自堕落な技術者の日記 : XAdESにおける発行者名前比較の問題(第4回)

≪前回第3回へ

なんか忙しくって随分時間が空いてしまってゴメンナサイｍ（＿　＿）ｍ
今回はいよいよRFC 2253で証明書識別名を文字列で表すところの紹介です。

識別名の文字列変換方式を定めたRFC 2253

RFC 2253 'Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names' とは、証明書中の発行者名や主体者名などの名前(X500Name)やディレクトリエントリの識別名をUTF-8エンコーディングされた国際化文字列に変換するルールを定めたものです。

XAdESの発行者名はRFC 2253により文字列変換された後にXML要素として格納されるので今回はこのRFC 2253について見ていきましょう。

幸いIPAでRFC 2253の和訳がありますのでこちらをご覧ください。

http://www.ipa.go.jp/security/rfc/RFC2253JA.html (IPA和訳)
http://tools.ietf.org/html/rfc2253.html (原文)

識別名の文字列変換は以下のような目的で必要となります。
(1) ディレクトリの検索・追加・変更のための文字列形式の検索キーを作るため
(2) ディレクトリエントリを表示するため
(3) 証明書・CRL・OCSPなどで使われる名前を表示するため

識別名自体はASN.1構造化バイナリ表現されたものですから、これをどのような識別名が与えられたとしても文字列で表現できるようにしたのがRFC 2253です。

変換ルールをまとめたのが以下です。(ちっともまとまってない（＾＾；)

RDNの並びはRDNの末尾から先頭に向かってカンマ","繋ぎで表す

RDNの中に複数AttributeTypeAndValueがある場合(Multi AVA)にはプラス'+'で繋ぐ(例：CN=Taro+OU=Foo)

AttributeTypeAndValue は「AttributeTypeの文字列=AttributeValueの文字列」

AttributeTypeはRFC 2252に関連する表(即ちRFC 2256)にあればその文字列を使う(全部小文字なことに注意)

表にない場合、10進ドット表記(例 "0.1.2.34.456") が使われる

よくあるAttributeTypeの文字列表現はCN,L,ST,O,OU,C,STREET,DC,UIDなどの例がある(※あくまで例です。大文字であることも注意) (2.3節)

AttributeValueが文字列できなければ"#1f3df..."のようなBER16進表現で (2.4節)

AttributeValueが以下を含む場合エスケープする (2.4節)

値文字列が空白か"#"で始まるならバックスラッシュ'\'でエスケープ

値文字列の終わりが空白文字ならエスケープ

',', '+', '"', '\', '<', '>', ';'の場合

AttributeValueでは他の文字もエスケープしてよい

AttributeValueではエスケープ文字は16進表現'\xx'でもよい

旧仕様RFC 1779の構文も受け入れなければならない(MUST) (4節)

RDN区切りのカンマ','の代わりにセミコロン';'も受け入れる(MUST) (4節)

カンマやセミコロンの両側の空白を許す(MUST) (4節)

AttributeTypeがOID表現の場合には"oid."もしくは"OID"が前についても受け入れる(MUST) (4節)

RFC 2253の例で示されている識別名はこんな感じです。

CN=Steve Kille,O=Isode Limited,C=GB
OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
CN=Before\0DAfter,O=Test,C=GB
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
SN=Lu\C4\8Di\C4\87

RFC 2253で変換した識別名文字列は一意じゃない！

ある識別名から上で説明したRFC 2253の変換規則を使って文字列にしてみると、いろんな表現方法があって一つには決まらないってことがよくわかります。例えば

OU=Test,C=JP

を考えてみましょう。

ざっと思いつくRFC 2253識別名文字列はこんな感じです。

O=Test,C=JP　　　　RFC 2253例にもある普通の表現

o=Test,C=JP　　　　RFC 2256の表ではAttributeTypeは小文字になっている

O=Test_,_C=JP　　　RDNの区切りの前後に空白があってよい

O=Test;C=JP　　　　RDNの区切り文字はセミコロンでもよい

O=Tes\74,C=JP　　　値の文字をエスケープしてもよい

O=#310D300B060355040A130454657374,C=JP　値がBER16進数でだめとは書いてない

2.5.4.10=#310D300B060355040A130454657374,C=JP　ドットなら値BERはSHOULD

oid.2.5.4.10=#310D300B060355040A130454657374,C=JP　"oid."をつけてよい

OID2.5.4.10=#310D300B060355040A130454657374,C=JP　"OID"をつけてよい

※空白文字はアンダーバー"_"で表示しています。

どうです？これだけ表現方法があって一意には決まらないんです。RFC 2253の文字列一致比較が単純にはうまくいかないことが、おわかり頂けたでしょうか？

それ故にXAdESの識別名の文字列比較は厄介なのです。

じゃぁ、作ればいいじゃん、、、と、RFC 2253の文字列比較に完全に対応しようとしている貴方、、、、止めた方がいいと思いますよ。砕け散った埴輪の復元作業みたいなもんです。完全には元には戻らないので単純に比較はできません。

文字列からASN.1 DERやBERバイナリを復元しようとする無駄なこともやってはいけません。(RFC 2253 7.2 参照) (手持ちのXAdESの実装は一致比較のためにコレをやっちゃっています（＾＾；)

今日は随分長くなってしまったので、この辺で終りにしましょう。
次回はRFC 2253の文字列比較の相互運用性上問題になりそうな~~ど～～でもよい~~ところを~~うじうじ、ちくちく~~細かく見ていこうと思います。