[13] distinguished name (DN) / X.501 の型 Name は、 「国名」「組織名」その他の属性によって表現される階層化された名前を表すものです。

仕様書

[3] RFC 5280 は X.501 の型 Name のインターネットPKIにおけるプロファイルを規定しています。

意味

[15] X.509 で規定される証明書は X.500 や X.501 が規定するディレクトリーサービスモデルを採用しており、 X.509 のプロファイルである PKIX も理論上はそれに従っています。 >>14

[16] X.500 ディレクトリーサービスモデルでは、情報はディレクトリー情報ベース (DIB) に格納されるもので、 DIB 上のエントリーはディレクトリー情報木 (DIT) と呼ばれる構造になっています。 >>14

[22] DIT 上のオブジェクトや別名エントリーは、属性の集合によって構成され、 Distinguished Name (DN) によって固有に識別されます。 DN は、 DIT 上でより上位 (根側) にあるエントリーの Relative Distinguished Name (RDN) である属性を集めることで得られます。 RDN は attribute-type-and-value pair の集合です。 >>14

[23] RDN は上位のエントリーの DN に相対的なものという意味で relative と呼ばれています >>14。[24] 根に近いエントリーを most significant である、葉を least significant であるといいます。[29] RDN は集合であり、本来順序を持たないはずですが、 証明書に用いる DER で符号化したり、それを文字列表現で表示したりすると、 特定の順序で示されることになります (それがビッグエンディアンだったりリトルエンディアンだったりしますが)。 しかもその順序を情報の階層と暗黙に関連付けて (実際にはそんな関係はあったりなかったりわからないですが) left-most/right-most、first/last、most/least specific/signiicant といった言葉を使う仕様書もあったりして、混乱しています。 >>14 CN-ID の規定では、この混乱を根拠に、同じ型の属性が複数指定された場合を定義から除外しています >>14。しかし実際には複数含まれる証明書も発行されているようです (service identity 参照)。[30] Name 中の RDN の順序も理論上は意味があると考えることもありますが、 実際にはあまりそのように扱われていません >>14。

[25] 実際には PKIX は subject 欄を X.501 Name で指定せずに空欄にして、かわりに SAN で指定することも認めています。 >>14

構文

[4] Name の書式は ASN.1 により定義されています。

[5] Name は、 RDNSequence 型の値の欄 rdnSequence のみを持ちます >>1。

[6] RDNSequence は、 RelativeDistinguishedName の列 (SEQUENCE) です >>1。

[7] RelativeDistinguishedName は、1個以上の AttributeTypeAndValue の集合です >>1。

[8] AttributeTypeAndValue は、 AttributeType 型の欄 type と AttributeValue 型の欄 value で構成されます >>1。 attribute-type-and-value pair ともいいます >>11。

[9] AttributeType は、オブジェクト識別子です >>1。

[10] AttributeValue は、 AttributeType によって決まる値です >>1。通常は DirectoryString となります >>1。

[12] まとめると、1つ以上の属性の集合であり、属性は型と値により構成されます。

文脈

[2] Name は 証明書の issuer 欄, subject 欄の値として用いられます。 TLS の CertificateRequest でも使われます。

[38] RelativeDistinguishedName は CRLDistributionPoints で用いられます。

属性

[17] RFC 5280 は名前中で使用できる属性型を制限していません >>1。

[18] 次の属性型を含む issuer と subject の名前に対応しなければなりません。 >>1

[19] 次の属性型を含む issuer と subject の名前に対応するべきです。 >>1

[26] その他:

比較

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

Two naming attributes match if the attribute types are the same and the values of the attributes are an exact match after processing with the string preparation algorithm. Two relative distinguished names RDN1 and RDN2 match if they have the same number of naming attributes and for each naming attribute in RDN1 there is a matching naming attribute in RDN2. Two distinguished names DN1 and DN2 match if they have the same number of RDNs, for each RDN in DN1 there is a matching RDN in DN2, and the matching RDNs appear in the same order in both DNs. A distinguished name DN1 is within the subtree defined by the distinguished name DN2 if DN1 contains at least as many RDNs as DN2, and DN1 and DN2 are a match when trailing RDNs in DN1 are ignored.

[21] subject 欄の値の比較では、属性値が DirectoryString なら、その比較規則を使って構いません。それ以外の値なら、バイナリ比較を使うべきです。 >>20

メモ

[40] RFC 1485 - A String Representation of Distinguished Names (OSI-DS 23 (v5)), , https://tools.ietf.org/html/rfc1485

[39] RFC 1779 - A String Representation of Distinguished Names, , https://tools.ietf.org/html/rfc1779

[41] RFC 2253 - Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names, , https://tools.ietf.org/html/rfc2253

[37] UniversalString は UCS-4 を、 BMPString は UCS-2 を表しています。

[31] RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2 ( 版) https://tools.ietf.org/html/rfc5246#section-7.4.4

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

[32] RFC 4514 - Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names ( 版) http://tools.ietf.org/html/rfc4514

[33] https - 東京都内のいくつかの団体のSSL証明書情報ピックアップ - Qiita ( 版) http://qiita.com/kobake@github/items/bc05d3790bde10869ad6

[34] Re: [certid] Need to define "most specific RDN" ( ()) https://www.ietf.org/mail-archive/web/certid/current/msg00231.html

[35] 469533 – FireFox 3.0.6 only processes 'Last' CN in x509 certificate when multiple CNs are present - ssl_error_bad_cert_domain ( ()) https://bugzilla.mozilla.org/show_bug.cgi?id=469533

[36] 自堕落な技術者の日記 : X.509証明書の識別名などで使われるMulti-valued RDNとjsrsasignのサポートについて - livedoor Blog(ブログ) () http://blog.livedoor.jp/k_urushima/archives/1808377.html