自堕落な技術者の日記

先月27日頃、ETSI TS 101 903 XAdESの改訂ドラフトが内々に回ってきましたが、レビューとコメント受付の期間が殆ど無いので多分このまま通っちゃうんでしょう、、、、、トホホ、

今回の改訂は仕様を深く理解していない人の意見をそのままあまり考えずに取り入れた改悪なような気が少ししています。正式に公開されたら、このブログで問題点を述べたいと思います。

STF351の実験の対応に忙殺されて、標準改訂に対して忙しすぎて全くコメントできなくて、後になってコメントすればいいやと考えていたのは間違いでした。残念、、、、、

自堕落な技術者のヰキ(公開版) - AdES/CAdES,CMS,ESSの属性一覧

人知れず別館の方でCAdES長期署名フォーマットで使われる属性の一覧表を作っていました。よかったら使ってやってください。

・自堕落な技術者のヰキ：CAdES,CMS,ESSの属性一覧
・http://www9.atwiki.jp/kurushima/pages/67.html

CAdESについて

(1)この属性のOIDなんだったっけ？とか
(2)どこで定義されているんだっけ？とか
(3)同じ属性を何個も置いていいんだっけ？とか
(4)SET OF AttributeValuesの中でAttributeValues幾ついれていいの？
(5)この属性は署名属性？非署名属性？

なんてことがわからなくなった時に使うといいかな、と思います。

表を観ればわかるようにAttributeやAttributeValueの個数制限についてはCMSでは割合厳密に規定されているんですがCAdESの方では結構曖昧でまずいなぁ、、、と思っています。

ちなみにAttributeやAttributeValueの定義はこんな感じです。

RFC 3852 CMS 5.3 SignerInfo Type

SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

Attribute ::= SEQUENCE {

  attrType OBJECT IDENTIFIER,

  attrValues SET OF AttributeValue }

例えば、署名属性群SignedAttributesの中で例えばSigningTimeのAttributeを幾つも付けてしまうとか、一つのSigningTime Attributeの中のattrValuesの中で幾つもAttributeValuesを置いてしまうとか可能性はあるわけです。(SigningTimeについてはどちらも1つまでに制限されます)

ASN.1 の 'SET OF' 構造がこれまた厄介で、DERの場合には要素をオクテットで昇順ソートしたものになりますが、BERの場合にはソートされません。SignedAttributesはDERでエンコードされますが、UnsignedAttributesはBERでソートしないものでも構いません。

ですから非署名属性の SET OF Attributesの要素数が2つ以上あるとCAdESではちょっと厄介なことになるのです。

CAdESの仕様ではこの辺を今後明記しないといけません。

サーバーの入れ替えに伴いウェブサーバのログデータを退避しました。今のウェブサーバーのソフトウェアは2004年10月頃から使っていますが、その辺りからテスト用にCRL(証明書失効リスト)を公開しています。
(途中、サーバーを停止させたりしている時期もありました。)

・2004年度後期 JNSA S/MIME WGのメーラー毎のS/MIME署名メール検証テスト
・2005年度後期 ECOM 2005年度 CAdES/XAdES長期署名相互運用性テスト
・2007年度 ECOM 2007年度 CAdES/XAdES長期署名相互運用性テスト
・実験後、テスト用署名データをECOMサイトで公開

2004年10月からのCRLの月毎のアクセス数をグラフにするとこんな感じ。





ECOMのテストはテストケース毎にCRLファイルを分けていたので、それなりのアクセス数になっています。ECOMのテスト後にテスト用の署名データや証明書などを公開するようにしたので、テスト後もちらほら継続的にアクセスはあったりします。

2004年10月からのCRLのアクセスの国内からの割合はこんな感じ。国内実験がメインなので7割が日本っていうのは当然ですが、国外からも意外にあったりします。





国外からのアクセスの内訳を見てみるとこんな感じ。





フランス、スペインはECOMの2007年度の実験に参加してもらっているので、それなりにアクセスがあるのは当然なんですが、トルコ、ハンガリー、スウェーデンなどECOMテストに参加していない国からのアクセスも結構あったりします。ECOMの英語版のページでテスト用長期署名をダウンロードできるようにしてあるんですが、これを観て実際に長期署名検証をしようとしてみてくれてるんだろうと思います。

トルコはトルコ政府がETSIのリモートテストにも参加していたりして長期署名に真剣に取り組んでいるみたいですね。

しかし、パキスタンって本当かなぁ、、、ログ取得時期とGeoIPのデータの時期が間違っているのかなぁ、、、本当だとしたらちょっとびっくりですね。

これらのCRLは、ふらっとサイトに来てダウンロードして帰るような代物ではないので、署名の実装があって検証しようとしてみたという所では割と信憑性のある数字なのかな、、、とも思います。

