自堕落な技術者の日記

PKCS#7やCMSなどの一般的な署名フォーマットと互換性を持ちながら、署名者の特定を厳密に行い長期に保存することが可能なバイナリ形式の署名フォーマットETSI TS 101 733 CAdES(CMS Advanced Electronic Signature)の仕様が2009年11月に改訂されていたようです。(全く気づきませんでした。おかしいなぁ、、、実際に公開されたのは1月に入ってじゃないのかなぁ、、、クリスマス休暇だしなぁ、、、)

前のバージョンはv1.7.4からv1.8.1へとなったわけですが、あまり重要な更新も無いのでv1.7.5でもよかったんじゃないかなと、思えるような更新です。

改訂作業は欧州通信規格協会(ETSI)の技術専門家タスクフォース(STF)で行われるので、個別の変更点は漏れ聞こえてきますが、改訂レビューの期間もすごく短くて何が変更されるのかETSIの電子署名基盤技術委員会(TC ESI)でも報告されるわけではないので、改訂の全体像っていうのがわかりにくいんですよね。

どの辺りが改訂されているのか少し調べてみました。

ワードで差分の抽出

差分を目で追うのも大変なので、Acrobat 9 Standardで比較しようとおもったら、比較機能はProだけなんですね。仕方なくMicrosoft Wordの比較機能を使いました。

(1) Microsoft Word 2003でv1.8.1を開く。
(2) メニューのツール＞文書の比較と反映を選ぶ。
(3) ファイル選択ダイアログでv1.7.4を選択する。
　　設定はデフォルトのままでモードは「反映」でよいようだ。

これで、変更部分が青字で表示されるようになります。

変更点のまとめの記述

「Annex L.2 Changes between 1.7.4 and 1.8.1」には変更点がまとめられています。ドラフトでは変更点は過去と一緒くたになっていたので、1.7.4と1.8.1の差分を明記して欲しいとMLやESI会議でお願いして、その場ではドラフト最終段階だから分けないという結論だったんですが、結局は分けてくれたようです。よかった。

主要な変更点次のようなんだそうです。

(a) ContentTimeStampの計算方法の明確化

具体的な計算方法の記述を無くし、CMSの計算方法を参照するように修正されました。

(b) タイムスタンプのハッシュアルゴリズム危殆化に関する記述

RFC 3161のタイムスタンプトークンのTSA証明書を特定するためにESSCertID(v1)とSHA2も使えるRFC 5035 ESSCertIDv2をサポートするものとする(shall)とされた。CAdESのRFC 3161タイムスタンプトークンはETS TS 101 861のプロファイルに準拠しなければならないそうだ。(見落としてた)

署名者証明書の特定にSHA256をデフォルトとするRFC 5035の「ESSCertIDv2もサポートする(shall)」という記述が加わった。

(c) OCSPを使う場合のCompleteCertificateRefsの利用ガイド

ocspRefHashは後方互換性のためオプションのままだが、置換攻撃に対応するために、これを含めることを強く推奨(strongly recommended)するとされた。

(d) CAdES-BES/EPESでなく一般的なCMSに対するCAdES属性の利用ガイド

(e) タイムスタンプのハッシュ計算についての追記

(f) CAdES-AでのB.3節の記述がオプションになるよう修正

(a) ContentTimeStampの計算方法の明確化について

ContentTimeStampは画像や文書などの署名対象データに対して署名を行う前に直接付与されるタイムスタンプです。v1.7.4までは、ContentTimeStampのmessageImprintの計算方法をencapContentInfoを使って具体的に記述していましたが、変に具体的だったため
・encapContentInfoのeContentがASN.1 BERやDERで違うときどうするのか
・内包署名(eContentに署名対象がある)や分離署名(署名対象データを署名フォーマットに入れない)の場合に計算はどうするのか
という問い合わせや議論が頻繁に起こっていたので、「CMSのmessage digestの計算方法と同じ方法を使う」という記述に変更されたようです。参照の仕方が大まかなので、かえって混乱するような気がします。「ContentTimeStampのmessageImprintのハッシュ値の計算方法はCMSのmessage digestの計算方法と同じで、eContentの構造に依存せず署名対象データそのものに対してハッシュ計算をする」というように何らかの補足は必要だったのかなと思います。

(d)一般的なCMSに対するCAdES属性の利用ガイドについて

