935.txt

* 仕様書

[REFS[
- [1] '''[CITE@en[RFC 6125 - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)]] ([TIME[2015-03-13 22:27:53 +09:00]] 版) <https://tools.ietf.org/html/rfc6125>'''
-- [4] [CITE@en[RFC 6125 - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)]] ([TIME[2015-03-13 22:27:53 +09:00]] 版) <https://tools.ietf.org/html/rfc6125#section-3>
-- [11] [CITE@en[RFC 6125 - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)]] ([TIME[2015-03-13 22:27:53 +09:00]] 版) <https://tools.ietf.org/html/rfc6125#section-4>
-- [26] [CITE@en[RFC 6125 - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)]] ([TIME[2015-03-13 22:27:53 +09:00]] 版) <https://tools.ietf.org/html/rfc6125#section-5>
-- [33] [CITE@en[RFC 6125 - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)]] ([TIME[2015-03-13 22:27:53 +09:00]] 版) <https://tools.ietf.org/html/rfc6125#section-6>
-- [67] [CITE@en[RFC 6125 - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)]] ([TIME[2015-03-13 22:27:53 +09:00]] 版) <https://tools.ietf.org/html/rfc6125#section-7.1>
-- [69] [CITE@en[RFC 6125 - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)]] ([TIME[2015-03-13 22:27:53 +09:00]] 版) <https://tools.ietf.org/html/rfc6125#section-7.4>
-- [72] [CITE@en[RFC 6125 - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)]] ([TIME[2015-03-13 22:27:53 +09:00]] 版) <https://tools.ietf.org/html/rfc6125#appendix-A>
- [2] [CITE[RFC Errata Report]] ([TIME[2015-03-24 22:54:51 +09:00]] 版) <http://www.rfc-editor.org/errata_search.php?rfc=6125>
]REFS]

[3] [[RFC 6125]] は [[TLS]] と [[PKIX]] を用いる場合で、[[アプリケーションプロトコル]]においてサービスの識別に[[ドメイン名]]を使う場合に、
その service identity の検査をどう行うべきかを規定するものです。従来 [[TLS]]
を用いる[[アプリケーションプロトコル]]はそれぞれ検査の方法を規定していましたが、
ほぼ同じで細部が異なるものでした。 [[RFC 6125]] はそれを踏まえて新たに標準的な方法を規定するものです。
ただし従来の各プロトコルの規定を廃止するものではなく、新プロトコルや既存プロトコルの改訂版で明示的に参照される場合にのみ適用する [SRC[>>1]] とされています。

[73] [[RFC 6125]] の附属書A、B はそれまでに出版された [[IETF]] の仕様書の
[[service identity]] の検査に関する条項をまとめています。

* ドメイン名

[24] [[証明書]]には[[ドメイン名]]は色々な形で記述され得ます。そのうち
[[RFC 6125]] に従う仕様で [[service identity]] を表すものとして解釈されるのは、
[FIG(short list)[
- [[CN-ID]]
- [[DNS-ID]]
- [[SRV-ID]]
- [[URI-ID]]
]FIG]
... の4つの[[識別子型]]の識別子です。 (それ以外も用いることも排除はされていません。)

[25] これらの形式の値の一部または全部が [[DNSドメイン名]]とみなされます。
[[IDN]] は [[Aラベル]]を使った [[ASCII]] のみの形に変換されてから[[証明書]]に記述されます。

* IP アドレス

[74] [[証明書]]では[[IPアドレス]]は [[SAN]] の [CODE[[[iPAddress]]]]
に記述されます。

[75] [[HTTPS]] などいくつかの仕様は [[IPアドレス]]の場合に [CODE[[[iPAddress]]]]
を検査するべきことを規定しています。それ以外の仕様は (意図的かどうかは不明ですが)
明記していません。 [[RFC 6125]] も[[ドメイン名]]のみが適用対象であるとして
[[IPアドレス]]には言及していません。

