自堕落な技術者の日記

デジタル証明書では、証明書の主体者名、発行者名なんかを文字列で指定します。PrintableStringには文字種の制限がありますが、UTF8String、TeletexString、BMPStringなんかを使った場合には文字種の制限があまりなく、改行や特殊文字なんかも入れてダメとは書いてありません。(入れていいかどうかは別です。CP/CPSの証明書プロファイルで制限を設けているケースもあります。)

とある近い国の証明書なんかはCNに改行がバリバリ入っており、証明書識別名を本当にメモ帳代わりに使っています。

手持ちのChallenge PKI Test Suiteでは、4年ぐらい前から識別名を部分的だったり全体的に16進数で指定したり、改行"\r\n"なんかのエスケープ文字にも対応しています。

Windowsの証明書ビューアーでは、属性の表示領域が9行あります。識別名のRDNを表示させると、最初の一行目はRDNの属性タイプ(O=とかCN=とか)が表示されるので、まぁ、文字のレイアウトの都合上(面倒なので)使わないとして、8行は自由に使ってよいことになります。

久しぶり(3年ぐらいぶり)に作ってみると、こんな感じ、、、、





んん〜〜っ、左側がもったいないので、もう少し横長で8行のアスキーアートを入れてみるとこんな感じ、、、





VeriSignの発行する証明書には入っていることもあるRFC 3709のロゴタイプX.509v3拡張という組織のロゴ画像や音声などを証明書に埋め込むっていうのもあるんですが、証明書ビューアーの方が対応していないので、フツーはこれ見られませんよね。もったいない、、、、ロゴタイプ拡張の代わりにアスキーアートが使えたら面白いんじゃないかと思います。

ただ実際は、CNやOUとかには何文字までっていう制限があるので使えないんですけどね、、、、、残念、、、、証明書ポリシ拡張のUserNoticeの中でもたった200文字か、、、もうちょっと長く使えるの無いかな、、、、

RFC 3280 Appendix: A.1 Explicitly Tagged Module, 1988 Syntax

　　：中略

--  specifications of Upper Bounds MUST be regarded as mandatory

--  from Annex B of ITU-T X.411 Reference Definition of MTS Parameter

ub-common-name INTEGER ::= 64

ub-organization-name INTEGER ::= 64

ub-organizational-unit-name INTEGER ::= 64

　　：以下略

あ、そっか、文字数の制限をクリアするには例えば行の先頭は"L = "(locality)固定でいけば先頭にゴミは付いちゃうけど、文字数制限はクリアできるか、、、、、





ちなみにこの64っていうのは64バイト(=64オクテット)ではなくて、64文字です。UTF-8エンコーディングだと日本語1文字が普通3バイトぐらいになっちゃうんですが、日本語1であろうが1文字としてカウントされます。この辺りは日本やアスキーアート（＾＾；では大事なところです。

EVガイドラインのドラフトは間違っていたので、修正依頼をCAB Forum事務局に送って bytes から characters に直してもらえました。

自堕落な技術者の日記 : OpenSSLでNumericStringの入った証明書が読み込めない - livedoor Blog（ブログ）

RFC 3280では規定外になりますが識別名にNumericStringを含む証明書を作ってみて、そのPKCS#12を作ろうとOpenSSLで読み込ませてみたら見事にエラーになりました。

前のブログでOpenSSLでNumericStringを識別名に含む証明書を読み込むとエラーになると書きましたが他はどうなのか(別の調査のついでに)調べてまとめてみたのが以下です。

DirectoryString Type	Tag	OpenSSL サポート※1	RFC3280 Issuer※2	RFC3280 Subject※3
UTF8String	0c	○	○	○
NumericString	12	×	×	×
PrintableString	13	○	○	○
TeletexString	14	○	○	○
VideotexString	15	×	×	×
IA5String	16	○	×	○
GraphicString	19	×	×	×
VisibleString	1a	×	×	×
GeneralString	1b	×	×	×
UniversalString	1c	○	○	○
BMPString	1e	○	○	○

※1: OpenSSL 0.9.8hで証明書識別名で使われているものを読み込んだ際、エラー終了しなければ「○」
※2: RFC 3280 4.1.2.4でIssuerに使ってよいとしているDirectoryString Typeであるか
※3: RFC 3280 4.1.2.6 SubjectではIssuerのものに加え過去との互換性からメールアドレスにIA5Stringをつかってもよい。


