自堕落な技術者の日記

基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通

ETSI

IETF S/MIME WGのMLにもテストの案内

Fwd: Invitation to the ETSI 3rd Remote XAdES/CAdES Plugtests


IETF S/MIME ワーキンググループもメーリングリストにもプラグテストの案内を出させて頂きました。

OpenXAdESのXAdES-XLの検証依頼

最近、たま〜〜にいろんなところから、XAdESやCAdESの署名が送られてきて、検証してみてください、、、、と来ることがあります。ありがたい話です。

一昨日、エストニアのオープンソースのXAdES長期署名のライブラリのプロジェクトOpenXAdESをやっているSK(www.sk.ee)という会社の人から「検証してちょ」と連絡が来ました。

この人は去年のプラグテストにも参加していて、その時も署名に誤りがあって「×」をつけたんですが、直ったのでまた検証してみてくださいとの事でした。

SigAndRefsTimeStampのついたXAdES-XLなんで早速検証してみるに、タイムスタンプトークンのXAdESプロパティを読み込む際にエラーになっており、トークンの部分のBase64を取り出してみるにTimeStampTokenでなくてTimeStampResp(タイムスタンプ応答)が入ってしまっていました。

これって、前もエラー報告出したんですが直ってなくて残念、、、、

一連のXAdESのDN問題のブログ記事で書いた通り使っている証明書が問題が起きがちなもので、出てきたDNの文字列を見るとRDNの順序もおかしいし、G=とかemailAddress=とかが入っているので、一致検証も難しそうな雰囲気です。検証側の問題ですが、ここのもnonRepudiationビットだけの証明書が、、、(こちらを参照)

まぁ、オープンソースといってもピンキリですな、、、、、

メジャーではないオープンソースはトホホな実装のものが多いですな。どれだけ多くの人がコードをレビューしたかってことなんでしょうな、、、、、

PDF長期署名

ISOにもなっているPDF(1.7 ISO 32000-1)のドキュメントを長期保存するときに、そのままではCAdES(ETSI TS 101 733, RFC 5126)などの長期署名フォーマットで保存することが難しかったため、3年ほど前からECOMで木村さんが主体的にうまい格納方法を考え、ETSI ESIとAdobe (or ISO TC171)に継続的にインプットしてくれました。

それが、ようやく昨年ぐらいに実を結びETSIのCAdES/XAdESの専門家とAdobeのメンバがタッグを組みETSI STF364 Advanced Electronic Signatures for PDFにおいてPDFの長期署名のための標準化を行っています。

現在、PDF 1.7 (ISO 32000-1)ベースに、CAdES長期署名を用いて長期保存するためのプロファイルのドラフトがETSI ESI内でレビューされています。

木村さんの提案した増分更新による(CAdESを使った長期)署名延長は「PDF serial signature」と ちゃんとした名前もつきましたし、私がECOMから提案してきたPKCS#7とCAdESとの差異の吸収によりPKCS#7の代わりにCAdESを入れても(ほぼ)問題無くなったかと思います。

ドラフトではPDF/Aとの関係についても(まぁ)解決されています。

コメントの締め切りは1月26日で、2月9日までにコメントが無ければESIで承認されたことになるそうです。(既にコメントは出ていますが、、、)

幾つか心配な事があるので、コメントしないといけません。

4th ETSI Security Workshop開催中

2009.01.13(火)〜14(水)の日程で4th ETSI Security Workshopをやっています。

ワークショップサイト
http://www.etsi.org/SECURITYWORKSHOP
プレゼン置き場
http://portal.etsi.org/docbox/Workshop/2009/200901_SECURITYWORKSHOP

13日 15:00 - 16:00 SESSION 3: PRIVACY
 ETSI Electronic Signatures Activities
  Riccardo Genghini, ESI Chairman
  (スライドPDF)


ETSI ESIのジンジアーニ議長がESIの話をします。
これは、次回ETSI ESIの会議でも報告があるでしょうから
まぁ、良しとして、、、、

14日11:00 - 12:00 SESSION 4: INTERNATIONAL STANDARDIZATION (continue)
The European Commission's new Action Plan on
 e-signatures and eidentification
  Gerard Galler , Policy Officer, European Commission,
  Information Society & Media DG
  (スライドPDF)


こちらはちょっと気になるところです。

講演模様がウェブ(WMV)でストリーミング放送されるらしいです。
http://webcast.etsi.org

う〜〜む日本で19:00かぁ、、、、飲んでる最中だな、こりゃ、、、、、