2009年2月の頭にプラグテストの最終調整のために行ったバルセロナ出張の記録を写真と共に簡単にご紹介しておきます。バルセロナな３回目なので観光的な要素は割と少なめで、、、、（＾＾；




行きは全日空、パリ経由エールフランスで行ったんですがこれだと乗り換えがチョー面倒臭いんですよね。ターミナル1からバスでターミナル2Fに行くわけですがこの乗り場に降りる階段がわかりにくい。延々歩かされるので乗り継ぎ時間が短いと絶対アウトですな。「ストライキがいつあるかわかんないのに良くエールフランスなんか使ったね。ルフトハンザがいいよ絶対！！」とフランス人のPeterに言われました。飛行機を選べる立場に無いわけですが、、、

宿泊は会議に便利なようにカタルーニャ工科大学(UPC)に隣接の宿舎UPC Residence Torre Gironaに泊まりました。着いたのが夜だったのと雨も降っていたのでタクシーで行きました。地下鉄ではL3線で中心街から北西部の駅Palau Reialからはこんな道のり。7分ぐらいでしょうか。

View Larger Map

昼間の入り口はこんな感じ。




大学の先生や職員が短期留学とかの目的で泊まれる施設なので結構いろんなものが揃っていて有難かったですが、肝心なコーヒーカップとかドライヤーとかは無くて困りました。インターネットは有線です。朝食付きですが、ぱっとしないのでキッチンもあるし何か作るといいんじゃないっすかね。




会議は二日間9:00-18:00でみっちりと、、、、その後、21:00から夕食もみっちりと、、、一日丸々なんで結構ヘビーですな。昼は大学構内にある２つのレストランのうちのひとつで9ユーロぐらいで味はフツーなんですが、赤ワインがデキャンタでサービスで付いてきます。このワインが深く渋みもあるのにさっぱりとした後味で良かったです。食事中写真を撮るのは、なんかマナーに反するような気がしたのでこの辺りは一切写真無しで残念。










二日目の会議後はフリーになったんで、早速お土産の買い物と食事に出かけます。まず、サッカーの聖地ＦＣバルセロナのホーム、カンプノウスタジアム。着いた日はメッシの２ゴールで勝ったのでスポーツニュースで盛り上がっていました。ここでとりあえず息子にスポーツマフラーを購入。







地下鉄の駅で回数券(十回券T-10)を購入。




とりあえず市電で移動しカミさんと娘にZARAやH&Mで洋服を購入。



別に高級店では無いですが「Ａ」が光らないのはチョットね。ハリファックスのマリオットも全部は光ってなくて悲しい感じだった。




賑わっているところに移動し本屋に入ってみました。テニスの王子様、NARUTO、キャプテン翼、BREACHとか全てスペイン語で置いてありました。立ち読みしました。




お土産選びも無事終わって、会議の無事終了を祝って適当にあったTAPA TAPAというバールで一人で祝杯。お疲れ様でやんす。これはイベリコ豚の生ハムサンドとアンチョビのパイ。



イカが柔らかくて激ウマ。スペインの人は魚介類好きなので日本人の味覚と近いような気がします。後ろでは女子大生の卒業旅行っぽい４人組の方がいて楽しそうでした。




９時ごろ宿をチェックアウトして３回にもなるのに一度も行っていなかった観光名所のカザ・ミラとカザ・パドリョに旅行鞄抱えて向かいました。宿から地下鉄の駅までの途中にグエル別邸(Finca Güell)があります。今はUPC建築学部ガウディ研究室になっているそうです。




これはカザ・ミラ。小学生が粘土で作った建物とあまり違いが無いところが逆にスゴイ。屋上を歩けるのでこれまた楽しい。よかった、受付で旅行鞄預かってくれて、、、、






学生さんも見学に来ています。




こっちは、カザ・パドリョ。









こちらも屋上に行かれます。ガウディはこのモザイクタイルの造形が特徴なんですが、特にグエル公園なんか行くと小学校の卒業制作とあんまり違わないのに、これがちゃんと残っているっていのがスゴイところだと思います。アイディア勝負です。

で、カタルーニャ広場に向かい適当にあったマクドナルドで昼食を取り空港バスで空港へ。巡回バスなんですが始発であるカタルーニャ広場から乗った方が荷物の置き場の心配が無くていいそうです。バスは１０分おきぐらいに出ているし、４ユーロぐらいで安いし止まる先も便利な場所だし国鉄なんか使うより全然便利みたいです。高速が空いていたので予定よりも１０分ぐらい早くてトータル３０分弱で着いてしまいました。

いつものようにスライドショーはこちらで、、、、

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

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

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

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

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

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

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

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

