属性

distinguished name (PKI)

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

仕様書

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

意味

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

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

[22] DIT 上のオブジェクトや別名エントリーは、属性集合によって構成され、 Distinguished Name (DN) によって固有に識別されます。 DN は、 DIT 上でより上位 (側) にあるエントリーの Relative Distinguished Name (RDN) である属性を集めることで得られます。 RDNattribute-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] 実際には PKIXsubject 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 型の typeAttributeValue 型の value で構成されます >>1attribute-type-and-value pair ともいいます >>11

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

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

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

文脈

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

[38] RelativeDistinguishedNameCRLDistributionPoints で用いられます。

属性

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

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

[19] 次の属性型を含む issuersubject名前に対応するべきです>>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

メモ

[37] UniversalStringUCS-4 を、 BMPStringUCS-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