* 証明書

[12] [[CA]] が[[完全修飾DNSドメイン名]]に基づく[[証明書]]を発行する時は、
次の規則が適用されます [SRC[>>11]]。
[FIG(list)[
- [13] [[証明書]]は [[DNS-ID]] を含む[['''べきです''']]。
- [14] [[証明書]]を使用する[[応用サービス]]の仕様が要求しているなら、
[[SRV-ID]] を含む[['''べきです''']]。
- [15] [[証明書]]を使用する[[応用サービス]]の仕様が要求しているなら、
[[URI-ID]] を含む[['''べきです''']]。
-- [16] [[URI-ID]] の [[scheme]] は当該サービスのプロトコルの [[scheme]] でなければ[['''なりません''']]。
-- [17] [[URI-ID]] の [[host]] (またはそれに相当するもの) は当該サービスの[[完全修飾DNSドメイン名]]でなければ[['''なりません''']]。
- [19] [[証明書]]は [CODE[[[XmppAddr]]]] など応用依存の識別子も含んで構いません。
- [20] [[証明書]]を使用する[[応用サービス]]の仕様が明示的に[RUBYB[推奨]@en[encourage]]する場合を除き、
[[CN-ID]] を含む[['''べきではありません''']]。
- [21] [[DNS-ID]]、[[SRV-ID]]、[[URI-ID]] は複数あっても構いません。
- [23] [[証明書]]を使用する[[応用サービス]]の仕様で認められる場合を除き、
[[DNSドメイン名]]に[[ワイルドカード]]を含める[['''べきではありません''']]。
]FIG]

[22] [[CN-ID]] が複数ある[['''べきではない''']] [SRC[>>11, >>69]] とされていますが、
定義上複数あるものは [[CN-ID]] ではありません。実際には [[SNI]] に対応していない環境に向けても
[[virtual host]] を実現するために複数の [[CN-ID]] を[[証明書]]に含めることがある
[SRC[>>69]] ようです。

;; [70] ですから、 [[CN-ID]] の定義が誤っていると解釈するべきでしょう。

* CSR

[27] [[CSR]] を作成するサービス提供者に対しては次のような指針が示されています [SRC[>>26]]。
[FIG(list)[
- [28] 一般に、[[証明書]]を使用する[[応用サービス型]]について要求または推奨されるすべての[[識別子型]]の[[識別子]]を含めることが[RUBYB[推奨]@en[encourage]]されます。
- [29] [[証明書]]が任意の[[応用サービス型]]について利用され得る場合は、
[[DNS-ID]] のみ含めることが推奨されます。
- [30] [[証明書]]が特定の[[応用サービス型]]についてのみ利用される場合は、
[[DNS-ID]] と、 (あれば) 当該[[応用サービス型]]に限定される [[SRV-ID]] や [[URI-ID]]
を含めることが推奨されます。
- [31] 複数の[[応用サービス型]]を提供したい時で [[SRV-ID]] や [[URI-ID]]
で適用対象を限定したい時は、複数の[[証明書]]を求めることが推奨されます。
異なる[[応用サービス型]]に関する複数の [[SRV-ID]] や [[URI-ID]]
を含む[[証明書]]を求めることは[RUBYB[推奨されません]@en[discouraged]]。
-- [32] [[IMAP]] と [[POP]] のような同種の[[プロトコル]]群はここでいう「複数の[[応用サービス型]]」には該当しません。
]FIG]

* アプリケーションプロトコル

