≪第2回へ
前回はETSI 101 903 XAdES v1.3.2における発行者識別名の一致検証の記述について説明しました。
今回は、XAdESと似たCMSバイナリ形式の長期署名フォーマットCAdESだってSigningCertificate、CompleteCertificateRefs、CompleteRevocationRefsが同じようにあるのに何故CAdESでは問題にならないのか、また、XAdESの元の仕様であるXML署名を規定したXMLDSigだってIssuerSerialはあるのに何故問題にならないのか、RFC 2253の説明に入る前に少し寄り道して説明したいと思います。
RFC 3280 4.1.2.4 Issuerで記述されているように証明書の発行者や主体者の識別名はX.501のName型として定義されています。ASN.1構造の定義はこんな感じ、、、、
具体例を示すと、以下が証明書中の名前(Name)であり相対識別名(Relative Distinguished Name)の並び(SEQUENCE)で表されます。
並びの順序は証明書のためのエントリがディレクトリに登録されて際のDIT(Directory Information Tree)の上から順に格納します。通常は国(C=JP)やドメインコンポーネント(DC=COM)なんかが上にきます。
そして部分的に取り出していくと、以下が相対識別名
これが属性タイプと値の組(AttributeTypeAndValue)になります。
上の名前(Name)の例をRFC 2253で文字列表現にすると
のようになるわけです。
前述の
CAdESでは、発行者識別名ASN.1構造の識別名オクテット(=バイト列)をそのまま検証情報参照情報として持っているので、証明書・CRL・OCSP応答中の発行者識別名との一致確認はそのままバイト単位で比較するため厳密な一致確認が可能です。
以前、ECOMの実証実験では名前をそのままバイトコピーせず、自分で作り直したために例えばPrintableStringがUTF8Stringに変わってしまい、一致しなかったなどというケースもありましたが、今は実験に参加している実装でそのような不具合は無いと思います。
W3C XMLDSigではW3C 4.4.4 The X509Data Elementで規定されているように署名者の鍵や証明書などを格納するKeyInfo要素の中にX509IssuerNameやX509SubjectName要素として証明書の識別名が入れられるようになっています。
このX509IssuerNameやX509SubjectNameもRFC 2253により証明書中の発行者名、主体者名を文字列にして保持するわけですが、特に比較して一致しなければならないとかいう検証要件はありません。それは、証明書を何らかのサービスやシステムから取得するために参考として用いる名前であって、検索できさえすればよく一致している必要は無いのです。このため、XMLDSigではRFC 2253で生成される結果が一意でなかったとしても問題とはならないのです。
一方 XAdES では、完全性確認のめにRFC 2253文字列が使われますから、一意でないと一致せずにエラーということになります。
以上、今回はCAdESやXMLDSigでは名前一致が問題にはならず、XAdESだけの問題であるという事を見てきました。
次回はRFC 2253そのものについてと、RFC 2253で単純に文字列比較なんかできないということの入り口までたどり着けると良いと思っています。
ではでは
XAdESの証明書識別名の比較問題 (もくじ)
・第1回 はじめに
・第2回 XAdESにおける名前比較の要件
・第3回 なぜCAdESやXMLDSigでは問題とならないのか
・第4回 RFC 2253による識別名バイナリの文字列化
・第5回 RFC 2253識別名文字列を比較する際の相互運用性阻害要因
・第6回 RFC 2253識別名文字列を生成する実装の紹介とテストの概要
・第7回 RFC 2253識別名文字列を生成する実装の標準準拠性テスト結果
・第8回 XMLDSig Second Editionでも参照されるRFC 2253の改訂版RFC 4514との差異
前回はETSI 101 903 XAdES v1.3.2における発行者識別名の一致検証の記述について説明しました。
今回は、XAdESと似たCMSバイナリ形式の長期署名フォーマットCAdESだってSigningCertificate、CompleteCertificateRefs、CompleteRevocationRefsが同じようにあるのに何故CAdESでは問題にならないのか、また、XAdESの元の仕様であるXML署名を規定したXMLDSigだってIssuerSerialはあるのに何故問題にならないのか、RFC 2253の説明に入る前に少し寄り道して説明したいと思います。
証明書・CRL・OCSP応答の(発行者)識別名の定義と例
RFC 3280 4.1.2.4 Issuerで記述されているように証明書の発行者や主体者の識別名はX.501のName型として定義されています。ASN.1構造の定義はこんな感じ、、、、
Name ::= CHOICE { RDNSequence }
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::= SET OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
value AttributeValue }
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY DEFINED BY AttributeType
(RFC 3280 4.1.2.4 Issuerより)
具体例を示すと、以下が証明書中の名前(Name)であり相対識別名(Relative Distinguished Name)の並び(SEQUENCE)で表されます。
SEQUENCE {
SET { SEQUENCE {OID countryName, PrintableString 'JP'} }
SET { SEQUENCE {OID organizationName, PrintableString 'Entrust'} }
SET { SEQUENCE {OID commonName, PrintableString 'Root CA'} } }
並びの順序は証明書のためのエントリがディレクトリに登録されて際のDIT(Directory Information Tree)の上から順に格納します。通常は国(C=JP)やドメインコンポーネント(DC=COM)なんかが上にきます。
そして部分的に取り出していくと、以下が相対識別名
SET { SEQUENCE {OID countryName, PrintableString 'JP'} }
これが属性タイプと値の組(AttributeTypeAndValue)になります。
SEQUENCE {OID countryName, PrintableString 'JP'}
上の名前(Name)の例をRFC 2253で文字列表現にすると
CN=Root CA,O=Entrust,C=JP
のようになるわけです。
CAdESにおける検証情報の発行者名比較
前述の
CN=Root CA,O=Entrust,C=JPの識別名を証明書から取り出してASN.1のバイト列表現に変換するとこのようになりますSEQUENCE {
SET { SEQUENCE { OID countryName, PrintableString 'JP' } }
SET { SEQUENCE { OID organizationName, PrintableString 'Entrust' } }
SET { SEQUENCE { OID commonName, PrintableString 'Root CA' } } }
↓↓ASN.1でエンコードすると以下のバイト列になります
30:31:
31:0B:30:09:06:03:55:04:06:13:02:4A:50:31:10:30:0E:06:03:55:04:0A
31:10:30:0E:06:03:55:04:0A:13:07:45:6E:74:72:75:73:74
31:10:30:0E:06:03:55:04:03:13:07:52:6F:6F:74:20:43:41
CAdESでは、発行者識別名ASN.1構造の識別名オクテット(=バイト列)をそのまま検証情報参照情報として持っているので、証明書・CRL・OCSP応答中の発行者識別名との一致確認はそのままバイト単位で比較するため厳密な一致確認が可能です。
以前、ECOMの実証実験では名前をそのままバイトコピーせず、自分で作り直したために例えばPrintableStringがUTF8Stringに変わってしまい、一致しなかったなどというケースもありましたが、今は実験に参加している実装でそのような不具合は無いと思います。
何故、W3C XMLDSIGでは問題にはならないのか
W3C XMLDSigではW3C 4.4.4 The X509Data Elementで規定されているように署名者の鍵や証明書などを格納するKeyInfo要素の中にX509IssuerNameやX509SubjectName要素として証明書の識別名が入れられるようになっています。
このX509IssuerNameやX509SubjectNameもRFC 2253により証明書中の発行者名、主体者名を文字列にして保持するわけですが、特に比較して一致しなければならないとかいう検証要件はありません。それは、証明書を何らかのサービスやシステムから取得するために参考として用いる名前であって、検索できさえすればよく一致している必要は無いのです。このため、XMLDSigではRFC 2253で生成される結果が一意でなかったとしても問題とはならないのです。
一方 XAdES では、完全性確認のめにRFC 2253文字列が使われますから、一意でないと一致せずにエラーということになります。
以上、今回はCAdESやXMLDSigでは名前一致が問題にはならず、XAdESだけの問題であるという事を見てきました。
次回はRFC 2253そのものについてと、RFC 2253で単純に文字列比較なんかできないということの入り口までたどり着けると良いと思っています。
ではでは
XAdESの証明書識別名の比較問題 (もくじ)
・第1回 はじめに
・第2回 XAdESにおける名前比較の要件
・第3回 なぜCAdESやXMLDSigでは問題とならないのか
・第4回 RFC 2253による識別名バイナリの文字列化
・第5回 RFC 2253識別名文字列を比較する際の相互運用性阻害要因
・第6回 RFC 2253識別名文字列を生成する実装の紹介とテストの概要
・第7回 RFC 2253識別名文字列を生成する実装の標準準拠性テスト結果
・第8回 XMLDSig Second Editionでも参照されるRFC 2253の改訂版RFC 4514との差異
