前から書こうと思っていたんですが、やっと時間が取れそうなのでXML形式の長期署名フォーマットXAdESにおける証明書等の名前比較の問題提起について数回に分けて触れていこうと思います。
W3CのXML署名(XMLDSIG)を拡張した長期署名フォーマットであるXAdESでは、署名者が署名に用いた証明書やこれを検証に用いた証明書、証明書失効リスト(CRL)、OCSP応答が将来不正に置き換えができないように以下のような検証情報のリストをSigningCertificate、CompleteCertificateRefs、CompleteRevocationRefsとったプロパティに保持しています。
先に例を示した方が早いと思うので、SigningCertificateプロパティの具体例を示しておきます。このプロパティを使って検証時に正しい署名者証明書であることを確認するわけです。
署名者証明書や証明書チェーンの検証参照情報を以下にまとめておきます。
一般論からすればこれら3種の値が一致していれば、この証明書・CRL・OCSP応答は検証に使用しなければならない検証情報ということになりますが、XAdESの場合には現状の標準に照らして「発行者の名前は必ずしも一致するとは限らない」というのが今回の問題提起のメインテーマです。
CAdESやXMLDSigでは起きないこの問題はXAdESだけに固有の問題であり、検証情報の完全性についてCAdESに比べてXAdESには不備があるということです。
発行者名とは
のようなものですが、証明書中の識別名からこの文字列を作る作り方はRFC 2253で定められています。皆さんも上の名前のバリエーションとして
みたいなものを見かけますが、これだと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との差異
・第9回(最終回) まとめと今後のXAdESの改訂
はじめに
W3CのXML署名(XMLDSIG)を拡張した長期署名フォーマットであるXAdESでは、署名者が署名に用いた証明書やこれを検証に用いた証明書、証明書失効リスト(CRL)、OCSP応答が将来不正に置き換えができないように以下のような検証情報のリストをSigningCertificate、CompleteCertificateRefs、CompleteRevocationRefsとったプロパティに保持しています。
先に例を示した方が早いと思うので、SigningCertificateプロパティの具体例を示しておきます。このプロパティを使って検証時に正しい署名者証明書であることを確認するわけです。
<SigningCertificate>
<Cert>
<CertDigest>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>nKmgzpXJg0+yJvxz5fmjNG3zWUs=</ds:DigestValue>
</CertDigest>
<IssuerSerial>
<ds:X509IssuerName>CN=Root CA,O=Entrust,C=JP</ds:X509IssuerName>
<ds:X509SerialNumber>123</ds:X509SerialNumber>
</IssuerSerial>
</Cert>
</SigningCertificate>
署名者証明書や証明書チェーンの検証参照情報を以下にまとめておきます。
- 証明書・CRL・OCSP応答データのハッシュ値
- 発行者の名前
- 証明書シリアル番号、CRL番号(CRLNumber)、CRL発行日時(thisUpdate)、OCSP応答発行者の鍵ハッシュ、OCSP応答生成日時(ProducedAt)等の付加情報
| プロパティ | 説明 |
|---|---|
| SigningCertificate | 署名者証明書を特定するための証明書データの拇印(ハッシュ値)、証明書発行者名、シリアル番号を保持するプロパティ |
| CompleteCertificateRefs | (署名者)証明書を検証するための署名者証明書からルート証明書までの証明書の並び、即ち証明書チェーンを構成する全ての証明書について上記の拇印、発行者名、シリアル番号を保持するプロパティ |
| CompleteRevocationRefs | (署名者)証明書を検証するための証明書チェーンの検証に必要な失効情報、つまり構成する個々の証明書に対するある時点でのCRLやOCSP応答を特定するための拇印、発行者名(Issuer or ResponderID.byName)、発行日(thisUpdate or ProducedAt)、番号(CRLNumber)などを保持するプロパティ |
一般論からすればこれら3種の値が一致していれば、この証明書・CRL・OCSP応答は検証に使用しなければならない検証情報ということになりますが、XAdESの場合には現状の標準に照らして「発行者の名前は必ずしも一致するとは限らない」というのが今回の問題提起のメインテーマです。
CAdESやXMLDSigでは起きないこの問題はXAdESだけに固有の問題であり、検証情報の完全性についてCAdESに比べてXAdESには不備があるということです。
発行者名とは
CN=Root CA,O=Entrust,C=JP
のようなものですが、証明書中の識別名からこの文字列を作る作り方はRFC 2253で定められています。皆さんも上の名前のバリエーションとして
CN=Root CA, O=Entrust, C=JP (カンマ後ろに空白がありRFC 2253違反)
C=JP,O=Entrust,CN=Root CA (逆順でありRFC 2253違反)
cn=Root CA,o=Entrust,c=JP (属性名が小文字になっておりRFC 2253違反)
みたいなものを見かけますが、これだとXAdESで発行者名を文字列比較することができません。それでは、RFC 2253に違反しているんだから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との差異
・第9回(最終回) まとめと今後のXAdESの改訂
