最近、セキュリティ関係のニュースを見逃すことが多くて申し訳ないんですが、2010年6月10日にIETF SMIME Working Groupのメーリングリストでインターネットドラフト「Additional CMS Revocation Information Choices」がIESGに承認されProposed Standardになったとアナウンスがありました。
CMS署名データのcrlsフィールドには、元々X.509かデータ型を表すOIDの規定された失効情報が格納できるようになっていたんですが、そのOIDが他で全く規定されていないためにOCSPレスポンスやSCVPのデータが格納できないようになっていました。
特にOCSPレスポンスを標準で格納できるようになったことは、タイムスタンプ付きのCAdES/XAdESを長期保存することを考えている方々には朗報なんじゃないかと思います。
CMS署名における失効情報の格納
CMS署名データには失効情報を格納するためにcrlsフィールドというものがあり、ここに格納できるASN.1シンタックスの定義は以下のようになっています。
RevocationInfoChoices ::= SET OF RevocationInfoChoice
RevocationInfoChoice ::= CHOICE {
crl CertificateList,
other [1] IMPLICIT OtherRevocationInfoFormat }
OtherRevocationInfoFormat ::= SEQUENCE {
otherRevInfoFormat OBJECT IDENTIFIER,
otherRevInfo ANY DEFINED BY otherRevInfoFormat }
OCSPレスポンスの格納
今回、このProposed Standardができたことにより、OCSPレスポンスを格納する場合には
otherRevInfoFormatにid-ri-ocsp-response "1.3.6.1.5.5.7.16.2"
を指定すればotherRevInfoにOCSPレスポンスを入れられるようになったのです。
CAdES、XAdESおよびタイムスタンプの長期保存に与える影響
今回のProposed Standard化の意義を深く考えている人はそう多くないんじゃないかと 思うんですが、自分としては心待ちにしていた標準化だったりします。 それは、
- アーカイビングの際、タイムスタンプ検証用の失効情報にOCSPが使いやすくなる。
- XAdES用のタイムスタンプ検証情報の格納にcrlsフィールドが使えるようになる。
タイムスタンプ検証情報にOCSPが使える事の意義
長期署名において署名やタイムスタンプを検証するためにCRLを使った場合、 そのCRLが検証するのに十分な猶予期間を持って取得されていることを考慮する必要があります。 簡単に言っちゃうと、署名をしたまさにその時刻にCRLを取得して含めたのではダメで、 署名時刻に失効申請たとしてそれが次のCRLに反映されるまでの十分な時間待ってから 取得したCRLを使わなければいけません。 毎日発行されるCRLならば割と話は簡単で数営業日待てばいいんですが、 CRLの発行周期が1ヶ月とか失効申請の都度CRLを発行するようなケースだと 適切なCRLかどうかを判断するのはすごく難しいです。 特に、サブCAやタイムスタンプ局証明書用のの失効情報については局によって例えば1ヶ月や 1年といった周期のところが多いので、次のアーカイビングを行うための待ち時間は 尋常ではなく、一般的な実装ではあきらめてしまっているケースが多いのではないでしょうか。 CRLでは、いつ取得したCRLであるかを第三者に示す仕掛けが無いために苦労するわけです。 OCSPレスポンスを使えば、所詮CRLを元にOCSPレスポンスを発行するので情報の新鮮さ は同じだったとしても、失効情報を取得した時間は明らかにできるので 猶予期間をまともに扱う事ができるようになるわけです。
XAdES中のタイムスタンプの失効情報にOCSPレスポンスが使える
タイムスタンプ局証明書がOCSPでしか失効情報を提供していない、または敢えて OCSPを使わなければならないってことが相互運用テストの場合にはあったりします。 XAdESの数世代のアーカイブタイムスタンプを行う場合には少し厄介で、 アーカイブタイムスタンプの検証情報はXAdES 1.4.1だったとしても タイムスタンプトークンの中に含めるしかなく、今回のProposed Standardが 出てくる前はcrlsフィールドには格納できなかったので、 CAdESと同等の非署名属性を用いてタイムスタンプトークンに格納する しかありませんでした。 XAdESを実装したいのにタイムスタンプのためのCMS実装だけでは 不十分でCAdESの属性まで扱える必要があったのです。 今回のProposed Standardを使えば、XAdESのアーカイブタイムスタンプの OCSPレスポンスによる失効情報をCMSの標準の範囲内で含めることができるわけです。
夏休みの宿題で自前のライブラリでOCSPレスポンスの格納に対応させようかなぁ。 早くこれがDraft Standard、Standardと進んで行くといいなぁ、と思っています。