[5] [[アプリケーションプロトコル]]の設計では、次の点を考慮するべきです [SRC[>>4]]。
[FIG(list)[
- [6] [[DNS]] [CODE[[[SRV]]]] [[レコード]]を使って[[ドメイン名]]の[[解決]]を行うなら、
[[証明書]]で [[SRV-ID]] [[識別子型]]への対応を要求または推奨することを検討するべきです [SRC[>>4]]。
- [7] [[URI]] を使って応用サービスを識別するなら、[[証明書]]で [[URI-ID]] 
[[識別子型]]への対応を要求または推奨することを検討するべきです [SRC[>>4]]。
-- [18] [[URI-ID]] の [[URL scheme]] を規定しなければ[['''なりません''']] [SRC[>>11]]。
- [8] [[後方互換性]]のために[[証明書]]の [CODE[[[CN]]]]
欄の[[DNSドメイン名]]を使う必要があるなら [[CN-ID]]
[[識別子型]]にフォールバックとして対応することを推奨することを検討するべきです [SRC[>>4]]。
- [9] [[DNSドメイン名]]で[[ワイルドカード]]に対応する必要があるなら、
[[ワイルドカード証明書]]への対応を推奨すること、
[[DNSドメイン名]]のどこに[[ワイルドカード]]文字が認められるか規定することを検討するべきです
[SRC[>>4]]。
]FIG]

;; [10] しかし既存のアプリケーションは [[SRV-ID]] や [[URI-ID]] に対応していないものが多い
[SRC[>>4]] です。

* 検証

[34] [[アプリケーションプロトコル]]の[[クライアント]]は、 [[service identity]]
を次のようにして[RUBYB[検証]@en[verify]]します [SRC[>>33]]。
[FIG(steps)[
= [35] [[利用者]]の入力等に基づき、受け入れる[[参照識別子]]のリストを作成します。
= [36] [[サーバー証明書]]から[[サーバー]]の識別子を得ます。
= [37] [[参照識別子]]と[[サーバー]]の識別子が一致するか検査します。
]FIG]

[55] [[証明書]]に示された[[識別子]]を順に調べ、
[[参照識別子]]のリストとの一致を検査します。一致するものが見つかれば、
そこで探すのをやめる[['''べきです''']]。 [SRC[>>33]]

[56] [[証明書]]に [[DNS-ID]]、[[SRV-ID]]、[[URI-ID]]、応用依存の ([[クライアント]]が対応する)
[[識別子型]]の[[識別子]]が含まれているなら、 [[CN-ID]] の[[参照識別子]]との一致を調べては[['''なりません''']]。
含まれていないなら、フォールバックとして [[CN-ID]] の一致を検査して構いません。 [SRC[>>33]]

;; [71] [[RFC 6125]] は[[ドメイン名]]を対象にしているので[[応用サービス型]] 
([[URL scheme]]) と[[ドメイン名]]にしか言及がありませんが、 [[URI-ID]] に
[[path]] や [[query]] が含まれる場合や、 [[URI-ID]] 相当のものが[[ドメイン名]]を含まない場合についても[[アプリケーションプロトコル]]はどう比較するか規定しなければならないものと思われます。

** 参照識別子のリストの作成

[38] [[クライアント]]は、[[参照識別子]]のリストを作成しなければ[['''なりません''']]
[SRC[>>33]]。

[52] まず[[利用者]]の入力や設定、[[ハイパーリンク]]などによって指定された接続先情報から、
[[ドメイン名]]の情報と[[応用サービス型]]を得ます [SRC[>>33]]。

[EG[
[39] 例えば入力 [[URL]] [CODE[[[sips:alice@example.net]]]] から、
[[応用サービス型]] 「sip」と[[ドメイン名]] 「example.net」を得ます [SRC[>>33]]。
]EG]

[53] これは入力に直接含まれる情報を取り出すだけかもしれませんし、
何らかの解決サービスに問い合わせた結果かもしれません。
ただし攻撃者が介在し得ない安全な方法で得たもの ([[利用者]]が明示的に指定したもの、
[[DNSSEC]] により得たものなど) でなければ[['''なりません''']] [SRC[>>33]]。
入力に直接由来する[[ドメイン名]] ([[source domain]]) を使う[['''べき''']]で、
それを [[DNS]] [[解決]]するなどして得られた[[ドメイン名]] ([[derived domain]])
を使う[['''べきではありません''']] [SRC[>>33]]。

