1. Introduction (はじめに)

Transport Layer Security (TLS) Extension (トランスポート層セキュリティ拡張) [RFC6066] フレームワークは, 他の拡張の中でも特に, Certificate Status extension (証明書ステータス拡張) ("OCSP stapling" (OCSPステープリング) とも呼ばれる) を定義しています。クライアントはこれを使用して, 別の接続を通じてダウンロードするのではなく, TLS ハンドシェイクを使用してそのようなデータを転送するために, サーバーにその証明書の現在のステータスのコピーを要求できます。この拡張の利点には, クライアントがサーバーの証明書のステータスを検証するためのラウンドトリップとネットワーク遅延の削減, および証明書発行者のステータス応答サーバーの負荷の削減が含まれます。これにより, 発行された証明書が頻繁に訪問されるサーバーによって提示される場合に重大になる可能性がある問題が解決されます。

既存の Certificate Status extension には2つの問題があります。第一に, 中間 Certification Authority (CA) (認証局) 証明書に関するステータス情報を要求する機能を提供していません。つまり, クライアントは Certificate Revocation Lists (CRLs) (証明書失効リスト) などの他の方法を通じてステータス情報を要求する必要があり, さらなる遅延が発生します。第二に, 拡張の現在の形式と TLS プロトコルの要求事項により, クライアントがサーバーに複数のステータス方式を提供することができません。

多くの CA は現在, CRL Distribution Point (CRL 配布ポイント) [RFC5280] で CRL の公開ポイントを指定するだけでなく, Authority Information Access (認証局情報アクセス) [RFC5280] で OCSP [RFC6960] サーバーの URL も指定する中間 CA 証明書を発行しています。クライアントがキャッシュした CRL は頻繁に期限切れになるため, クライアントは OCSP を使用して中間 CA 証明書に関する最新のステータス情報にアクセスすることで利益を得られます。発行 CA にとっての利点はそれほど明確ではありません。OCSP レスポンダの帯域幅を提供することはコストがかかる可能性があり, 特に多くのトラフィックの多いサブスクライバサイトを持つ CA にとってはそうであり, このコストは多くの CA にとって懸念事項です。単一のトラフィックの多いサイトに対する OCSP 要求が, 発行 CA に重大なネットワーク問題を引き起こしたケースがあります。

クライアントは, サーバー証明書だけでなく中間 CA 証明書についても, タイプに関係なく TLS サーバーが証明書ステータス情報を提供することから利益を得られます。ステータスチェックを1つの拡張に組み合わせることで, クライアントが TLS 接続をネゴシエートするために必要なラウンドトリップだけで済むようになり, ハンドシェイクを完了するために必要なラウンドトリップが削減されます。また, 認証局にとっては, サーバーへの負荷は発行した証明書の数に依存し, それらのサイトへの訪問者数には依存しません。さらに, この拡張を使用することで, クライアントが訪問しているサイトについて証明書発行者に通知することに関するプライバシーの懸念が大幅に軽減されます。

このような新しいシステムをシームレスに導入するには, クライアントが既存の OCSP Certificate Status 方式と新しい複数 OCSP モードのサポートを示すことができる必要があります。

残念ながら, Certificate Status extension の定義では, ハンドシェイクの単一の拡張レコードで定義できる Certificate Status extension は1つだけであり, TLS プロトコル [RFC5246] では, 任意の拡張について拡張リスト内の単一のレコードしか許可されていません。これは, クライアントが古い方式をサポートしながら新しい方式のサポートを示すことができないことを意味し, 新しいクライアントと古いサーバー間の相互運用性に問題を引き起こします。これは, 上記で提案された複数ステータス要求モードだけでなく, 将来導入される可能性のある他のステータス方式にとっても問題になります。これは, 現在の PKIX インフラストラクチャ [RFC5280] だけでなく, 代替 PKI 構造にとっても当てはまります。

この問題の解決策は, 新しい拡張 "status_request_v2" を定義することです。これは拡張された形式を持ち, クライアントが複数のステータス要求方式のサポートを示すことができます。これは, 拡張レコード内の CertificateStatusRequestItemV2 レコードのリストを使用して実装されます。サーバーは選択された暗号スイートと提示された証明書に基づいて単一のステータス方式を選択するため, サーバーの拡張形式に大きな変更は必要ありません。