2024年6月10日～2024年6月16日に読んだ中で気になったニュースとメモ書きです。社内勉強会TLSらじお第161回分。

[A Warm Welcome to ASN.1 and DER]

こちらのツイートから。

Let's Encrypt
A Warm Welcome to ASN.1 and DERhttps://t.co/78YYjqnUTD

ASN.1が嫌いな人がいたとしても、Let's Encryptのような組織がASN.1やDER、BERについて解説しようとしてくれていることは有難い。
— kjur (@kjur) 2024年6月14日

リンク先はこちら。

letsencrypt.org

サーバー証明書がASN.1つまりAbstract Syntax Notation Oneという記法で定義されているのは知ってたけど、細かいところは知らなかった...。

ASN.1のシリアライゼーション形式はDERとBERがあり、どちらもTLV形式（Tag-Length-Value）を取る。つまり、TLSのハンドシェイクメッセージなどと同様、型を示すバイト、Valueの長さを示すバイト、そして値そのもの、と続く。

INTEGERはDERだと126バイトの長さまで、BERだと無限長のフィールドが表現できるとか。int64どころじゃないんだ...。

StringもIA5String、PrintableString、UTF8Stringなど種類がある...。Printableといいつつ*や@が含まれないので、IA5String（ASCIIの最初の128文字）を使う必要があるとか。罠だなあ。

SEQUENCEとSEQUENCE OFはまったく別物で、SEQUENCEがいわゆる構造体で、SEQUENCE OFは配列に相当するらしい。

あと特徴的なのがObject Identifier。標準、アルゴリズム、証明書拡張、組織などあらゆるものを識別するのに利用する。1.3.6.1.4.1.11129はGoogle, Inc.を、1.3.6.1.4.1.11129.2.4.2はGoogleが開発したCTで利用するSCTリスト拡張を示す。

この記事で一番面白かったのは末尾の「ちょっとしたおまけ」。PEMエンコードされた証明書がMIIで始まる理由を説明してくれている。証明書はSEQUENCEなので0x30バイト始まり、長さのフィールドは基本変わらないので、証明書の最初の値をBase64に変換するとMII...となるらしい。証明書の長さが16383バイト以上になると変わるらしいので、耐量子暗号アルゴリズムで公開鍵のサイズが変わってくるとこの辺りにも影響があるかも？

[その他のニュース]

▼Java 8とTLS1.3

こちらのツイートから。

Improved Performance of TLS 1.3 in Java JDK 8#Java #OpenJDK https://t.co/55ebSfnVce
— Java at Microsoft (@JavaAtMicrosoft) 2024年6月10日

リンク先はこちら。

devblogs.microsoft.com

Javaはバージョン11でTLS1.3が実装され、その後LTSであるバージョン8にバックポートされたらしい。TLS1.3のRFCが2018年8月、Java 11のリリースが2018年9月だから、まあそんなもんでしょうか。

Java 11の初期の実装には問題があって、Java 20でのちにバグ（KeepAliveCache Blocks Threads while Closing Connections）が修正され、これがJava 8にバックポートされることで、パフォーマンスが30倍向上したとか。

Java 8を使い続けられるのはありがたいけど、そろそろ移行しないとな...。

▼Entrust続報

こちらのツイートから。

I have held out hope that Entrust would get their act together, but unfortunately, despite being given every opportunity and a massive amount of time, they have squandered it. Their response to their repeated mishandling of incidents and failure to live up to their past…
— Ryan Hurst (@rmhrisk) 2024年6月11日

リンク先はこちら。

groups.google.com

6/15のWayne氏の書き込みによると、数ヶ月遅れでようやくEntrustが緊急対応の人間をアサインしたとか。スレッドに登場しているBruce Morton氏のことだろうか？

スレッド中で、Mike Shaver氏はEntrustが十分な対応をしておらず、2024年6月7日以降に発行されたEntrustの証明書をMozilla製品が信頼しないことを提案している。

Ryan Hurst氏の見解はこちらの返信にある。個々のインシデントはさほど大きな問題ではないが、一連の長期的な対応を考慮すると、エンドユーザーからの信頼に値しないのではないかとのこと。

▼fancy-cryptography

こちらのツイートから。

We're crowdsourcing a list of mainstream uses of "fancy" cryptography such as OPRFs, blind signatures, SNARKs and ZKP. Basically cryptography beyond symmetric ciphers, hashes, signatures, and KEM/PKE.https://t.co/HnBYEpMV8a
— Bas Westerbaan (@bwesterb) 2024年6月12日

リンク先はこちら。

github.com

TLSはあまり関係ないけど、高度暗号あれこれを集めたリポジトリ。

ここでいうFancyは、高度な、複雑な、という意味っぽい。カタカナのファンシーの語感とは随分違うな...。