[37] 証明書鎖certificate chainは、 証明書の列です。

[38] ただの列ではなく、前の証明書を証明する発行者の証明書を次に置く、 という形で証明経路certification pathを記述したものとなっています。

仕様書

証明書鎖の記述形式

[43] 証明書鎖は証明書を順に並べたものに過ぎませんが、 どのように並びを記述するか、いくつかの形式ファイル形式があります。

[13] 証明書鎖を記述するファイル形式とプロトコル要素

証明書列のDER

[40] TLS でサーバー証明書やクライアント証明書を送信する Certificate メッセージでは、 証明書の列を DER 符号化したものが使われます。 Certificate

application/pkix-pkipath

[7] RFC 5280 証明書の列を DER で符号化したものが、 MIME型 application/pkix-pkipath です >>6。これは certification path を表します >>6。

[8] 証明書の順序は意味を持ちます。最初の証明書の subject が2番目の証明書の発行者、などとなるように並べます >>6。

[9] relying party は RFC 5280 に厳密に適合しない証明書を必ずしも拒絶しなくても構いませんが、 セキュリティーへの影響は慎重に検討する必要があります >>6。

[11] MIME型の引数は次の通りです。

  • version

[10] 7ビット輸送路では、 Base64 を使うべきです >>6。

[12] 拡張子は .pkipath が使われます >>6。

証明書のPEMの列

[39] OpenSSL は1個以上の証明書が含まれる.pemファイルに対応しています。 OpenSSL を使った多くの応用がこの形式をそのまま採用しています。

[41] この形式は、 1個の証明書を表す .pem ファイルを (適当な改行を挟んで) 任意の個数、繰り返し記述したものです。

[42] TLS Certificate 用にこれを指定した場合は、 PEMファイルに含まれる証明書がそのまま順に送信されます。

application/pem-certificate-chain

[19] .pemファイル形式の証明書鎖の記述形式の一種として、 application/pem-certificate-chain があります >>17, >>18。

  • [17] draft-ietf-acme-acme-18 - Automatic Certificate Management Environment (ACME) () https://tools.ietf.org/html/draft-ietf-acme-acme-18#section-9.1
  • [18] application/pem-certificate-chain () https://www.iana.org/assignments/media-types/application/pem-certificate-chain
  • [20] An optional MIME parameter for application/pem-certificate-chain? · Issue #435 · ietf-wg-acme/acme () https://github.com/ietf-wg-acme/acme/issues/435

x5u 参照先

[22] JWS のヘッダー引数や JWK の鍵引数である x5uで指定された証明書鎖の資源は、 RFC 5280 X.509 証明書または証明書鎖を RFC 4945 .pem 形式で符号化した表現を提供するものでなければなりません。 >>21, >>31

[23] JWS では、 RFC 4949 デジタル署名に用いた鍵に対応する公開鍵を含む証明書は、 最初の証明書でなければなりません。 >>21

[24] 前の証明書を次の証明書が証明する、 という形で追加の証明書があっても構いません。 >>21

[25] このような証明書鎖の制約の記述方法だと、 冗長な証明書を含めることが出来ず、 クロスルート証明書のような他の場面で利用可能な技法が通用しない場合が出てこないでしょうか。

[32] JWK では、 含まれる最初の証明書は、 JWK の他の鍵引数で記述された公開鍵に一致しなければなりません。 >>31

[33] JWSの取得プロトコルも参照。

証明書のPEMのJSON配列

[16] report-uri で指定された URL に送信される JSON では、証明書鎖を証明書の .pem 形式の文字列を JSON 配列として記述します。

証明書のDERのBase64のJSON配列

x5c の JSON 配列

[27] x5cのJSON配列は、 JSON配列です。 >>26, >>31

[28] JSON配列の各値は、 RFC 5280 PKIX X.509 証明書を DER 符号化し、 RFC 4648 Base64 符号化した文字列です。 >>26, >>31