X.680で定義されている文字列を扱うプリミティブをリストにしました。OpenSSLは0.9.8hで確認しました。RFC 3280でサポートされているDirectoryString Typeしかサポートしてないんですね。

読めなかったときのエラーはこんな感じです。

% openssl x509 -inform DER -noout -txt -in EE-ECOM-XMLDN-DS-VIDEOTEX-ASCII.cer
unable to load certificate
24264:error:0D07808C:asn1 encoding routines:ASN1_ITEM_EX_D2I:mstring wrong tag:tasn_dec.c:228:Type=ASN1_PRINTABLE
24264:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:749:Field=value, Type=X509_NAME_ENTRY
24264:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:710:
24264:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:710:
24264:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:749:Field=issuer, Type=X509_CINF
24264:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:749:Field=cert_info, Type=X509

自分の苗字は面倒臭い方の、上に「山」、下に「鳥」書く「嶌」なんですが、初めて同じ「嶌」の方とお仕事でお会いしました。名前が面倒臭いと相手に説明するのも面倒で、ひどいと「蔦(つた)」と間違えられることもあります。一応JIS第二水準の漢字(シフトJISコード：9BB8)なんですよね。

その方は新しく戸籍を作られる際、市役所の人が「パソコンで入れられる普通の『島』に変えてもらえませんか？」と言われたそうです。それはちょっとヒドイなぁ、、、と、、、システムに無い漢字なら仕方ないかもしれませんが第二水準漢字だし、上の方から譲り受けた物なわけですから、、、、

親も教えてくれなかったし、自分も昔はこんな難しい「島」だとは大学生まで知らなくてパスポートを作った際に戸籍見て初めて難しい方なんだと知りました。おじいさんが亡くなる前まで普段は簡単な方使っていたんですが、亡くなって「嶌」使い出してからちょっとツイてきたような気がするので、それからはずっと面倒くさい方を使っています。

アジアPKIの実験の時に台湾の方から聞いたんですが、台湾ではそもそも繁体時という複雑な方の漢字をつかっているんですが、子供が生まれた時に新しい漢字を作ってしまったりするそうです。そりゃUnicode BMPでも収まりきらないし、Windowsでもなかなか表示できないですよね。証明書のDNでもこうした漢字が入るわけですが、UTF-8にした際に4バイト以上になっちゃいますもんね。

昔、CAB ForumのEV証明書のガイドラインのDraft11の時に証明書のOU(組織の部署名)について

EV Certificate Guideline Draft11 D.6.(a)(1) Organization name

If the combination of the full legal organization name and the assumed or d/b/a name exceeds 64 bytes as defined by RFC 3280, the CA SHOULD use only the full legal organization name in the certificate.

となっていてOUには64バイトしか使えないというのでRFCの方を確認したところ

RFC 3280 Appendix A.1

ub-organization-name INTEGER ::= 64

-- Note - upper bounds on string types, such as TeletexString, are
-- measured in characters. Excepting PrintableString or IA5String, a
-- significantly greater number of octets will be required to hold
-- such a value. As a minimum, 16 octets, or twice the specified
-- upper bound, whichever is the larger, should be allowed for
-- TeletexString. For UTF8String or UniversalString at least four
-- times the upper bound should be allowed.

とあり、OUの値の上限は64バイトではなく64文字であることがわかりました。そこで、CAB Forumに指摘のメールを送ったところ、CAB Forumの議長であるEntrustのTim Mosesから該当部分のエディタに「指摘は正しいと思うんだけど、異論がなければ直してね」というメールが送られました。(CCが来ました)

ガイドラインの1.0では無事64文字に修正されています。

将来、日本のEV証明書でUTF8Stringで日本語の商号が入るかどうかはわからないんですけどね、、、64バイトというと日本語ではUTF-8エンコーディングで大体21文字なので最近の長いカタカナの商号の会社なんかは引っかかるかもしれないですよね。

＜関連ページ＞
OKWave: ＪＩＳコードと句点コードと１６進法
http://okwave.jp/qa546874.html