ゆるTLSアドベントカレンダー 10日目：CT

この記事は ゆるTLS Advent Calendar 2021 の10日目の記事です。

もはや何日遅れなのか数えるのもめんどくさい...orz

9日目に、不正に発行された証明書のチェックを行うための仕組みとして言及したCertificate Transparency（CT：証明書の透明性）の最新情報（2021年12月時点）を。

[CT v1]

CTのバージョン1.0は、2013年6月に仕様が公表された（RFC6962）。

www.rfc-editor.org

TLS拡張のひとつとして、signed_certificate_timestamp拡張が定義されている。

この署名付き証明書タイムスタンプは、認証局が証明書発行時に、監査ログサーバに証明書を登録した際にログサーバから返されるものである。

これをTLSクライアントがTLS拡張を通して受け取り検証することで、透明性のある証明書であることを確認できるため、証明書の信頼性が向上する（プロフェッショナルSSL/TLS 51ページ）。

例えば、Googleが公開している監査ログサーバのサイトはこちら。

transparencyreport.google.com

たとえば、www.google.comの証明書のログはこのようになっている。Google Trust ServicesやGoogle Incのほか、DigiNotarやThawteなどの認証局から発行されているのが分かる。

[CT v2]

そのCTのv2.0にあたるRFC9162が出たのをこのツイートで知った。

RFC 9162
Certificate Transparency Version 2.0https://t.co/Y5IR8dtZSx
CT v2 出た！！

— ゆき (@flano_yuki) 2021年12月10日

datatracker.ietf.org

v1.0からの大きな変更点として、TLS拡張が

• signed_certificate_timestamp

ではなく、

• transparency_info

に変更となった。

TLSサーバはTLS1.2以下の場合ServerHelloメッセージにのみ、TLS1.3の場合は、CertificateメッセージまたはCertificateRequestメッセージにのみ、この拡張を追加できる。

この新しく追加されたTLS拡張transparency_infoのextension_dataはTransItemListとなる。これは、TransItemsから構成されるが、既にサーバ証明書やOCSPステープルのレスポンスに含まれる場合には、transparency_infoには含めない。

TransItemsは次のような種類（VersionedTransType）があるが、このうちtransparency_infoとしてタイムスタンプ系の2つのいずれかは必須（MUST）となっている。可能な場合にはsigned_tree_head_v2とinclusion_proof_v2もtransparency_infoに含めるべし（SHOULD）とされている。

enum {
   // entry系：CTのログデータそのもの
   x509_entry_v2(0x0100), precert_entry_v2(0x0101),
   // sct系：タイムスタンプ
   x509_sct_v2(0x0102), precert_sct_v2(0x0103),
   // ツリー系：CTのログのツリー構造に使われる
   signed_tree_head_v2(0x0104), consistency_proof_v2(0x0105),
   inclusion_proof_v2(0x0106),
   // 予約済みデータ
   reserved_rfc6962(0x0000..0x00FF),
   reserved_experimentaluse(0xE000..0xEFFF),
   reserved_privateuse(0xF000..0xFFFF),
   (0xFFFF)
} VersionedTransType;

その他細かい変更点は以下の通り。

• 許可されたハッシュアルゴリズム、署名アルゴリズムがIANAのレジストリで指定されるようになった：RFCと独立してるからアジャイルさが増すらしい。
• 事前証明書（precertificate）がX.509形式ではなくCMSオブジェクトに：シリアルナンバの一意性を侵害しないためらしいが、よく分からなかった...🥺
• ログIDがOIDではなく公開鍵のハッシュ値に
• TransItem構造体が追加：MerkleTreeLeaf構造体を置き換え、シンプルで拡張しやすくなった
• Log artifact extensionsがSCTだけでなくSigned Tree Heads (STHs)にも利用可能に
• APIの出力結果が完全なTransItem構造体に。もとは部分的だった
• 新しいクライアントAPIが追加（get-all-by-hash、submit-entry）

事前証明書とか、MerkleTreeLeaf構造体とか、知らない概念がいっぱいでてきてつらい...。

[まとめ]

• 2013年に制定されたCT v1に代わり、2021年12月にCT v2が制定された
• 大きな変更点としては、TLS拡張がsigned_certificate_timestampではなく、transparency_infoになった