CAdESのタイムスタンプ等を含まない基本的なフォーマットであるCAdES-BES、CAdES-EPESでは必須要件として署名者証明書を特定するためのESSSigningCertificateV1/V2属性を必須としていました。しかしながら、一般的なPKCS#7やCMS、PDF署名など、これら属性を最初から含まない署名データが数多く存在し、これらを長期保存するよう移行することができずに困っていました。

そこで、SigningCertificate属性を含まないものをCMS-BES/EPES/T/C/X/XL/Aと呼ぶことにより、CAdESの属性を使ってもよこととし、PKCS#7やCMSを長期保存できるようにしました。

欧州電子署名指令では高度電子署名(AdES)の要件として「署名者が特定できること」を挙げており、SigingCertificate属性は署名者証明書を特定でき置換攻撃ができないようにするための重要な要素なので、この属性もしくはこれと同等の機能を含まないものをAdESとは呼ばず、CMS-*としたことはとても意義があることだと思います。(この問題でPAdESについては言いたいことがあるんですが、また別の機会に、、、)

(f) CAdES-AでのB.3節の記述がオプションになるような修正について

v1.7.4のAnnex B.3 の CAdES-A の説明では、「少なくとも一つのTimestampedCertsCRLsかCAdES-C TimeStampが必須である」という記述だったんですが、元々過去のバージョン(v1.5.1以前？)ではオプションでした。ESI会議でこの点を日本とトルコが指摘し無事修正されることとなりました。

タイムスタンプのハッシュ計算についての追記について

v1.8.1 Annex Kに(informative)Time-stamp hash calculationという章が追加され、タイムスタンプトークンのmessageImprintの計算方法について表を用いた解説が追加されました。

個人的にはこの表の追加には反対だったし、そのようにコメントもしました。そもそも表自体がわかり辛いし、仕様本体(normative)と齟齬があるように誤解され得る箇所があり、一貫性を持ちながらこの表を今後メンテナンスしいく事が難しいように思えたからです。

全体的には仕様が緩められた

細かい所は説明しませんが、全体的にmustやshallと記述されていたところが緩い表現に変更されているのがわかります。現実の実装に則した仕様に近づいたかなと思います。

ArchiveTimeStampの計算方法について

ArchiveTimeStampの計算方法については、v1.5.1以降、曖昧な点があり続け、これを明確化するように日本からもコメントをし続けてきましたが、v1.7.4からv1.8.1への変更では大きく変更されることはありませんでした。依然としてASN.1 BERとDERのエンコーディングの違いによる問題は残されたままになっています。

署名対象のデータ表現について

CAdESや元のCMS(PKCS#7)で使われる署名対象のデータを署名フォーマットのeContentフィールドの中に格納することができるんですが、恐らくCAdES v1.6.3あたりから「こっそり」以下のような記述が追加されていました。

引用 ETSI TS 101 733 v1.8.1 5.2 Data Content Type
NOTE: If the content type is id- data, it is recommended that the content be encoded using MIME, and that the MIME type is used to identify the presentation format of the data. See clause F.1 for an example of using MIME to identify the encoding type.

コンテントがid-dataで示されるデータの場合には、S/MIMEのオペイク署名のようにMIMEでエンコードすることを推奨(recommended)するという記述が加わっています。個人的にはCAdESで制限する必要の無い事だと思っています。

おわりに

以上、少し時間が取れたので2009年11月に公開されたCAdES v1.8.1の改訂について解説してみました。この先、署名やPKI関係の仕事ができなそうな気もしているので、時間がとれ次第ため込んでいることを書き残していきたいと思っています。

ではでは

5月にも一度投票があり結局、積極参加が1ヶ国足らずにダメだったんですが、各方面のアドバイス通り、議長など粘り強くいろいろして下さった結果、追加の積極参加が1ヶ国あって、New Work Itemとして7月14日に ISO/TC154/SCで承認されたとTC154の議長さんから連絡が来ました。

そ〜〜です、CAdESとXAdESのJISプロファイルが3年後にはISOになるっつ〜〜〜〜ことなんですよ、おと〜〜〜さん。(トホホ)・・・・（Ｔ＿Ｔ）

■タイトル
Long Term Signature Profiles for EDI Data and Electronic Documents

■投票結果
Pメンバー19 / 賛成10 / 反対1 / 棄権8

■積極参加(エキスパートを出してくれる国)
・中国(SAC)
・チェコ(UNMZ)
・ドイツ(DIN)
・日本(JISC)
・ベトナム(STAMEQ)

2010年1月15日までに最初のドラフトを出さないといけないんだそう、、、、

いつのまにかexpertに入れられちゃってるし、、、(＞＞自分)、、、、日本提案だからワーキングのリーダーっつ〜〜ことになるんだよなぁ、、、、（はぁ)

