メインコンテンツまでスキップ

3.3. TLSハンドシェイクへの署名付き証明書タイムスタンプの組み込み

3.3. TLSハンドシェイクへの署名付き証明書タイムスタンプの組み込み​

少なくとも1つのログからのエンドエンティティ証明書に対応するSCTデータは、以下に説明するX509v3証明書拡張を使用するか、タイプ「signed_certificate_timestamp」のTLS拡張 ([RFC5246]のセクション7.4.1.4) を使用するか、またはオンライン証明書状態プロトコル (OCSP) ステープリング (「Certificate Status Request」TLS拡張としても知られています。[RFC6066]を参照) を使用してTLSハンドシェイクに含まれなければなりません。ここで、応答にはOID 1.3.6.1.4.1.11129.2.4.5 ([RFC2560]を参照) のOCSP拡張と本文が含まれます。

    SignedCertificateTimestampList ::= OCTET STRING

少なくとも1つのSCTが含まれなければなりません (MUST)。サーバーオペレーターは、複数のSCTを含めてもかまいません (MAY)。

同様に、証明機関は事前証明書を複数のログに提出してもよく (MAY)、取得されたすべてのSCTは、SignedCertificateTimestampList構造をASN.1 OCTET STRINGとしてエンコードし、結果として得られるデータをX.509v3証明書拡張 (OID 1.3.6.1.4.1.11129.2.4.2) としてTBSCertificateに挿入することによって、最終証明書に直接埋め込むことができます。証明書を受信すると、クライアントはSCT署名を検証するために元のTBSCertificateを再構築できます。

OCSP拡張またはX509v3証明書拡張に埋め込まれたASN.1 OCTET STRINGの内容は次のとおりです。

     opaque SerializedSCT<1..2^16-1>;

     struct {
         SerializedSCT sct_list <1..2^16-1>;
     } SignedCertificateTimestampList;

ここで、「SerializedSCT」は、シリアル化されたTLS構造を含む不透明なバイト文字列です。このエンコーディングにより、TLSクライアントは各SCTを個別にデコードできます (つまり、バージョンアップグレードがある場合、古いクライアントは、理解できない新しいSCTをスキップしながら、古いSCTを解析できます)。

同様に、SCTはTLS拡張に埋め込むことができます。詳細については以下を参照してください。

TLSクライアントは、3つのメカニズムすべてを実装しなければなりません (MUST)。サーバーは、3つのメカニズムのうち少なくとも1つを実装しなければなりません (MUST)。既存のTLSサーバーは、一般的に変更なしで証明書拡張メカニズムを使用できることに注意してください。

TLSサーバーは、1つ以上のログがクライアントに受け入れられない場合 (たとえば、ログが不正行為のために除外されたか、キーの侵害があった場合) に備えて、複数のログからSCTを送信する必要があります。

に最終更新