2023-08-30
製品マニュアル公開中 [by miyachi]
XML長期署名ライブラリLE:XAdES:LibをV3にバージョンアップしました。V2まではきちんとしたマニュアルを提供していませんでしたが、V3ではきちんとマニュアルを作成しました。参考の為にLE:XAdES:Lib V3マニュアル公開中です。
PDF長期署名ライブラリLE:PAdES:Lib（LE:PAdES-Basic:Lib含）もマニュアルをバージョンアップしています。またPKI基本ライブラリLE:PKI:Libに関してはLE:XAdES:Lib V3と共通化したことでマニュアルを分けました。
＞現在以下の製品マニュアルを公開中です。
〇PAdES：LE:PAdES:Lib/LE:PAdES-Basic:Libマニュアル(PDF長期署名)
〇XAdES：LE:XAdES:Lib V3マニュアル(XML長期署名)
〇PKI(共通)：LE:PKI:Libマニュアル(証明書やタイムスタンプの利用)
〇クライアント署名(オプション)：LE:Client:Signマニュアル(ブラウザ連携)
製品説明が主目的ですがPAdESやXAdESの説明もありますのでよろしければご覧ください。また製品検討時の参考資料としても自由にご利用ください。なお評価版にもマニュアルは同梱されています。
PDF長期署名ライブラリLE:PAdES:Lib（LE:PAdES-Basic:Lib含）もマニュアルをバージョンアップしています。またPKI基本ライブラリLE:PKI:Libに関してはLE:XAdES:Lib V3と共通化したことでマニュアルを分けました。
＞現在以下の製品マニュアルを公開中です。
〇PAdES：LE:PAdES:Lib/LE:PAdES-Basic:Libマニュアル(PDF長期署名)
〇XAdES：LE:XAdES:Lib V3マニュアル(XML長期署名)
〇PKI(共通)：LE:PKI:Libマニュアル(証明書やタイムスタンプの利用)
〇クライアント署名(オプション)：LE:Client:Signマニュアル(ブラウザ連携)
製品説明が主目的ですがPAdESやXAdESの説明もありますのでよろしければご覧ください。また製品検討時の参考資料としても自由にご利用ください。なお評価版にもマニュアルは同梱されています。
2021-04-05
Re:ゼロから始める長期署名 [by miyachi]
Qiitaに「Re:ゼロから始める長期署名」を公開しました。ご笑覧ください。長期署名についての書籍も古いものしか無かったり、いまさら長期署名の基礎を解説する記事も無かったり、と言うことであらためて基本から書いてみました。新しい長期署名フォーマットとしてJSONベースのJAdES仕様が公開されましたので簡単にそれにも触れています。
https://qiita.com/lemiyachi/items/87d698e51e4a53c721d6
https://qiita.com/lemiyachi/items/87d698e51e4a53c721d6
2015-02-20
PAdES Remote Plugtests 2015 [by miyachi]
ETSIの次プラグテストは5月4～29日でPAdESとアナウンスされました。現在ETSIでは各長期署名仕様を見直してEN化しています。今回のプラグテストはそのdraftをベースに仕様チェックを兼ねているようです。
[PAdES Remote Plugtests 2015]
http://www.etsi.org/news-events/events/887-pades-remote-plugtests-2015
[Draft ETSI EN 319 102-1 V0.12.0 (2015-2)]
http://docbox.etsi.org/ESI/Open/Latest_Drafts/prEN-319102-1v0120-SigCreationAndValidationProcedures-STABLE-DRAFT.pdf （PDF注意）
今回も参加費は無料ですがNDAは交わす必要があります。弊社製品も参加して相互運用性のチェックを予定しています。結果はNDAがあるので公開できないんですが互換性は確実に上がると思います。
日本でもこのような相互運用性試験やりたいですね。そのうちJNSAで何とかと考えてはいますがどうなりますか。何はともあれPAdES実装をお持ちのベンダー・メーカーさんは是非ご参加を！
[PAdES Remote Plugtests 2015]
http://www.etsi.org/news-events/events/887-pades-remote-plugtests-2015
[Draft ETSI EN 319 102-1 V0.12.0 (2015-2)]
http://docbox.etsi.org/ESI/Open/Latest_Drafts/prEN-319102-1v0120-SigCreationAndValidationProcedures-STABLE-DRAFT.pdf （PDF注意）
今回も参加費は無料ですがNDAは交わす必要があります。弊社製品も参加して相互運用性のチェックを予定しています。結果はNDAがあるので公開できないんですが互換性は確実に上がると思います。
日本でもこのような相互運用性試験やりたいですね。そのうちJNSAで何とかと考えてはいますがどうなりますか。何はともあれPAdES実装をお持ちのベンダー・メーカーさんは是非ご参加を！
2013-03-21
電子署名の系譜 [by miyachi]
先日何に使う訳でもないのですがふと電子署名データフォーマットの系譜でもまとめてみるかと言う事で作った１枚の画。う～ん思った以上につまらなかったですねw
実はこちらは画にする必要も無い電子署名の系譜があったりします。それは日本の電子署名標準化に関する系譜です。先日弊社も加盟しているeRAP「電子記録応用基盤フォーラム」の成果報告会がありました。eRAPではかつてECOMが行ってきた電子署名標準化の作業を引き継いで来ました。ECOMでは長期署名のJIS化を、eRAPではISO化を達成しています。ところがeRAPはフォーラムとしては今年度を最後に終了して、来年度は研究会としてケースマネージメント等の活動を行う予定です。電子署名標準化の作業は残念ながら継続されない事になりました。と言うことで成果報告会にてセコムの佐藤さんの発表の最後に以下のアナウンスがありました！
「今後の電子署名技術に関する調査研究はJNSA（日本ネットワークセキュリティ協会）の電子署名WG（仮称）で活動予定。近日キックオフミーティング予定。」
弊社もJNSAに４月より加盟して同WG活動に参加予定です。近年また電子署名のお話が増えて来ているように感じています。参加すると勉強にもなりますし新しい技術もいち早く知ることができます。ご興味がありましたら是非ご参加ください！最初は見学からでもＯＫだと思います。弊社にご連絡頂いても大丈夫です。と言うことで日本の電子署名標準化の系譜は「ECOM→eRAP→JNSA」になります！
さて閑話休題（長い閑話だったなぁw いや正確にはこの後が閑話か(^^;）。せっかく書いた電子署名データフォーマットの系譜について簡単に個人的感想を付けてみましょう。 [続きを読む]
実はこちらは画にする必要も無い電子署名の系譜があったりします。それは日本の電子署名標準化に関する系譜です。先日弊社も加盟しているeRAP「電子記録応用基盤フォーラム」の成果報告会がありました。eRAPではかつてECOMが行ってきた電子署名標準化の作業を引き継いで来ました。ECOMでは長期署名のJIS化を、eRAPではISO化を達成しています。ところがeRAPはフォーラムとしては今年度を最後に終了して、来年度は研究会としてケースマネージメント等の活動を行う予定です。電子署名標準化の作業は残念ながら継続されない事になりました。と言うことで成果報告会にてセコムの佐藤さんの発表の最後に以下のアナウンスがありました！
「今後の電子署名技術に関する調査研究はJNSA（日本ネットワークセキュリティ協会）の電子署名WG（仮称）で活動予定。近日キックオフミーティング予定。」
弊社もJNSAに４月より加盟して同WG活動に参加予定です。近年また電子署名のお話が増えて来ているように感じています。参加すると勉強にもなりますし新しい技術もいち早く知ることができます。ご興味がありましたら是非ご参加ください！最初は見学からでもＯＫだと思います。弊社にご連絡頂いても大丈夫です。と言うことで日本の電子署名標準化の系譜は「ECOM→eRAP→JNSA」になります！
さて閑話休題（長い閑話だったなぁw いや正確にはこの後が閑話か(^^;）。せっかく書いた電子署名データフォーマットの系譜について簡単に個人的感想を付けてみましょう。 [続きを読む]
2012-06-08
XML長期署名ツール LE:XAdES:Tool Ver2.00B1 公開 [by miyachi]
XAdES v1.4.1/1.4.2に対応したXML長期署名ツール「LE:XAdES:Tool」のVer2.00ベータ1版をリリースしました。ETSIのXAdESプラグテストで利用した機能が組み込まれています。ダウンロードはこちらから！
Ver2となったこともありイメージも少し変更し名称も「XAdEStool」から「LE:XAdES:Tool」としました。ちなみに「Le-XAdESライブラリ」もVer2.00からは「LE:XAdES:Lib」と名称変更の予定です。「LE:XAdES:Lib」は簡単なマニュアルも用意しようとしている為に今しばらくリリースまで時間が必要ですが、先に「LE:XAdES:Tool」で機能をお試しください。なお更新の詳細は readme.txt をご覧ください。
なお「LE:XAdES:Lib」はVer2.00より少しAPIや利用方法に変更があります。その辺りの移行手順もマニュアルにまとめる予定です。「LE:XAdES:Lib」のVer2.00正式リリースまではベータ版として「LE:XAdES:Tool」をリリースします。XML長期署名ツール「LE:XAdES:Tool」は試験または個人利用の目的で公開されております。商用利用は不可となっておりますのでご了解ください。
何かありましたら本投稿にコメントを頂くかメールをお願いします。それではお楽しみください！
2012-04-06
XAdES 1.4.1/1.4.2：第４回 サンプルファイル他 [by miyachi]
さて技術的な説明は前回と前々回で終わったと考えています。最終回の今回はまず実際のサンプルファイルを見てみましょう。早速ですが以下はXAdES 1.3.2とXAdES 1.4.1/1.4.2でそれぞれ署名したES-A（保管タイムスタンプ付）のサンプルファイルです。弊社のLe-XAdESのVer1.5ベータ版で作成してあります。
[続きを読む]
2012-04-05
XAdES 1.4.1/1.4.2：第３回 XAdESv141:ArchiveTimeStamp [by miyachi]
さて1日間が空きましたが第３回は前回説明したXAdESv141:TimeStampValidationDataと同じくXAdES 1.4.1/1.4.2で新しく追加されたXAdESv141:ArchiveTimeStampについての説明です。名前の通り保管タイムスタンプなのですがXAdES 1.3.2とは互換性がありませんので名前空間で区別して利用する必要があります。
では今回もそもそもなぜ新しい保管タイムスタンプであるXAdESv141:ArchiveTimeStampが必要になるのかと言う話からしましょう。前回XAdESの非署名領域であるUnsignedSignatureProperties要素の下にタイムスタンプ用の検証情報格納場所であるXAdESv141:TimeStampValidationDataが追加された事を説明しました。UnsignedSignatureProperties要素の下にはSchema的には任意の要素の追加が可能なので問題ありません。
一方XAdESv132:ArchiveTimeStampの計算時にはUnsignedSignatureProperties要素の下の決められた要素を順番に取得して連結して行く仕様となっています。この決められた要素とは全てXAdES 1.3.2で定義されたSignatureTimeStamp要素やCertificateValues要素等でありXAdESv141:TimeStampValidationData要素が含まれていません。これではせっかくXAdES 1.4.1/1.4.2で追加したXAdESv141:TimeStampValidationData要素の下が保護出来ない事になってしまいます。そこでArchiveTimeStampの計算方法として「UnsignedSignatureProperties要素の下を全て対象とする」XAdESv141:ArchiveTimeStamp要素を追加して解決したと言う事です。
ただそれだけでは無くもう１点ds:Objectの扱いについても変更がありました。XAdES 1.3.2では「Reference要素で参照されていないds:Object」が対象でしたが、XAdES 1.4.1/1.4.2では「全てのds:Object」が対象となりました。なお正確には「XAdESの要素であるQualifyingPropertiesを持つds:Objectは除外する」と言うルールもありますがこれはXAdES 1.3.2とXAdES 1.4.1/1.4.2の両方に共通しています。
以上をまとめると以下のようになります。
１）XAdES 1.3.2における保管タイムスタンプ仕様（一部）
１：UnsignedSignatureProperties要素の下の決められた要素を連結
２：Reference参照されていない全てのds:Objecctを連結 ※
２）XAdES 1.4.1/1.4.2における保管タイムスタンプ（一部）
１：UnsignedSignatureProperties要素の下の全ての要素を連結
２：Reference参照有無に関係無く全てのds:Objecctを連結 ※
※ ただしXAdESのQualifyingPropertiesを持つds:Objectは除外する。
計算方法が2箇所異なるので、当然計算結果のハッシュ値もXAdES 1.3.2とAdES 1.4.1/1.4.2では異なり一致しません。XAdESv141:TimeStampValidationData要素への対応の為に異なる保管タイムスタンプが生まれてしまいました。
なおXAdES 1.4.1のSchemaではXAdESv141:ArchiveTimeStampV2と書かれていましたがこれは誤りで、V2が無いXAdESv141:ArchiveTimeStampが正しい要素名となります。これはXAdES 1.4.2で訂正されています。 [続きを読む]
では今回もそもそもなぜ新しい保管タイムスタンプであるXAdESv141:ArchiveTimeStampが必要になるのかと言う話からしましょう。前回XAdESの非署名領域であるUnsignedSignatureProperties要素の下にタイムスタンプ用の検証情報格納場所であるXAdESv141:TimeStampValidationDataが追加された事を説明しました。UnsignedSignatureProperties要素の下にはSchema的には任意の要素の追加が可能なので問題ありません。
一方XAdESv132:ArchiveTimeStampの計算時にはUnsignedSignatureProperties要素の下の決められた要素を順番に取得して連結して行く仕様となっています。この決められた要素とは全てXAdES 1.3.2で定義されたSignatureTimeStamp要素やCertificateValues要素等でありXAdESv141:TimeStampValidationData要素が含まれていません。これではせっかくXAdES 1.4.1/1.4.2で追加したXAdESv141:TimeStampValidationData要素の下が保護出来ない事になってしまいます。そこでArchiveTimeStampの計算方法として「UnsignedSignatureProperties要素の下を全て対象とする」XAdESv141:ArchiveTimeStamp要素を追加して解決したと言う事です。
ただそれだけでは無くもう１点ds:Objectの扱いについても変更がありました。XAdES 1.3.2では「Reference要素で参照されていないds:Object」が対象でしたが、XAdES 1.4.1/1.4.2では「全てのds:Object」が対象となりました。なお正確には「XAdESの要素であるQualifyingPropertiesを持つds:Objectは除外する」と言うルールもありますがこれはXAdES 1.3.2とXAdES 1.4.1/1.4.2の両方に共通しています。
以上をまとめると以下のようになります。
１）XAdES 1.3.2における保管タイムスタンプ仕様（一部）
１：UnsignedSignatureProperties要素の下の決められた要素を連結
２：Reference参照されていない全てのds:Objecctを連結 ※
２）XAdES 1.4.1/1.4.2における保管タイムスタンプ（一部）
１：UnsignedSignatureProperties要素の下の全ての要素を連結
２：Reference参照有無に関係無く全てのds:Objecctを連結 ※
※ ただしXAdESのQualifyingPropertiesを持つds:Objectは除外する。
計算方法が2箇所異なるので、当然計算結果のハッシュ値もXAdES 1.3.2とAdES 1.4.1/1.4.2では異なり一致しません。XAdESv141:TimeStampValidationData要素への対応の為に異なる保管タイムスタンプが生まれてしまいました。
なおXAdES 1.4.1のSchemaではXAdESv141:ArchiveTimeStampV2と書かれていましたがこれは誤りで、V2が無いXAdESv141:ArchiveTimeStampが正しい要素名となります。これはXAdES 1.4.2で訂正されています。 [続きを読む]
2012-04-03
XAdES 1.4.1/1.4.2：第２回 XAdESv141:TimeStampValidationData [by miyachi]
さて今回はXAdES 1.4.1/1.4.2で新しく追加された要素のうちタイムスタンプの検証情報を保管するXAdESv141:TimeStampValidationDataについて私の理解の範囲で説明しましょう。
そもそも何故XAdESv141:TimeStampValidationDataが必要になるのかと言う話からする必要がありますね。XAdESをはじめとする長期署名は基本的には「署名」＋「タイムスタンプ」（これがES-T形式）となります。PDF長期署名のPAdESでは「(文書)タイムスタンプ」だけで「署名」無しの仕様も可能ですが、XAdES/CAdESでは署名抜きでタイムスタンプだけの仕様はありません。
タイムスタンプのRFC3161仕様とは乱暴に言えばサーバによる「署名」と言えます。つまり「署名」＋「タイムスタンプ」では2つの「署名」がある事になります。それぞれの「署名」についてEE(署名者)証明書が存在しており、かつトラストアンカーとなるルート証明書までの証明書パス（チェーン）が存在する事になります。
もし「署名」と「タイムスタンプ」で同じトラストアンカーのルート証明書を使うのであれば同じ証明書とCRL等の検証情報で良いので証明書パスは1つだけですみます。過去にXAdESの国際プラグテストを行った時には署名証明書とタイムスタンプは同じトラストアンカーを利用していました。欧州等ではどうもこのような運用が一般的だったようです。
一方日本では主に「署名」に関しては経済産業省の管轄であり「タイムスタンプ」は時刻に関係があるので総務省の管轄で認証局とタイムスタンプ局が別々に認定されてきました。このために「署名」と「タイムスタンプ」ではトラストアンカーとなるルート証明書が異なります。そうすると証明書パスは「署名」と「タイムスタンプ」の2つが必要となります。
少なくとも日本では証明書パス（と正確にはそれらに必要な検証情報群）は2つ格納する必要があります。ところがXAdES 1.3.2の仕様では証明書はCertificateValues要素下に格納し検証情報はRevocationValues要素下に格納できるだけです。かつCertificateValues要素とRevocationValues要素は1つだけしか認められません。つまり証明書パスの情報を格納するのは1ヶ所しか無いのです。本来CertificateValues要素とRevocationValues要素には「署名」に関する証明書パスと検証情報を格納する事になっています。
このままでは「タイムスタンプ」の証明書パスと検証情報をXML要素として格納する事ができません。そこでJIS化する際に以下のルールが定義されました。
署名タイムスタンプ(SigTS)の証明書と検証情報：
１）タイムスタンプトークン自身に埋め込む
２）CertificateValues要素とRevocationValues要素に入れる
保管タイムスタンプ(ArcTS)の証明書と検証情報：
１）タイムスタンプトークン自身に埋め込む
正確にはタイムスタンプトークンのどこに埋め込むかによって更に種類は分かれますがここの本題では無いので省略します。CertificateValues要素とRevocationValues要素に関しては意味を広義にとって署名タイムスタンプについては利用しても良いとしました。保管タイムスタンプはその時刻が常にRevocationValues要素に埋め込まれたCRL発行日よりも後になるので利用できません。
これでめでたしめでたし…なのですが証明書や検証情報を「タイムスタンプトークン自身に埋め込む」には以下の意見がありました。
１）XMLだけでなくASN.1/DER(BER)の操作が必要になり難しい
２）取得したタイムスタンプトークンはそのまま利用すべき
３）XMLの利点である可読性の面から望ましくない
４）CertificateValues/RevocationValuesは署名証明書のみにすべき
どれも問題点と言うレベルでは無いのですが、特に１）のASN.1/DER(BER)の操作については技術的なハードルが高くなるので実装者が苦労すると嫌がられています。ちなみに日本ではどのベンダーもタイムスタンプトークン自身に埋め込む方式に対応しています。JIS対応するには必須ですから当然ですね。しかし欧州では…げふんげふんw ここでXAdESv141:TimeStampValidationDataの登場です。 [続きを読む]
そもそも何故XAdESv141:TimeStampValidationDataが必要になるのかと言う話からする必要がありますね。XAdESをはじめとする長期署名は基本的には「署名」＋「タイムスタンプ」（これがES-T形式）となります。PDF長期署名のPAdESでは「(文書)タイムスタンプ」だけで「署名」無しの仕様も可能ですが、XAdES/CAdESでは署名抜きでタイムスタンプだけの仕様はありません。
タイムスタンプのRFC3161仕様とは乱暴に言えばサーバによる「署名」と言えます。つまり「署名」＋「タイムスタンプ」では2つの「署名」がある事になります。それぞれの「署名」についてEE(署名者)証明書が存在しており、かつトラストアンカーとなるルート証明書までの証明書パス（チェーン）が存在する事になります。
もし「署名」と「タイムスタンプ」で同じトラストアンカーのルート証明書を使うのであれば同じ証明書とCRL等の検証情報で良いので証明書パスは1つだけですみます。過去にXAdESの国際プラグテストを行った時には署名証明書とタイムスタンプは同じトラストアンカーを利用していました。欧州等ではどうもこのような運用が一般的だったようです。
一方日本では主に「署名」に関しては経済産業省の管轄であり「タイムスタンプ」は時刻に関係があるので総務省の管轄で認証局とタイムスタンプ局が別々に認定されてきました。このために「署名」と「タイムスタンプ」ではトラストアンカーとなるルート証明書が異なります。そうすると証明書パスは「署名」と「タイムスタンプ」の2つが必要となります。
少なくとも日本では証明書パス（と正確にはそれらに必要な検証情報群）は2つ格納する必要があります。ところがXAdES 1.3.2の仕様では証明書はCertificateValues要素下に格納し検証情報はRevocationValues要素下に格納できるだけです。かつCertificateValues要素とRevocationValues要素は1つだけしか認められません。つまり証明書パスの情報を格納するのは1ヶ所しか無いのです。本来CertificateValues要素とRevocationValues要素には「署名」に関する証明書パスと検証情報を格納する事になっています。
このままでは「タイムスタンプ」の証明書パスと検証情報をXML要素として格納する事ができません。そこでJIS化する際に以下のルールが定義されました。
署名タイムスタンプ(SigTS)の証明書と検証情報：
１）タイムスタンプトークン自身に埋め込む
２）CertificateValues要素とRevocationValues要素に入れる
保管タイムスタンプ(ArcTS)の証明書と検証情報：
１）タイムスタンプトークン自身に埋め込む
正確にはタイムスタンプトークンのどこに埋め込むかによって更に種類は分かれますがここの本題では無いので省略します。CertificateValues要素とRevocationValues要素に関しては意味を広義にとって署名タイムスタンプについては利用しても良いとしました。保管タイムスタンプはその時刻が常にRevocationValues要素に埋め込まれたCRL発行日よりも後になるので利用できません。
これでめでたしめでたし…なのですが証明書や検証情報を「タイムスタンプトークン自身に埋め込む」には以下の意見がありました。
１）XMLだけでなくASN.1/DER(BER)の操作が必要になり難しい
２）取得したタイムスタンプトークンはそのまま利用すべき
３）XMLの利点である可読性の面から望ましくない
４）CertificateValues/RevocationValuesは署名証明書のみにすべき
どれも問題点と言うレベルでは無いのですが、特に１）のASN.1/DER(BER)の操作については技術的なハードルが高くなるので実装者が苦労すると嫌がられています。ちなみに日本ではどのベンダーもタイムスタンプトークン自身に埋め込む方式に対応しています。JIS対応するには必須ですから当然ですね。しかし欧州では…げふんげふんw ここでXAdESv141:TimeStampValidationDataの登場です。 [続きを読む]
2012-04-02
XAdES 1.4.1/1.4.2：第１回 概要と名前空間 [by miyachi]
XMLの長期署名フォーマットであるXAdESの最新仕様はETSI（欧州電気通信標準化機構）が中心となって決定しています。日本では旧ECOM及び現在はeRAP（電子記録応用基盤フォーラム）が中心となってJISプロファイルを策定してきました。現在のJISプロファイル（JIS X 5093:2008）はXAdES 1.3.2をベースにしています。しかし実は新しいXAdES 1.4.1が既にリリースされており、更に1.4.1を更新したXAdES 1.4.2も2010年12月にリリースされています。ETSIのベースラインプロファイルも昨年リリースされ欧州では標準化作業が進展しています。ここまでのXAdES仕様の流れを以下にリストアップします。
(2005) ETSI XAdES 1.3.1 Draft
(2006-03) ETSI XAdES 1.3.2 [PDF]
(2008-05) JIS X 5093:2008 [案：PDF]
(2009-06) ETSI XAdES 1.4.1 [PDF]
(2010-12) ETSI XAdES 1.4.2 [PDF]
(2011-09) ETSI XAdES Baseline Profile [PDF]
XAdES 1.3.1の前にももちろん仕様が存在しますが今回の話には必要が無いのでここでは説明しません。またXAdESはベース仕様として XmlDsig（XML署名）[PDF] を使っています。しかしながらXAdES 1.4.1/1.4.2に関して言えば変更はありませんのでこれもここでは説明しません。
JISプロファイルもそろそろXAdES 1.4.1/1.4.2ベースに移行する必要があると思いますが色々な事情もあり（聞かないでw）まだ更新されていません。しかしながらそろそろ弊社のLe-XAdESライブラリもXAdES 1.4.1/1.4.2へ対応しようと作業を開始しました。その必要もあってXAdES 1.4.1/1.4.2仕様をまずは簡単にまとめたいと思います。 [続きを読む]
(2005) ETSI XAdES 1.3.1 Draft
(2006-03) ETSI XAdES 1.3.2 [PDF]
(2008-05) JIS X 5093:2008 [案：PDF]
(2009-06) ETSI XAdES 1.4.1 [PDF]
(2010-12) ETSI XAdES 1.4.2 [PDF]
(2011-09) ETSI XAdES Baseline Profile [PDF]
XAdES 1.3.1の前にももちろん仕様が存在しますが今回の話には必要が無いのでここでは説明しません。またXAdESはベース仕様として XmlDsig（XML署名）[PDF] を使っています。しかしながらXAdES 1.4.1/1.4.2に関して言えば変更はありませんのでこれもここでは説明しません。
JISプロファイルもそろそろXAdES 1.4.1/1.4.2ベースに移行する必要があると思いますが色々な事情もあり（聞かないでw）まだ更新されていません。しかしながらそろそろ弊社のLe-XAdESライブラリもXAdES 1.4.1/1.4.2へ対応しようと作業を開始しました。その必要もあってXAdES 1.4.1/1.4.2仕様をまずは簡単にまとめたいと思います。 [続きを読む]
2010-07-23
XAdES/CAdES Remote Plugtests Event 2010 [by miyachi]
ETSIによる長期署名（XAdES/CAdES）プラグテストのサイトオープンを、@kjurさんのつぶやきで知りました。以下に簡単に概要をまとめておきましょう。詳しくは以下サイトをご覧ください。
http://www.etsi.org/plugtests/XAdES-2010/XAdES-CAdES.htm
まずテスト期間は10月25日から11月05日までです。登録の締め切りは10月10日までとなっています。参加にはNDA締結が必要となります。料金は700ユーロでETSIメンバーだと650ユーロ必要となります。それに19.6%の消費税が加算されます。実質10万円くらいでしょうか。今回は参加したことを宣伝に使っても良いそうです。
テストの目的は XAdES 1.3.2 と CAdES 1.7.4 ですが、新しいバージョンである XAdES 1.4.1 と CAdES 1.8.1 のテストも行われます。後はRSA-SHA2署名もテストしてくる参加実装もあるんじゃ無いかと思います。
参加者は前回まではバラエティに富んでいて、実装レベルもバラエティに富んでいましたので良く言えば勉強になりますし、悪く言えば大変な部分もあります。またNDAが必要ですがPDFをダウンロードして印刷して手書き署名後に再PDF化して返信すればＯＫのはずです。前回はそうでした。電話会議もありますが英語に自信が無ければチャット参加も可能です。私はチャットのみで参加しました。弊社の実装もそうですが例えばXAdESの全ての仕様の実装がされていなくても可能な範囲だけでも参加できます。
前回は私も初参加だった関係で@kjurさんには大変お世話になりました。今更ですが、あの時はありがとうございましたm(_ _)m ＞ @kjurさん
eRAPに未参加の企業でも参加できますので、長期署名を実装されている皆様参加してみませんか？弊社ですか？う～ん今回はどうしようかなと検討中です(^^;;
そう言えばPAdESのプラグテストは行われないのかなぁ…
http://www.etsi.org/plugtests/XAdES-2010/XAdES-CAdES.htm
まずテスト期間は10月25日から11月05日までです。登録の締め切りは10月10日までとなっています。参加にはNDA締結が必要となります。料金は700ユーロでETSIメンバーだと650ユーロ必要となります。それに19.6%の消費税が加算されます。実質10万円くらいでしょうか。今回は参加したことを宣伝に使っても良いそうです。
テストの目的は XAdES 1.3.2 と CAdES 1.7.4 ですが、新しいバージョンである XAdES 1.4.1 と CAdES 1.8.1 のテストも行われます。後はRSA-SHA2署名もテストしてくる参加実装もあるんじゃ無いかと思います。
参加者は前回まではバラエティに富んでいて、実装レベルもバラエティに富んでいましたので良く言えば勉強になりますし、悪く言えば大変な部分もあります。またNDAが必要ですがPDFをダウンロードして印刷して手書き署名後に再PDF化して返信すればＯＫのはずです。前回はそうでした。電話会議もありますが英語に自信が無ければチャット参加も可能です。私はチャットのみで参加しました。弊社の実装もそうですが例えばXAdESの全ての仕様の実装がされていなくても可能な範囲だけでも参加できます。
前回は私も初参加だった関係で@kjurさんには大変お世話になりました。今更ですが、あの時はありがとうございましたm(_ _)m ＞ @kjurさん
eRAPに未参加の企業でも参加できますので、長期署名を実装されている皆様参加してみませんか？弊社ですか？う～ん今回はどうしようかなと検討中です(^^;;
そう言えばPAdESのプラグテストは行われないのかなぁ…
2010-06-11
MS-Office2010の長期署名仕様解析 [by miyachi]
以前にもベータ版の時に書きましたが、MS-Office2010では標準のデジタル署名が長期署名（XAdES-EPES）になりました。弊社はボリュームライセンスなのでダウンロードで正式版が入手できたので仕様の解析をしてみました。まずは簡単なスライドの表示です。
上のスライドの説明は [続きを読む] にて。上のスライドが見えない場合同じ内容のPDFはこちら（約170KB）。 [続きを読む]
上のスライドの説明は [続きを読む] にて。上のスライドが見えない場合同じ内容のPDFはこちら（約170KB）。 [続きを読む]
2010-04-02
MS Office 2010でXAdES署名に対応 [by miyachi]
kjurさんの「自堕落な技術者の日記」にてMicrosoft Office 2010にてXAdESを利用可能とのニュースを知る。おお！遂にMicrosoftが長期署名をサポートかと感慨深いものが。
しかしながらベータ公開版ではXAdES-Tまでらしい。試してみたいけど時間が無いのでとりあえず見送り。時間が出来たら入れてみよう。正式版になってもXAdES-X-Longまでで、保管タイムスタンプを使ったXAdES-Aには対応しないらしい。
どうもXAdESは組み込んだけどまだGUIも変更して本格的な導入では無いようだ。XAdES-C/X-Long等も署名時点の物が使われるようで猶予期間は考慮されないようだし、保管タイムスタンプにも後から付与する必要があるので未対応と言うところか。
MicrosoftがXAdESに対応したと言うのは大きい。後AdobeもPAdES（PDF長期署名）のやる気が満々だし。MSとAdobeが長期署名に対応したら普及にも弾みが付きそうです。過去にはこのネタで論文まで書いてしまったので正式サポートは嬉しいです。
Office 2010のベータ版ダウンロードはこちらです。正式リリースは今年前半とのこと。
しかしながらベータ公開版ではXAdES-Tまでらしい。試してみたいけど時間が無いのでとりあえず見送り。時間が出来たら入れてみよう。正式版になってもXAdES-X-Longまでで、保管タイムスタンプを使ったXAdES-Aには対応しないらしい。
どうもXAdESは組み込んだけどまだGUIも変更して本格的な導入では無いようだ。XAdES-C/X-Long等も署名時点の物が使われるようで猶予期間は考慮されないようだし、保管タイムスタンプにも後から付与する必要があるので未対応と言うところか。
MicrosoftがXAdESに対応したと言うのは大きい。後AdobeもPAdES（PDF長期署名）のやる気が満々だし。MSとAdobeが長期署名に対応したら普及にも弾みが付きそうです。過去にはこのネタで論文まで書いてしまったので正式サポートは嬉しいです。
Office 2010のベータ版ダウンロードはこちらです。正式リリースは今年前半とのこと。
2010-01-18
論文「Office Open XMLに対する長期署名の付与」 [by miyachi]
NII（国立情報学研究所）の先生方と共著の論文が情報知識学会に採択され早期公開されています。
情報知識学会誌
「Office Open XMLに対する長期署名の付与」
山地 一禎, 片岡 俊幸, 宮地 直人, 曽根原 登
私にとっては初めての本格的な論文となりましたので採用されるまでのプロセスが大変刺激的で勉強になりました。内容はMS-Office2007から採用されたOOXML形式のXMLドキュメントに対してXML署名をXAdESによる長期署名にした場合の問題の考察と解決法の提案と実装結果に関するものです。ご興味がありましたらぜひご覧下さい。
情報知識学会誌
「Office Open XMLに対する長期署名の付与」
山地 一禎, 片岡 俊幸, 宮地 直人, 曽根原 登
私にとっては初めての本格的な論文となりましたので採用されるまでのプロセスが大変刺激的で勉強になりました。内容はMS-Office2007から採用されたOOXML形式のXMLドキュメントに対してXML署名をXAdESによる長期署名にした場合の問題の考察と解決法の提案と実装結果に関するものです。ご興味がありましたらぜひご覧下さい。
2010-01-08
XAdES tool Ver1.30R2 をリリース [by miyachi]
弊社開発のLe-XAdESライブラリを利用したXML長期署名ツールXAdEStoolをバージョンアップしたVer1.30R2版を本日リリースしました。ダウンロードはこちら(XAdEStool)から。今回のバージョンアップでは、CAPICOM非依存をはじめとして各種機能アップが行われています。
詳しくは同梱のXAdEStoolドキュメントをご覧下さい。
XAdEStoolのVer1.30R2版に関してのバグ報告や質問やコメントがありましたら本投稿にコメントかmiyachiまでメールをお願いします。
Ver1.30R2に関して詳しくは後日少しずつ説明をして行く予定です。とり急ぎバイナリの公開まで。
詳しくは同梱のXAdEStoolドキュメントをご覧下さい。
XAdEStoolのVer1.30R2版に関してのバグ報告や質問やコメントがありましたら本投稿にコメントかmiyachiまでメールをお願いします。
Ver1.30R2に関して詳しくは後日少しずつ説明をして行く予定です。とり急ぎバイナリの公開まで。
2009-06-19
シリーズ長期署名１：長期署名入門 [by miyachi]
弊社の製品であるXML長期署名ライブラリLe-XAdESに関連して長期署名の説明や問題点やその回避方法や考え方をまとめたシリーズをはじめます。第１回は長期署名入門と言うことで簡単にまとめます。
まず電子署名と長期署名は何が違うかを考えてみましょう。電子署名は公開鍵方式暗号による電子証明書（公開鍵）と私有（秘密）鍵を利用したPKIと言う枠組みの中で、「誰が」「何に」を保証する技術として古くから使われて来ました。しかしここで２つ足りない要素があります。
１） 「何時（いつ）」が保証されない。
２） 電子証明書に有効期限があり保証期間が有限。
これを補う目的で考えられた仕様が長期署名と言うことになります。１）に対してはPKIベースのタイムスタンプ技術を使うことで「何時」を保証し、２）に対しても同様にタイムスタンプ技術と検証に必要な情報を保管することで電子証明書の有効期限を超えて保証することが出来ます。１）のタイムスタンプを署名（シグネチャ）タイムスタンプと、２）のタイムスタンプを保管（アーカイブ）タイムスタンプと、呼びます。保管タイムスタンプは重ねて適用が可能な為に有効期間を延長して行くことも可能になります。
[続きを読む]