そんなにワークが割けるんかいな、、、と、とて〜〜〜〜〜も不安、、、、、New Work Itemが承認されて、とて〜〜〜も複雑、、、、、

Title: CMS (RFC 3852) Implementation Report
Author: Sean Turner, IECA Inc.
Date: 30 March 2009

Summary: This document provides an implementation report for Cryptographic Message Syntax (CMS) [CMS]. The methodology used to develop this document is explained, the questionnaire used to develop some of the report is included, and the eight different "products" are listed, the results of the questionnaire is included, and a conclusion is provided. The editor makes no claim as to the accuracy of the information provided.

CMS署名の相互運用性に関するアンケートがS/MIME WGでまわっていましたが、そのまとめのレポートが公開されました。

調査結果としてはあまりためにはならないような気がします。内容もあまり面白くない、、、、（＾＾；

＜リンク＞
・PDF版はこちら
・IETF IESG Protocol Implementation Reports

自堕落な技術者のヰキ(公開版) - 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の仕様ではこの辺を今後明記しないといけません。

RFC 5485 - Digital Signatures on Internet-Draft Documents

This document specifies the conventions for storing a digital signature on Internet-Drafts. The Cryptographic Message Syntax (CMS) [CMS] is used to create a detached signature. The signature is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature.

お世話になっているＭさんの日記を見ていたらRFC 5485 Digital Signatures on Internet-DraftsというInformational RFCが大御所R.Housleyから出てきたそうです。

これは、インターネットドラフトにCMS detached署名をIETF事務局がつける方法に関するRFCだそうで、基本はCMSなんですが、RFC 3161タイムスタンプも付けられます。

署名属性には書かれていませんが必要と思われるものは適当に追加していいようでESSSigningCertificateV1/V2属性を追加しておけば、ばっちりCAdES-Tになります。

文中、新しいASN.1シンタックスの表記が使われちょります。

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

2月16日に始まったETSI 3rd Remote XAdES/CAdES Plugtestsですが、3月4日に最終の検証結果の提出期限を終え、無事終了しました。参加された皆様、ご苦労さまでした。




今回は13ヶ国17組織が参加しました。全体が減っているおかげで日本からの参加の比率が「しっかりある」といった感じがしますね。珍しいところではトルコ政府機関の方が参加されたのは良かったかなと思っています。




参加総数は前回よりも徐々に減っていますが、実験の回数が無駄に多いから何回も参加する必要ないっていうのと、景気の影響もあるんですかね。