<追記 2009.01.16>
ジンジアーニ議長は、今私も参加しているSTF351の活動の紹介や、XAdES/CAdES長期署名フォーマットのプラグテスト(ETSI 3rd Remote XAdES/CAdES Plugtests)の紹介もちゃんとしてくれたようだ、、、、よかった、よかった(^^;

ETSI STFテレカン初め

今日は年が明けて最初のETSI STF351の電話会議になります。

2月末に行われる"ETSI 3rd Remote XAdES/CAdES Plugtests"の準備に本格的に取り掛かります。

プラグテストまでの参加者のスケジュールはこうなっています。

2009.02.06 オンライン登録〆
2009.02.06 参加者とETSIのNDA締結〆
2009.02.06 参加費のカード払い〆(海外送金の場合別途)
2009.02.16 テスト開始
2009.02.27 テスト終了

ウェブカム忘れないようにしないと、、、、、、

CAdESライブラリを機能追加

自堕落な技術者の日記 : ETSI 3rd Remote XAdES/CAdES Plugtest - livedoor Blog(ブログ)
来年2009年2月にETSIで長期署名フォーマット CAdES/XAdES の相互運用実証実験を行います。ETSIの主催するXAdESのテストとしては3回目、インターネットを用い日本からもリモートで気軽に参加できるテストとしては2回目、CAdESのテストとしては初めてのテストとなります。


ETSI 3rd Remote XAdES/CAdES Plugtestのために参加者の皆さんに検証してもらう失敗系のテストデータを作っているんですが、手持ちのCAdES実装ではOCSPの扱いがかな〜〜〜り不十分であることが発覚しました。実装もかなりイケテない、だめだこりゃ、、、トホホ、、、、

機能を足す前にリファクタリングだな、、、、こりゃ、、、、

来週のISO TC154とETSI ESI

今週はIETFがミネアポリスであったみたいですが、来週はISO TC154 plenaryとETSI TC ESI meetingが同じ日にあります。

ESIいけなくて残念、、、、、、
課題は山積なんですが、、、、

CAdESの改訂の方はなんかCompleteCertificateRefsの現状の規定の解釈の認識がESIのメンバー内で少しずつ違うのでRapporteurのJulienも苦労しているよう、、、、

個人的にはCompleteCertificateRefsの問題は、どちらかというとどうでも良くて、
・検証要件がInformativeになっている問題
・時間の比較の問題の修正
の方がよっぽど重要なんじゃないかと思っています。

ただ、CompleteCertificateRefsの問題が解決すると、タイムスタンプを含む検証情報の格納方法が一気に片付きそうな気配もあるのでうまく誘導しないといけません、、、、

パッキングはほぼ終わりで、発表のスライドも手をいれ終わったんですが事務局に事前に送ったスライドと随分違っちゃうのでやばいかな、、、、、Kさんに明日相談しないと、、、、

CAdES move forward...

Confluence - Enterprise Wiki Software


明日に向けちょっとテンパった状態で今夜は完徹ですが、何とか生きています。

ETSI CAdESのエディタの一人であるイケメンフランス人のJulien SternからCAdESで残課題となっている相互運用性上の問題を解決するため議論に加わってちょ、、、とメールが来た。最初は少人数で始めたいからと、他にはPinkasさん、Popeさん、Juan Carlosさんがメンバになっているそうだ。

ディスカッションにはATLASSIAN社のConfluenceという商用のWikiソフトを使うみたいだ、、、、と、早速アカウント登録、、、っと

フムフム、Issue Listを見ると頭の痛い問題ばかりだ、、、、私が指摘したのが半分以上占めちゃっている。熱い議論になりそうだ、、、きっともめるな、、、こりゃ、、、、、

でも、私は場が険悪になっても主張は曲げない、、、、つもり( ´∀`)つ
果たしてうまくいくでしょうか、、、、、

XAdESにおける発行者名前比較の問題(第1回)

前から書こうと思っていたんですが、やっと時間が取れそうなのでXML形式の長期署名フォーマット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の改訂

ETSI ESI #22 Meeting Bilbao Spain

ETSI Calendar of Meetings - View Meetings


2008年11月25日(火)〜2008年11月26日(水)、スペインの北部バスク地方のビルバオで欧州電子通信規格協会(ETSI)電子署名基盤技術委員会(TC ESI)の定例会議が開かれますので、、、、メモメモ、、、
最新記事
Categories
Archives
Twitter
記事Google検索

本ブログ内をGoogle検索
Yahoo!アクセス解析
Travel Advisor
記事検索
QRコード
QRコード
  • ライブドアブログ