要約

  • TLS作業部会が9月30日に出した信頼アンカー識別子草案の第06版は、識別子のバイナリ表現の上限を255バイトから32バイトへ変更した。TLSのTrustAnchorID構造も1～32バイトとなる。文書はまだInternet-Draftで、IESGの状態はI-D Existsだ。
  • 新たな実装上の説明は、OIDの一成分が極めて大きい場合の整数オーバーフローや誤解釈を禁じる。有効なIDをローカルの表示・設定系が扱えない場合にも相互運用性を保つ必要がある。IDは経路選択の手掛かりであり、CAへの信頼そのものではない。

ルート認証局を更新する時、全ての利用者が同じ日に新しい根を受け入れるわけではない。認証する側が複数の証明書経路を用意できても、相手がどの認証局を信頼するか分からなければ適切な経路を選びにくい。草案のtrust_anchors拡張は、その選択に使う目印を簡潔に伝えようとする。古いcertificate_authorities拡張で長い名前を並べる負担を減らせる可能性があるが、短い目印を送信しただけで検証が成功するわけではない。

改訂で確認できる第一の差分は長さだ。9月14日付の第05版では、信頼アンカーIDのバイナリ表現は最大255バイトだった。第06版では32バイトになり、TLS構造の範囲も<1..2^8-1>から<1..32>へ変わった。草案は、バイナリ形式とドット区切りの十進表記が、相対OIDでも完全なOIDでも255バイト以内に収まりやすくするためだと説明する。これは一つのIDの長さの規定であり、利用側が信頼できる認証局の数を32に制限する規定ではない。

第二の差分は、ID全体の長さとは異なる「大きさ」を扱う。OIDの個々の成分やグループを照合するパターンの整数には理論上大きな値があり得る。第06版は、固定幅整数への変換でオーバーフローを起こしたり、別の値として読んだりしてはならないと明記した。識別子の等価性とパターン照合はバイト列のまま処理できるため、原則としてその形を保持することを勧める。相互接続で重要なのは、表示可能な数字の範囲と、プロトコルとして受け入れるべき有効な入力の範囲を混同しないことだ。

診断画面やテキスト設定では、ドット区切りの数字に上限を設けてもよい。ただしTLS実装は、指定されたハンドシェイクのメッセージに任意に大きいOID成分を含むIDを受け取れる必要がある。別の部品に渡す前に対応外のIDを捨てることは認められる。EncryptedExtensionsのIDを全て捨てた場合は、拡張がなかったのと同じ扱いになる。大きい成分を扱えない表示装置が、勝手に新しい信頼関係を作ったり、別のIDへ丸めたりしてよいわけではない。上限を設ける実装には少なくとも2^32-1までの成分を支えることが推奨され、Private Enterprise Numberの範囲を意識した値だ。

改訂には、版管理されたグループの例で最大値を2^64-1から無限大に直す変更もある。例の変更を実際の登録簿や根証明書の変更と取り違えてはならない。Datatrackerでの文書は作業部会草案で、IESG承認やRFC発行はまだ示されていない。実装製品の普及、欠陥、侵害についても、この差分だけから結論は出せない。

出典