自堕落な技術者の日記

(application/pdf オブジェクト)

W3C Workshop Position Paper:The importance of incorporating XAdES extensions into ongoing
XML-Sig workより
Today XAdES has gained a high degree of acknowledgment in Europe and is also penetrating in
Japan. Several interoperability test events have been organized by ETSI in Europe and by ECOM in Japan. Some European countries mandate signing certain electronic documents with XAdES signatures (e-Invoices, accounting documents, etc).

W3Cの一昨年行われたワークショップ Next Steps for XML Signature and XML Encryption (25/26 September 2007 -- Mountain View, California hosted by VeriSign) で、Juan Carlos Cruellas教授が"The importance of incorporating XAdES extensions into ongoing XML-Sig work"というタイトルでプレゼンをして、日本のECOMの話も触れて頂いていたようです、、、、ありがとうございますｍ（＿　＿）ｍ

今日はちょっと早くでないといけません、、、、眠い、、、、

自堕落な技術者の日記 : ETSI 3rd Remote XAdES/CAdES Plugtest - livedoor Blog（ブログ）

来年2009年2月にETSIで長期署名フォーマット CAdES/XAdES の相互運用実証実験を行います。ETSIの主催するXAdESのテストとしては３回目、インターネットを用い日本からもリモートで気軽に参加できるテストとしては２回目、CAdESのテストとしては初めてのテストとなります。

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

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

ウィキペディアで前に
・ja:暗号メッセージ構文
・ja:PKCS
・ja:XAdES
・ja:XML署名

なんかを英語版から持ってきて書いたりしたんですが、今日はちょっと時間があったのでこんなところを追加しておきました（　´∀｀）つ

・ja:CAdES
・en:CAdES (computing)
・en:Cades

Plugtests Portal for Electronic Signature

来年2009年2月にETSIで長期署名フォーマット CAdES/XAdES の相互運用実証実験を行います。ETSIの主催するXAdESのテストとしては３回目、インターネットを用い日本からもリモートで気軽に参加できるテストとしては２回目、CAdESのテストとしては初めてのテストとなります。

CAdESのテスト内容は、前回のXAdESのテストと同じようなテストケースになります。
・長期署名の生成・交換・検証について３５程度
・失敗系のみの検証テストについて１５程度
になるかと思います。

OCSPや属性証明書などを使ったテストもありますので、よかったら参加してください。STF351でそろそろテストケースの設計や準備に着手することになります。XAdESの方については何かニューなテストが必要かなと思っていますのでご要望などありましたらよろしくおねがいしますｍ（＿　＿）ｍ

Dear Madam,
Dear Sir,

The ETSI Plugtests Service is pleased to invite you to participate in a new remote XAdES plugtests!

After the success of the first remote plugtest event, ETSI has continued the development of the supporting Remote Plugtest Portal, which now offers on-line PKI-related services (Certificates provision, OCSP server, LDAP and Time-stamp).

The purposes of these new events are:

* To consolidate solutions to already identified interoperability issues of XAdES.

* To enable participants to assess the level of interoperability of CAdES.

* To identify additional issues that should be taken into account in future XAdES/CAdES standardization activities.

* To improve the quality of XAdES/CAdES specifications.

* To ease the introduction of XAdES/CAdES signatures, by providing the means to solve interoperability problems before widespread deployment.

The event will evaluate (X-C)AdES interoperability by focusing on all the different XAdES forms standardized in ETSI TS 101 903 and ETSI 101 733, including (X-C)AdES-BES, (X-C)AdES-EPES, (X-C)AdES-T, (X-C)AdES-C, (X-C)AdES-X Type 1, (X-C)AdES-X Type 2, (X-C)AdES-XL and (X-C)AdES-A.

Participants will also be able to generate new test case definitions and signatures, which will be taken into consideration for extending the test cases set according to ETSI's discretion.

The registration deadline for the 3rd event is 6th February 2009. We recommend you to register as soon as possible. All details about the events, including all the technical information are available at http://www.etsi.org/plugtests/XAdES2/html/XAdES2.htm

Should you need any further information, please feel free to contact us at: plugtests@etsi.org

The Plugtests Team

今、ブリュッセルは２２時半です。

ISO TC154 plenary二日目でPossible New Work Itemに関する
無事プレゼンも国内委員長の鶴の一声のおかげで無事終えることができました。
作業者のリソースの問題はあるけども興味を持ってくれた国も何カ国かあり概ね好意的に受け取ってもらえたのではないかと思います。はひ〜〜疲れたび〜〜〜。

会議後、自動車博物館を見学して３時間の間でお土産の買い物をダッシュで済ませてしまい昨晩行き損ねた中華に行ってきました。食べたのはこんなの、、、

・エビチリという漢字で書いてあるも海老と野菜のうま煮、赤唐辛子入り
・酢豚のようでいてただのケチャップ煮っぽいもの
・ジューシーでない小龍包
・白いごはん

一般的なこちらの料理には本当に飽きていたので、上に書いてあるような料理でもとてもウレシイし、まぁ、中華ではなく家庭料理みたいな感じで良かったです。地元のベルギー人、中国人に人気の店らしくてとても２０時を過ぎるととても混んでいました。

ここでは、ろくなベルギービールが無くなぜかチンタオビールと５４°のマオタイ酒を飲みました。マオタイ酒は基本的に記憶がなくなるまで飲んでしまい、味など覚えていないのが普通ですが、今回はライチのお酒のような風味で今までで一番だと思うマオタイ酒を適量飲みました（　´∀｀）

さて、パッキングをせねば、、、、、

今、ブリュッセルは朝６時ちょっと前。
いよいよ今日TC154で説明してきます。

なるべくわかりやすく平易な表現でやるつもりなんですが、
そもそも面倒くさい技術が背景にあるので
なかなか難しい、、、、、

昨晩は会議後、少し電車やトラムを乗り継いでガイドブックに乗っていた中華や焼肉に行こうとおもったんですが二件ともつぶれていたのかガイドブックが間違っているのか結局見つけられず、南駅に戻り探してみるも食べるところも見つからず、途中でお腹の具合がわるくなってしまいホテルに戻ってくるという晩飯に関しては三連敗という散々な目にあってしまいました（　´∀｀）

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

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

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

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

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

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

Confluence - Enterprise Wiki Software

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

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

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

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

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

前から書こうと思っていたんですが、やっと時間が取れそうなので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 #21 Meeting London (9/24-25) - livedoor Blog（ブログ）

欧州通信規格協会の電子署名基盤技術委員会 ETSI ESI#21 Meeting がロンドンにて明日から行われます。PDF長期署名については重要な議題なんですが、それに加えてCAdES関連の追加の提案や仕様の改定案がいくつか出ています。

ArchiveTimeStampについてはV2ようやく落ち着いたと思ったのに変な改定案がまた出ており、きちんと対応しないといけません、、、、ちょっと疲れる、、、、、