;; [40] これは、利用者の入力とサーバー側が示した識別子が一致することをもってのみ、
当該[[証明書]]によって安全が保たれると言えるからです。
ただし例外として、人間利用者が[[証明書]]を他のドメイン名に「pin」
した場合には、 [[source domain]] と他のドメイン名の両方を含むことになります。 [SRC[>>33]]

[54] 次に、[[ドメイン名]]と[[応用サービス型]]から、[[参照識別子]]のリストを得ます。

[FIG(list)[
- [41] [[DNS-ID]] を含める[['''べきです''']]。 [SRC[>>33]]
-- [[DNSドメイン名]]のみで、[[応用サービス型]]は含まれません [SRC[>>33]]。
- [42] 当該[[応用サービス型]]でサーバーが通常 [[DNS]] [CODE[[[SRV]]]] 
[[レコード]]により発見可能なものなら、 [[SRV-ID]] を含む[['''べきです''']]。 [SRC[>>33]]
-- [[SRV-ID]] は [CODE[_]]、[[応用サービス型]]、[CODE[.]]、[[DNSドメイン名]]で構成されます。
- [43] 当該[[応用サービス型]]が通常セキュリティー目的で [[URI]]
に関連付けられるものなら、 [[URI-ID]] を含む[['''べきです''']]。 [SRC[>>33]]
-- [[URI-ID]] は[[応用サービス型]]と[[DNSドメイン名]]に相当するものが含まれます。
- [44] [[後方互換性]]のため [[CN-ID]] を含むことができます。 [SRC[>>33]]
-- [[DNSドメイン名]]のみで、[[応用サービス型]]は含まれません [SRC[>>33]]。
- [47] [CODE[[[CN]]]] 以外の [[RDN]] について識別子を構築し、検査しては[['''なりません''']]
[SRC[>>33]]。
- [50] [CODE[[[XmppAddr]]]] のような[[応用サービス型]]依存の識別子を含めることもできます。
]FIG]

;; [51] この[[参照識別子]]のリストの作成は、[[サーバー]]側が示す識別子とは独立に、
[[クライアント]]側のみで行わなければ[['''なりません''']] [SRC[>>33]]。

[45] どの[[識別子型]]の識別子を含めるかは [[local policy]] の問題です。
例えば特定のサービスにのみ接続するよう構築されたクライアントでは、
その[[応用サービス型]]の [[SRV-ID]] のみ含めることにできます。
より一般的なクライアントでは [[SRV-ID]] と [[DNS-ID]] の両方を含めます。
当面の間は [[CN-ID]] にも対応する必要がある可能性が高いです。
[SRC[>>33]]

[EG[
[48] [[Webブラウザー]]は、  [CODE[www.example.com]] の [[HTTPS]] において 
[FIG(list)[
- [[DNS-ID]] [CODE[www.example.com]]
- フォールバック [[CN-ID]] [CODE[www.example.com]]
]FIG]
... を含めることができます [SRC[>>33]]。
]EG]

[EG[
[49] [[MUA]] は、 [[IMAPS]] [CODE[example.net]] が
[CODE[mail.example.net]] に解決される時、
[FIG(list)[
- [[SRV-ID]] [CODE[_imaps.example.net]]
- [[DNS-ID]] [CODE[example.net]]
- [[DNS-ID]] [CODE[mail.example.net]]
- フォールバック [[CN-ID]] [CODE[example.net]]
- フォールバック [[CN-ID]] [CODE[mail.example.net]]
]FIG]
... を含めることができます [SRC[>>33]]。
]EG]

;; [46] これらの識別子は[[証明書]]に示された識別子と比較するために用意するだけで、
実際に [[ASN.1]] のような[[証明書]]で使われる表現で構築する必要はありません。 [SRC[>>33]]