このまえのデ協のWGで、昨年末あったうるう秒の話題になったんですが、日本の多くのタイムスタンプサービスや時刻配信局はうるう秒であるUTC時刻で2008年12月31日23時59分60秒、日本時間でいう2009年1月1日8時59分60秒は、利用者側で不具合がおきないようサービスを停止させておくという措置を取っていたそうです。

ASN.1プリミティブはITU-T X.680で規定されていてGeneralizedTimeは以下のように42章で以下のように定義されています。値はVisibleStringでありISO 8601で規定された時刻表現である限りは何でもよく

GeneralizedTime ::= [UNIVERSAL 24] IMPLICIT VisibleString

うるう秒でも表現して構わないようです。

GeneralizedTime: 20081231235960Z

一方、UTCTimeは同じく43章で規定されており秒は0..59の範囲しか使えないので、うるう秒を表現することはできません。

じゃぁ、うるう秒を含むような
・X.509証明書
・タイムスタンプトークン
・長期署名フォーマット
ってどうなるんだろうとう疑問が沸々沸いてきたので、まぁ、作ってみました。

ASN.1を扱うライブラリに完全に依存しているし、ANSIのCの時刻なんかは絶対アウトだろうな、、、と思うわけです。

うるう秒を含むX.509証明書

証明書の有効期限のnotBeforeが、昨年のうるう秒(GeneralizedTime 20081231235960Z)であるような証明書を作ってみて読めるか試してみました。

・OpenSSL
UTC時刻 2008年12月31日23時59分00秒 (と60秒戻ってしまった)
・Windows証明書ビューア
開こうとしても「このファイルは"セキュリティ証明書"として
使用することはできません」と表示されてしまいます。
・Windows PKCS#12のインポート
「インポート中のキーは正しくエンコードされていません。」
と表示され失敗
・Java 1.6 JCE SUN Provider(algorithm="X.509")
例外発生 java.security.cert.CertificateParsingException: Parse Generalized time, invalid format
・Java 1.6 JCE BC(BouncyCastle) Provider(algorithm="X.509")
読み込み成功。"200901010000Z"と同じ扱い。
・Java 1.6 JCE IAIK 3.142 Provider(algorithm="X.509")
読み込み成功。"200901010000Z"と同じ扱い。

テスト結果：
・WindowsやSun Javaなどはうるう秒証明書に対応していない
・暗号ライブラリ OpenSSL, BouncyCastle, IAIKはうるう秒証明書に(概ね)対応している

genTimeがうるう秒であるようなRFC 3161タイムスタンプトークン

とりあえず入手できた某RFC 3161タイムスタンプトークン検証ツールで試してみたところ、正しく"20081231235960Z"であるように表示されています。すばらしい。

うるう秒を含むCAdES長期署名フォーマット

署名タイムスタンプのgenTimeにうるう秒が含まれるようなCAdES長期署名ファイルを生成し、手持ちのツールやライブラリで検証してみました。

自前のCAdES実装では特に問題なく検証できました。時刻はうるう秒としてそのまま扱われていました。

うるう秒を含むXAdES長期署名フォーマット

署名タイムスタンプのgenTimeにうるう秒が含まれるようなXAdES長期署名ファイルを生成し、手持ちのツールやライブラリで検証してみました。

自前のXAdES実装では特に(大きな)問題なく検証できました。時刻はUTC時刻2009年1月1日0時0分0秒として扱われていました。

とある私のではない別の実装でXAdES-T署名を検証してみましたが、署名タイムスタンプのエラーになってしまいました。時刻がパーズできないせいなのか、どうかがちょっとわかりません。

今日は、こんなところで、、、、

2008年9月8日から18日にかけて開催された前回のETSIのXAdESプラグテストの結果が公開されました。

過去のテストイベントの説明
・http://xades-portal.etsi.org/pub/pastevents.shtml
ETSI 2nd Remote XAdES Plugtestの報告書
・http://xades-portal.etsi.org/pub/FinalReport-2ndRemoteXAdESPlugtest-200809.pdf

なんかレポート見ると、うちの実装とのマークが赤くなっていて相互運用性に問題があるように勘違いされそうですが、これは間違っている署名を正しく間違っていると検証できているためです。ECOMのテストと違って問題があってもどちらが悪いか白黒はっきりさせないんですよね、、、、、、

ETSI STF-351(Interoperability framework for XML Advanced Electronic Signatures (XAdES)) の役割分担についても新しくページを作ってもらいました。

ETSI STF-351 Team
・http://xades-portal.etsi.org/pub/STF-351_presentation.shtml

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で承認されたことになるそうです。(既にコメントは出ていますが、、、)

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

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

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

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

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

≪第8回

今回で最終回となります。これまで、XML形式の長期署名フォーマットXAdESの識別名一致確認において以下の事柄を紹介してきました。