長期署名フォーマットにはXML署名の拡張であるXAdESと、CMS(PKCS#7)署名の拡張であるCAdESがあって、今回ETSIでは初めてのCAdESのテストで欧州でまともに参加実装が集まるんかいなと心配していたんですが、傾向的に長期署名に関心のある企業はCAdESもXAdESの双方に対応する企業が多いんだなぁ、、、という感じでした。
面倒だけど理屈さえわかっちゃえば、XMLだろうがCMSだろうが実装の手間は大差ないみたいなところはあるんでしょうかね、、、、

各実装でのありがちな誤りはこんなところ、、、

【CAdESでありがちな誤り】
・タイムスタンプ対象のMessageImprintの計算間違い
・BasicOCSPResponseでなくOCSPResponseを使っている
・署名ポリシIdのハッシュ計算や構造の誤り

【XAdESでありがちな誤り】
・DataObjectFormatの一致確認の誤り
・CertifiedRoleの属性証明書の誤り
・スキーマエラー
・入っている証明書・CRL・OCSPが間違っていたり

ECOMのテストデータを公開しているせいか、CAdESの誤りっていうのは初のETSIテストにもかかわらずあまりなくて驚きました。まぁ、ひどいところはひどいし、「前も指摘しましたよねぇ、、、直ってないじゃん、、、」みたいなのはあります。

ASN.1 BER・DERの議論も、もっと出てくるかなと思ったんですが、指摘すると「あ、そうですね」みたいな感じで素直に直ってくるので揉め事も少ないような気もしました。

自分の実装は、検証部分を大きく作り直したりしたんですが、テスト参加回数も大小あわせて７回ぐらいになるので実装的には枯れてきていてテストでバグが見つかったりとかも無く、単に設定上の誤りがあった程度でした。




ETSIのテストケースは標準で定義された全て要素を扱っていてテストケースへの対応状況表はこんな感じ、、、、うちのは無駄に100%フル実装してますな。（＾＾；

個人的には、イベントを主催している側の意識が仕様の改訂のネタ出しが主目的になっていてお金を払っている参加企業への配慮を非常に欠いているのと、お金を払ってまでヒトのバグを直しているような気分になるのがちょっとなぁ、、、という気がしました。eEuropeがスポンサーになっているそうなんですけど、参加費まで取ってるし、日本からの実験準備・技術提供とかも全てボランティアなのに、スポンサー費用って一体何に使われてるんでしょうねぇ、、、、

随分前にコトリグラフという3Dグラフ作成ソフトを買ってから何でもとりあえずグラフにしたくなってます（＾＾；

Plugtests Portal for Electronic Signature

Remote XAdES/CAdES plugtest 16 - 27 February 2009

今週の月曜より、長期署名フォーマットの相互運用テストであるETSI 3rd Remote XAdES/CAdES Plugtestsが始まりました。期間は2週間です。前回、前々回に比べて若干参加者も減り気味ですが、毎回やることはそれほど大きく変わらないので1回出れば十分っていうのもあるかもしれないですね。景気も悪いしねぇ、、、、、

CAdESのテストは殆ど一人で面倒みているようなもんな上に、XAdESも標準フル実装で参加していたり、運営側の仕事もあったりで結構大変です（Ｔ＿Ｔ）

3月5日に長期署名フォーマットプロファイルのISO化についてお話をさせて頂きます。この日は、何やらいろんなところでフォーラムやセミナーが開かれるようですが、もしよろしかったらお越し下さいｍ（＿　＿）ｍ

EDIや電子商取引がご専門の方がお見えになるようなので基本的には長期署名フォーマットのチュートリアル的な内容と、EDIへの長期署名フォーマットの適用、ISO提案の話をザックリできると良いと思っております。

◇　次世代EDI推進協議会(JEDIC)「第70回普及研修会」開催のご案内　◇
〜新しいビジネスインフラの構築に向けて〜
　
　製品のモジュール化が進展するデジタル化時代では、セットメーカーと
サプライヤーがお互いに対等な立場で連携することが、新しい付加価値
をユーザーに提供する上で不可欠となっています。また、業界や国境を
越えた企業間連携を実現するいわゆるビジネスインフラを日本発で構築
していくことが産業の国際競争力の観点で極めて重要です。
　今回の普及研修会では、EDI/電子タグ実態調査を踏まえ、企業間連携
のためのビジネスインフラ構築に向けて実施すべき施策・標準化および
ソリューションについて、実務家からご講演いただきます。

日時 ：平成21年3月5日（木） 13:30 〜 16:30

会場 ：機械振興会館　6階　66会議室
　　　　　　　　（東京都港区芝公園3-5-8）

参加費 　：・ＪＥＤＩＣ会員団体およびその所属企業：無料
　　　　　　　・ＥＣＯＭ会員、ＸＭＬコンソーシアム会員：無料（特別招待）
　　　　　　　・一般：15,000円　
　　　　　　　　
定員 ：90名（定員になり次第締め切らせていただきます。）

参加申込→JEDICホームページよりご登録ください。
　　　　　　　　http://jedic.ecom.jp/activity/seminar.html

--------------------------------------------------------------
プログラム(予定)：
--------------------------------------------------------------
13:30〜14:00
講演1「企業間連携のためのビジネスインフラ」
経済産業省　商務情報政策局情報経済課　伊藤　慎介　氏

　ビジネスインフラを日本発で構築していくための考え方につきご講演い
ただきます。
--------------------------------------------------------------
14:00〜14:45
講演2「平成20年度EDI/電子タグ実態調査報告」
株式会社三菱総合研究所　瀬楽　丈夫　氏

JEDIC会員38団体の協力により、団体傘下約550の企業よりアンケート
の回答をいただきました。当該アンケート回答に基づき、国内産業界にお
けるEDI/電子タグの利用実態につき解説します。
--------------------------------------------------------------
14:45〜15:00　休憩
--------------------------------------------------------------
15:00〜15:45
講演3「長期署名の国際標準化に向けて」
エントラストジャパン株式会社　漆嶌　賢二　様

　効率的な検証情報の保存や内部統制への対応のため、企業活動に係
る情報の記録管理の重要性が見直されています。情報記録管理のため
の長期署名標準化につきご講演をいただきます。
--------------------------------------------------------------
15:45〜16:30
講演4「中小企業EDIソリューションガイド」
株式会社データ・アプリケーション　藤野　裕司　氏

　公正取引を推進するための取引ガイドラインが見直されています。新た
な取引ガイドラインに沿って中小企業とEDIを実施するための考慮点につ
き解説します。
--------------------------------------------------------------

★参加申込登録→JEDICホームページ
　　　　　　　　　　　　http://jedic.ecom.jp/activity/seminar.html

★お問い合わせ→次世代EDI推進協議会(JEDIC)　事務局
TEL：03-3436-7568 FAX：03-3436-7570

＃ちなみに、講演タイトルとアブストラクトを決めたのは私ではありません（Ｔ＿Ｔ）

こちらは朝の５時、CAdESとXAdESの属性証明書関連の参照情報・値情報の記述でよせばいいのに標準策定者の属性証明書の認識不足から来る、重箱の隅をつつくような、でも大きな議論に発展しそうな問題を見つけてしまったような気がする、、、、、、、見つけなきゃ良かった、、、、（Ｔ＿Ｔ）

次のプラグテストに間に合うように一応資料は作ってみる予定、、、、このブログでも紹介できるとよいなぁ、、と思います。

属性証明書は面倒臭いし殆ど誰も使ってないので、修正したとしても誰も喜ばないですし、突っ込んでもしょうがないんですけどね、、、、(じゃぁ、仕様に入れるな、みたいな、、、、（＾＾；

今、１８：１５、ミーティング一日目ようやく終わりました。実りはあったような無かったような微妙な感じですね。CAdESのテスト用のファイル名のゴタゴタがやや解決したようなので、まぁ、それはよかったかなと、、、、、

９：００からきっかり始まったので相当疲れて脳がスポンジのようです（Ｔ＿Ｔ）

２１時スタートでカルロスさんの知り合いの弁護士の人と一緒に会食しましょうということになってしまい、これまた大変。一日は長い、、、、、
＜追記＞
弁護士の方と会うのはカルロスさんだけで、大学の予算関係のことだそう。自分の英語力しょぼすぎ（Ｔ＿Ｔ）ＳＴＦメンバだけで２１時にオープンする地元の人しか来なさそうな創作フレンチっぽいレストランに行きました。
地図だけぽっと渡されて店に現地集合だったので、心細かったんですが、何とかトラムに乗って、ZARAでお土産になりそうなもの見たりして時間を潰し店まで辿りつきました。５分前頃行ったら先にピーターが来て、他のお客さんもズラ〜〜ッと１０人ぐらい店の前で待っていました。月曜だというのに結構人気の店なのかも。

アボカドと蟹のイチゴソース添え、海老とズッキーニのカレーソース・ライス添えなんか食べてなかなか美味しかったです。（良かった、英語のメニューくれて。スペイン語なんか読めるわけがないし、説明されてもよくわからない）写真撮るのは恥ずかしくてやめてしまった、、、、撮ればよかった、、、、

今日の２枚：




カタルーニャ工科大の研究室棟のところでは、過去の計算機とかが展示されてるんですが、この「１」って書いてあるのが1986年のCentury Data Systems社のハードディスクです。私はロクロか揚水ポンプかと思いましたよ。「１」の数字の下の黒いのがディスクを回すためのモーターだと思います。手前の「５」が3.5インチのサムソンのフツーのハードディスクなので大きさも迫力あるでしょ。





これは、名機 DEC VAX-11です。大学で触ったことがあります。これは処理速度が1 MIPSなんですが、Pentium 4で9700 MIPSぐらいあるそうです。MD5 Chosen-Prefix Collisionsで有名になったPS3は18000 MIPSぐらいあるそうです。ありゃ、でもPS3のやつは流行のグラフィックスチップを使った計算だからもっと速いのかな、、、、