文字列

文字列 (X.500)

[31] ASN.1 にはいろいろな文字列型があります。

仕様書

IA5String

[5] >>4

A value of the IA5 String syntax is a string of zero, one, or more characters from International Alphabet 5 (IA5) [T.50], the international version of the ASCII character set. The LDAP-specific encoding of a value of this syntax is the unconverted string of characters, which conforms to the <IA5String> rule in Section 3.2.

The LDAP definition for the IA5 String syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )

This syntax corresponds to the IA5String ASN.1 type from [ASN.1].

PrintableString

[3] X.400 (RFC 987, RFC 1138, RFC 1148, RFC 1327, RFC 2156) で定義されています。

[34] RFC 4517 - Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules ( 版) http://tools.ietf.org/html/rfc4517#section-3.3.29

構文

 printable-string   = *(ps-delim / ps-restricted-char)
 ps-restricted-char = DIGIT / ALPHA / " " / "'" / "+"
                    / "," / "-" / "." / "/" / ":" / "=" / "?"
 ps-delim           = "(" / ")"
 ps-encoded       = *( ps-restricted-char / ps-encoded-char )
 ps-encoded-char  = "(a)"               ; (@)
                  / "(p)"               ; (%)
                  / "(b)"               ; (!)
                  / "(q)"               ; (")
                  / "(u)"               ; (_)
                  / "(l)"               ; "("
                  / "(r)"               ; ")"
                  / "(" 3DIGIT ")"      ; 000 - 127 (= ASCII %x00-7E)

大文字・小文字は区別しませんが、常に小文字で生成します。

(l), (r) は RFC 987 では定義されていませんでした。

         'a demo.'         <->   'a demo.'
         foo(a)bar         <->   foo@bar
         (q)(u)(p)(q)      <->   "_%"
         (a)               <->   @
         (A)               ->    @
         (l)a(r)           <->   (a)
         (126)             <->   ~
         (                 ->    (
         (l)               <->   (

DirectoryString

[11] DirectoryString は、 TeletexString, PrintableString, UniversalString, UTF8String, BMPString のいずれかによる空でない列です >>1

[2] IA5String は含まれていません。

[14] RFC 5280 プロファイルに適合する CA は、 原則として PrintableStringUTF8String を用いなければなりません >>1, >>20

[15] CA が従来 issuer において TeletexString, BMPString, UniversalString証明書発行していたなら、 後方互換性のため引き続きこれを利用しても構いません >>1

[16] 既存の CA>>15 のような証明書を発行しているところに新しい CA を追加する場合、既存の CA が使っているものと同じ方法で属性符号化して構いません。 >>1

[22] 証明書subjectCA の場合には、 >>15 のような issuerCA証明書で使われているなら、それと同じ方法で符号化しなければなりません >>20

[23] 証明書subjectCRL発行者の場合には、 当該CRL発行者発行する CRLissuer と同じ方法で符号化しなければなりません >>20

[24] 既存の subject に新しい証明書を発行する場合や、 他の subject に発行した証明書で既に符号化された属性を新たな subject に発行する場合には、 TeletexString, BMPString, UniversalStringsubject符号化して構いません。 >>20

[25] 証明書利用者は、 TeletexString, BMPString, UniversalStringsubject の受信にも備えるべきです >>20。しかし対応は義務ではありません >>27

Unicode への変換

[10] RFC 4518LDAPstringprep においては、 転符号化 (Transcoding) 手順において Unicode に変換する方法が規定されています。

[12] PrintableString は、直接 Unicode へと転符号化します >>9

[13] UniversalString, UTF8String, bmpString は、既に Unicode なので転符号化は不要です >>9

[17] TeletexString は、 Unicode転符号化します。 ただし標準の写像はありませんから、実装に委ねられます。 これもあって、 TeletexString は使うべきではありません>>9

比較

[7] RFC 4517 は、文字列に関する次の比較演算を規定しています >>6

[8] これらは RFC 4518Stringprep 変種を使って正規化して比較します。

[18] インターネットPKIにおいては、実装は PrintableStringUTF8Stringdistinguished name 属性比較に当たり RFC 4518 が規定する stringprep プロファイルを適用しなければなりません。 実装は caseIgnoreMatch による比較に対応しなければなりません。 それ以外の比較方式を使う属性型への対応は必須ではありません。 >>27

caseIgnoreMatch のための stringprep では、 Map 手順で RFC 3453 表B.2 を用いた case folding を行います。 また Insignificant Character Removal 手順で Insignificant Space Handling を用います。 >>27 詳しくは stringprep を参照。
[21] CNドメイン名IPアドレスservice identity 検証のために比較する場合も理論上は本規定が適用されるのかもしれませんが、 実際には ASCII文字のみで構成されるため (IDNAラベルに変換され、 IPアドレスもバイト列ではなく文字列表現となるため)、事実上本規定の影響は受けません。 CNservice identity を参照。

関連

T51String

メモ

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

Some legacy implementations support names encoded in the ISO 8859-1

character set (Latin1String) [ISO8859] but tag them as TeletexString.

TeletexString encodes a larger character set than ISO 8859-1, but it

encodes some characters differently. The name comparison rules

specified in Section 7.1 assume that TeletexStrings are encoded as

described in the ASN.1 standard. When comparing names encoded using

the Latin1String character set, false positives and negatives are

possible.

[26] 自堕落な技術者の日記 : OpenSSLで対応しているDirectoryStringType一覧 - livedoor Blog(ブログ) ( 版) http://blog.livedoor.jp/k_urushima/archives/597202.html

[28] RFC 7612 - Lightweight Directory Access Protocol (LDAP): Schema for Printer Services ( 版) https://tools.ietf.org/html/rfc7612#section-1.4.1

DirectoryString

[29] 1088998 – ssl_error_bad_cert_domain on some Akamai-hosted sites (developer.nvidia.com, schwabcdn.com) due to lack of subjectAltName and TeletexString-encoded Subject CN ( ()) https://bugzilla.mozilla.org/show_bug.cgi?id=1088998

"The issue with the www.joes-ssl.com certificate is mainly that it doesn't use an escape sequence to specify that it's using one of the JIS encodings... and while the MS CryptoAPI apparently uses heuristics for figuring out the correct set, NSS always treats TeletexStrings as ISO-8859-1 strings (http://mxr.mozilla.org/mozilla/source/security/nss/lib/certdb/secname.c?mark=654-661#643)."

[30] 1089104 – ssl_error_bad_cert_domain when subjectAltName extension is missing and Subject CN is encoded as TeletexString ( ()) https://bugzilla.mozilla.org/show_bug.cgi?id=1089104

[32] 1089104 - ssl_error_bad_cert_domain when subjectAltName extension is missing and Subject CN is encoded as TeletexString () https://bugzilla.mozilla.org/show_bug.cgi?id=1089104

[33] 245609 - Mozilla not getting certificate issuer from Authority Information Access CA Issuers () https://bugzilla.mozilla.org/show_bug.cgi?id=245609#c20