[29] JWS では、 RFC 4949 デジタル署名するのに使った鍵に対応する公開鍵を含む証明書は、 最初の証明書でなければなりません。 >>26

[35] JWK では、鍵値を含む証明書は、 最初の証明書でなければなりません。 >>31

[36] ここでいう「鍵値」とは何か不明瞭ですが、 JWK として表現している鍵が直接的に含まれるものが最初の証明書のものである、 ということでしょう。

[30] 前の証明書を次の証明書が証明する、 という形で追加の証明書があっても構いません。 >>26, >>31

>>25

[34] JWK では、 含まれる最初の証明書は、 JWK の他の鍵引数で記述された公開鍵に一致しなければなりません。 >>31

その他のASN.1系記述形式

[44] PKCS #7証明書鎖

[45] Netscape Certificate Sequence

証明経路

中間証明書の欠如

Certificate

証明経路の完成のための証明書の入手

[46] TLS はじめ多くのプロトコルは証明書鎖にルート証明書を含めても、 含めなくても良いとしています。 必要なルート証明書は、手元の証明書データベースにあるものを参照します。

[47] ルート証明書が相手方から送られてきていれば、 それを使えば証明書データベースを参照しなくても EE証明書の検証自体は可能です。 しかしルート証明書が信頼できるかどうかの判断は必要となるので、 証明書データベースの参照はやはり必要となります。 したがってルート証明書は省略できるのです。

[48] TLS はじめ多くのプロトコルは必要な中間証明書をすべて証明書鎖に含めて相手方に送信することを求めています。

[49] しかしそれ以外の手段で中間証明書を取り揃えて証明経路を用意する仕組みを構築することは可能です。

[50] 実際にそのための要素の1つとして、 証明書に AIA を使って中間証明書の入手方法を記述することができます。

[51] IE は TLSサーバーが中間証明書を送ってこなかったときにも AIA を参照して中間証明書を取得して検証に使います。 そのために他の実装との互換性の問題をしばしば起こしていました。 AIA, Certificate

[52] また、実装によっては中間証明書の検証結果をキャッシュしているために、 プロトコル上必須とされる中間証明書が証明書鎖に含まれなかった場合でも、 キャッシュを根拠に検証を成功させてしまう場合があります。 このような挙動は接続の可否に再現困難な不確定性をもたらしてしまい、 問題の発覚と修正を難しくするので、避けなければなりません。

[53] 詳しい検証の処理はキャッシュを使うとしても、 証明経路の完全性の検証は毎回行う必要があるのでしょう。 その程度の検査で住むならコストは大きくならずに済むでしょうし。

メモ

[1] RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile ( 版) http://tools.ietf.org/html/rfc5280#section-3.2

[2] RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile ( 版) http://tools.ietf.org/html/rfc5280#section-4.1.2.4

Certificate users MUST be prepared to process the issuer

distinguished name and subject distinguished name (Section 4.1.2.6)

fields to perform name chaining for certification path validation

(Section 6). Name chaining is performed by matching the issuer

distinguished name in one certificate with the subject name in a CA

certificate.

[3] RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile ( 版) http://tools.ietf.org/html/rfc5280#section-4.2.1.7

Issuer alternative names are not

processed as part of the certification path validation algorithm in

Section 6. (That is, issuer alternative names are not used in name

chaining and name constraints are not enforced.)

[4] RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile ( 版) http://tools.ietf.org/html/rfc5280#section-6

[5] RFC 6818 - Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile ( 版) https://tools.ietf.org/html/rfc6818#section-4

[14] 634074 – Cannot validate valid certificate chain when looping/cross-signed certs are involved ( ()) https://bugzilla.mozilla.org/show_bug.cgi?id=634074

[15] RFC 7515 - JSON Web Signature (JWS) () https://tools.ietf.org/html/rfc7515#section-4.1.6