** ドメイン名の比較

[57] [[クライアント]]は、[[参照識別子]]の[[DNSドメイン名]]部分が[[一致]]するか検査しなければ[['''なりません''']]。
[[参照識別子]]の[[DNSドメイン名]]が[[伝統的ドメイン名]]なら、
[[ASCII大文字・小文字不区別]]で各[[ラベル]]を順に比較しなければ[['''なりません''']]。
[[参照識別子]]の[[DNSドメイン名]]が [[IDN]] なら、
[[Uラベル]]を[[Aラベル]]に変換した上で、
[[ASCII大文字・小文字不区別]]で各[[ラベル]]を順に比較しなければ[['''なりません''']]。
[SRC[>>33]]

[58] [[ワイルドカード文字]]の扱いについては、[[ワイルドカード証明書]]の項を参照。

** 応用サービス型の比較

[59] [[SRV-ID]] や [[URI-ID]] については[[応用サービス型]]の[[一致]]も検査しなければ[['''なりません''']] [SRC[>>33]]。

[60] [[SRV-ID]] の応用サービス名部分は、 [[DNS]] [CODE[[[SRV]]]] の仕様にそって[[大文字・小文字不区別]]で比較しなければ[['''なりません''']] [SRC[>>33]]。

[61] [[URI-ID]] の [[URL scheme]] 部分は、 [[URL]] の仕様にそって[[大文字・小文字不区別]]で比較しなければ[['''なりません''']] [SRC[>>33]]。

** 一致判定

[62] [[証明書]]に示された識別子で[[資源識別子]]に[[一致]]するものが見つかれば、
[[service identity]] の検査は成功です。[[クライアント]]はその[[資源識別子]]を当該[[応用サービス]]の[RUBYB[検証済み]@en[validated]] [[identity]]
として使わなければ[['''なりません''']] [SRC[>>33]]。

[63] [[証明書]]に示された識別子で[[資源識別子]]に[[一致]]するものが見つからなかった場合で、
以前に当該[[応用サービス]]の[[証明書]]をいずれかの[[資源識別子]]に [[pin]]
している場合で、[[証明書]]が [[pin]] された[[証明書]]と一致する場合には、
[[service identity]] の検査は成功です [SRC[>>33]]。

[64] [[証明書]]に示された識別子で[[資源識別子]]に[[一致]]するものが見つからなかった場合で、
[[pin]] された[[証明書]]もない場合、[[対話的]]なクライアントは[[利用者]]に
[[identity]] が一致しなかったと通知し、通信は問題ある[[証明書]]であるとの[[誤り]]により自動的に終端する[['''べきです''']] [SRC[>>33]]。

[65] [[対話的]]なクライアントの中には、その場合であっても処理を続行する、
つまり[[証明書]]を [[pin]] する選択肢を[[利用者]]に示すものもあります。
特殊な状況ではそのような動作も必要かもしれませんが、高度な利用者のみに提示するべきものです。
しかも極めて注意して取り扱うべきものですから、 [[pin]] する前に [[certification path]]
全体の確認を強制するなど注意が必要です。 [SRC[>>33]]

[66] クライアントが[[人間]]利用者が直接制御しない自動化された応用である場合には、
問題ある[[証明書]]であるとの[[誤り]]により自動的に終端し、誤りを適宜記録する[['''べきです''']]。
これを抑制する設定を設けても構いませんが、既定値としては[['''なりません''']]。 [SRC[>>33]]

;; [68] [[pin]] は、示された[[証明書]]とその承認された文脈の両方を考慮しなければ[['''なりません''']]。
ここでいう文脈とは、当該[[証明書]]から trust anchor までの[[証明書鎖]]、
[[source domain]]、[[応用サービス型]]、サービスの [[derived domain]]
や[[ポート番号]]、その他[[利用者]]や[[クライアント]]が持つ関係する情報を含みます。 [SRC[>>33]]