1. XAdESの仕様ではSigningCertificate、CompleteCertificateRefsおよびCompleteRevocationRefsに記載された証明書識別名が証明書、CRL、OCSP応答データと一致することを確認しなければならない。


2. XAdESにおいて証明書識別名はRFC 2253により生成されるが、これは正規化形式ではないので生成側、検証側の実装が異なれば一致確認を行うのは難しい。


3. 実際にテストを行いRFC 2253識別名文字列の生成を行ってみると実装により違いがあることがわかった。


4. 現在存在するXAdESの多くの実装では規定された識別名との一致確認を行っていないために問題とならなかったようだ。


5. 識別名の一致確認を容易かつ厳密に行えるCAdESと比較して、XAdESの実装では識別名の確認を行っていないか不十分であるため、XAdESの方が検証情報の真正性のレベルは低くなる。

XAdESのための認証局・証明書選び

もし、署名者、タイムスタンプ局の認証局を選ぶことができるならば以下の点に注意すると良いと思います。逆にこれから認証局を構築するなら同様の点に注意してください。

1. 全ての認証局の識別名の属性タイプは(CN,OU,O,L,C)のみが使われているものを選ぶ(例：CN=Root CA,O=Hoge,C=JP)


2. 全ての認証局の識別名の属性タイプに(emailAddress,stateOrProvince)が使われていないことを確認する


3. 全ての認証局の識別名のDirectoryString TypeはPrintableStringかUTF8Stringのみを用いる


4. 鬼門となりそうなASCIIの記号文字(',', ';', '<', '>', '=', '#', '\', '"', など)は極力識別名には使わない

アプリケーション側が認証局選べるハッピーなケースなんてほとんど無いんですけどね、、、（＾＾；

XAdES相互運用性のアプリケーション側の注意点

生成も検証も同じアプリを使う場合には気にしなくていいですが、他の会社の文書交換とか署名生成と検証とが違うアプリケーションの場合には、選んでしまった認証局の種類、アプリケーションの種類によって「生成、検証の双方のドメインで」以下のような注意をすると良いのではないかと思います。

1. 詳細なテストの前に検証側実装が識別名名の一致確認を厳密に実装しているか確認してみる。実装していないなら問題は生じない


2. 一方がMicrosoft系の実装であれば慎重に動作確認を行う


3. 使用される全てのCA証明書で主体者名の属性タイプにemailAddress、stateOrProvinceが含まれていればXAdES参照情報の一致確認に問題が生じないか確認しておく


4. CA証明書主体者名のDirectoryString TypeがPrintableString、UTF8String以外であれば慎重に動作確認する


5. CA証明書主体者名の属性値にASCIIの記号文字(',', ';', '<', '>', '=', '#', '\', '"', など)が含まれている場合には慎重に動作確認する


6. 使用される全てのCA証明書で主体者名の属性タイプがCN,OU,O,L,Cであれば問題は少ないが一応動作確認をしておく


7. 検証時に名前が一致しなかったとしても、エラーとはせず警告程度に留めておいた方がよい

XAdESの改定に向けて

現在、ETSIで行われた実証実験の結果を受けてETSI TS 101 903 v1.3.2 XAdESの改訂の項目洗い出しやディスカッションがETSI TC ESIで行われています。

今回のXAdESの名前比較は、CAdESと同等の置換攻撃に対する耐性を持たせるためにはきちんとやらなければいけないはずですが、識別名文字列の生成結果が一意にならないために、一致検証を行っていなかったりする実装がほとんどであり、XAdES v1.3.2の仕様の検証要件自体が形骸化しています。

できもしないような現状の一致検証の要件は取り下げてもらい、必要性を感じているなら、識別名オクテットのハッシュ値を比較し、文字列としては比較しないなどの別の方法による識別名の一致確認を行うべきであると考えており、これをETSI TC ESIや仕様のエディタに継続的に訴えかけていくつもりでいます。

ETSIのプラグテストの設計の際、今回ご紹介した問題を仕様のエディタ兼プラグテストの取りまとめの方に説明し、「名前比較はXAdESでは真面目にやろうとすると難しいし、現状ではあまり意味がないのでテスト項目から外しましょう」という事で納得してもらいましたので、概ねこの問題については理解してもらっているものと思っています。

以上、全９回に分けてXAdESにおける識別名の名前比較の問題について説明してきました。いかがでしたか？細かい部分が理解いただけなかったとしても、それは私の説明の仕方に問題があるんだと思います（＾＾；なんとな〜〜く「XAdESの名前比較は面倒臭い、、、」という事だけ知って頂ければ幸いです。

ではでは、、、

＜追記＞
以前書いたBER/DERの問題は、ちょっとウソを書いてしまっているので近いうちに直します、、、、ｍ（＿　＿）ｍ

---

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の改訂