自堕落な技術者の日記

2015年5月7日に「RFC 7525 TLSとDTLSの安全な利用に関する推奨事項(Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS))」が公開されました。

昨年あたり、SSL/TLSで使われる暗号アルゴリズム、プロトコルや実装にいろいろな問題が見つかり、製品をそのままデフォルトで使っているとロクなことが無いわけですが、どんなことに注意しながら実装や設定をしなければならないかをベストカレントプラクティス(現時点での最良の慣行)としてまとめたRFCだそうです。

最近、SSL/TLSの設定ネタでお話しする機会を頂いたりしておりますが [1] [2] 、RFC 7525をざっと見たところ、概ね違ったことは言ってないようにおもいます。今日は、RFC 7525について、ちょっと見てみたところを書いていきたいと思います。

RFC 7525の目的

RFC 7525の目的は、仕様から以下の2つなのかなと思います。

• 最低限満たすべき推奨事項を示す。
• TLS 1.3が普及するまでのつなぎで対応しておくべき事を示す。

RFC 7525のポイント

各節から拾ってきたRFC 7525のポイントをまとめると以下のようになります。

• 3.1.1節 TLSプロトコル
  • POODLE等の対策として、SSLv2、SSLv3の利用禁止(MUST NOT)
  • CBCモード対策としてTLS 1.0の利用抑制(SHOULD NOT)
  • TLS 1.2の実装必須(MUST)
  • TLS 1.2、TLS 1.1、TLS 1.0の順で優先(MUST)
• 3.1.2節 DTLSプロトコル
  • DTLS 1.0の利用抑制(SHOULD NOT)
  • DTLS 1.2の実装必須(MUST)
  • DTLS 1.2、DTLS 1.0の順で優先(MUST)
• プロトコルその他
  • 3.1.3節 TLS 1.x からSSLv2、SSLv3のフォールバック禁止(MUST NOT)
  • 3.2節 HSTS(HTTP Strict Transport Security)ヘッダのサポート必須(MUST)
  • 3.3節 CRIME攻撃等の回避のためTLS圧縮を利用抑止(SHOULD)
  • 3.4節 セッション再開でセッションチケットの通信における認証と暗号化は必須(MUST)
  • 3.5節 TLS再ネゴシエーションが必要な場合、renegotiation_info拡張のサポート必須(MUST)
  • 3.6節 Server Name Indication(SNI)のサポート必須(MUST)
  • 4.5節 Truncated HMAC TLS拡張の利用禁止(MUST NOT)
  • 6.5節 証明書失効検証では、OCSP、status_request・status_request_v2 TLS拡張、OCSP stapling拡張を利用すべき(SHOULD)
• 4節 暗号スイートの推奨
  • NULL暗号スイートでの接続禁止(MUST NOT)
  • RC4暗号スイートでの接続禁止(MUST NOT)
  • EXPORT等、112ビット未満の暗号スイートでの接続禁止(MUST NOT)
  • 128ビット未満の暗号スイートでの接続抑止(SHOULD NOT)
  • TLS_RSA_WITH_*の接続抑制(SHOULD NOT)
  • DHE、ECDHEなどPFSをサポートする暗号スイートの優先接続のサポート(MUST)
  • TLS_{DHE,ECDHE}_RSA_WITH_AES_{128,256}_GCM_SHA{256,384}を推奨(RECOMMENDED)
• 4.3節 公開鍵長
  • DHE鍵交換の場合、DH鍵長は2048bit以上を推奨(RECOMMENDED)
  • ECDH鍵の場合、192bit未満の曲線は利用抑止(SHOULD NOT)
• 4.3節 証明書
  • RSA場合、鍵長2048bit以上の証明書を推奨(RECOMMENDED)
  • 証明書の署名はSHA-256の利用を推奨(RECOMMENDED)

RFC 7525を見て気になった点

気になった点や感想的なものをまとめてみます。

• 最小限の推奨事項といいながら、MUST、SHOULDに従ったとするとかなり厳格な要件で、これに対応できるのは最新のウェブブラウザ、ウェブサーバーのみであり、ちょっと前の組み込み機器、SSLアクセラレーターなどは、これらの要件を満たすことは不可能かなと思います。
• やはり、最新のソフトウェアのみで対応すればよい環境と、後方互換性を必要とする環境とで区別して推奨事項を述べるのがよいのではと思います。
• RSA鍵交換を抑制(SHOULD)する一方で、SEED、IDEA、Camelliaなど言及されないアルゴリズムも多く、これらの扱う際に混乱します。
• PFSやRC4を強調しすぎで、CBCモードは軽視されている。
• 鍵長の話はもう少しシンプルに纏められたのではと思う。文章が整理されておらずわかりにい。
• アプリケーションプロトコル(HTTP, SMTP, IMAP, IRC, XMPP等)の言及はあまり役立たない。
• 証明書要件はRECOMMENDEDと、かなり緩め。

RFC 7525の良かった点

一方、このRFC 7525の良かった点はこんなとこかなと、、、

• 何を根拠(Rationale)としてそのような設定を要求するのかが明らかになっており良い。
• 実装(implementation)と展開(deployment)を分けて書いてあるのはよい。
• Opportunistic Securityについて、単なるフォールバックよりも危険が懸念されることを明確にし、RFC 7525の対象外としたのは良い。
• 証明書失効の課題が整理されたのは良い。
• 特に、プロプライエタリな失効検証がスケールしない点を指摘したのは良い。

おわりに

RFC 7525はベストカレントプラクティスと言いながら、少しトガった要求事項になっていて、最新の環境だけでしか動かない感じです。InternetWeekでお話をした時から、状況もいろいろ変わっていて、現時点での暗号スイート設定のおすすめは、近々書きたいと思っています。あと、メジャーなサーバーでの設定ファイルを作るウェブツールなども作ってしまいたいと思ってるんですが、なかなか先に進まない。

来週の情報セキュリティExpoでは、IPAさんのブースで私も委員として作成に携わらせて頂いた「SSL/TLS暗号設定ガイドライン」の説明もあったりするそうです。このガイドは主にサーバー管理者向けに幾つかのケースに分けてセキュリティ要件を定めて設定例を示したもので、RFC 7525 よりは、より具体的にどうすればよいかがわかるようになっています。最後の委員会が終わったあとも、リクエストがあったので追加原稿はいろいろ出させて頂いたんですが、どうも最終的に、特に暗号スイートの設定について、思った通りのものにはならなかったですね。いろんな意味で後悔しています。

今日はこの辺で

苦節7年(といっても本当は自分の貢献なんか大したこと無いんですがorz)、自分も携わらせて頂いたタイムスタンプに関する日本発のISO/IEC国際標準が、ようやく制定されました。

ISO/IEC 18014-4 Information technology - Security techniques - Time-stamping services - Part 4: Traceability of time sources

マジ、うれしいっす。ちょっと泣きそう。ISO/IEC国際標準を制定するためのプロセスはここに解説があるんですが、本当に長い道のりです。

デジタルタイムスタンプとは

国際標準時って昔はイギリスのグリニッジ天文台の時間を使ってたんだけど、今は幾つかの国の原子時計の時間を比べながら、地球の回転(正しくは公転周期)なんかも考慮しながら協定世界時(UTC)という標準時間を作っています。

パソコンの時間って、NTPとかで自動的に合わせている人も多いけど、無理やり設定することもできますよね。例えば、同じような発明を2人がほぼ同時した時に、パソコンで時間戻して、ワードで発明資料を保存して、「オレの方が先に発明してた〜〜！！ファイルの更新日時見ろ〜〜っ！！」とかね。パソコンの時間って全くあてにならないから、データの存在時刻もあてにならないわけです。

医療、裁判、株取引、銀行業務、特許など、いろんな業務の電子化が進んでいるんですけど、デジタルデータはコピーや変更が簡単という性質があって、そのデータが本物かどうか、本当にその時間にあったかどうかが大切になるんですが、時間を証明するのって難しいんですよね。

これを解決するのがデジタルタイムスタンプという技術です。あるデータがある時刻に存在していて、それ以降変更されていない事を示すために、データを区別するための拇印のような情報であるデータのハッシュ値をタイムスタンプサービスに送ると、そのデータの存在証明、つまりデジタルタイムスタンプを作って送ってくれるというものです。日本でもこのようなデータの存在時刻を証明する時刻認証事業者、日本標準時からの誤差を保証しながら時刻を配信する時刻配信事業者が生まれサービスが開始されました。

各国国際標準時とのトレーサビリティーの必要性

こうした中、デジタルタイムスタンプのフォーマットについては、ISO国際標準があるので問題ないのですが、発行されるタイムスタンプが、各国の国際標準時と比較してどれくらいの精度で発行されているのかを保証する仕組みがありませんでした。タイムスタンプ局は、自分の持つ時計を元に、タイムスタンプを発行することができますが、これが無いと、各国の国際標準時と連携しているのか、どれくらいの誤差範囲で提供されるか保証や監査ができないものは、お互いの国で信用ができないからです。

そのようなわけで、各国の標準時を起源として、時刻の精度のトレーサビリティが保証および監査できないと、その国のタイムスタンプは信頼できないという話になるため、まず日本でJIS規格を制定し、うまくいけば、これをISO国際標準にしましょうという話になりました。

私の個人的な時刻トレーサビリティーの興味と今回の策定の関わり

私はその頃、タイムスタンプ付きの署名フォーマットである長期署名に興味があり、PKI方式タイムスタンプを採用する事業者が、タイムスタンプトークンに含んでいる、時刻監査証もしくは時刻監査記録と呼んでいる、時刻のトレーサビリティーを示すX.509v2属性証明書に着目していました。当時懸念に思っていたのは以下の事柄でした。

• この時刻監査証(TAC: Time Audit Certificate)という属性証明書とその証明内容は利用者が検証する必要があるのか、無いのかが明らかになっていなかった。そもそもデータ・フォーマットや検証に必要な情報は公開されていなかった。
• この時刻監査証はASN.1として誤ったエンコーディングをされていた。
• 時刻監査証に誤りがあった時に、利用者はそのタイムスタンプトークンを無効とすべきか否かが規定されていない。

認定基準を定め監督管理する団体、タイムスタンプ関係の事業者の専門家方、電子署名の専門家、国際標準の専門家の方と議論させて頂き、 2009年、日本データ通信協会で「タイムスタンプ局に対するUTCトレーサビリティ保証のTA技術要件に関する検討 中間報告書」にまとめて頂きました。私は4.3節「TACの課題と結論」を執筆させて頂いております。

当時の私の疑問に対する識者コンセンサスは、

• デジタルタイムスタンプの利用者は時刻監査証を検証する必要はない。
• 時刻監査証のASN.1エンコーディングはASN.1に準ずるようサービスを修正する。
• 時刻監査証に誤りがあった際に、利用者はそのタイムスタンプトークンを無効とする必要はない。

ということで納得しました。

ただ結局、タイムスタンプ事業者のTP/TPSタイムスタンプポリシ/運用規定では、時刻監査証のASN.1シンタックスが公開されず、時刻監査証は検証不要であることが明記する所、しない所があったりといった状況です。(ちょっと残念)

JIS X 5094:2011という時刻トレーサビリティに関するJIS規格の制定

その後、その中間報告書をベースに、日本国内で日本標準時からのタイムスタンプのタイムスタンプの トレーサビリティーを保証するためのJIS規格が2011年に制定されました。(これは、これで結構大変だった。)

JIS X 5094:2011 UTCトレーサビリティ保証のためのタイムアセスメント機関(TAA)の技術要件

中間報告書をベースにこれがJIS規格になり、日本データ通信協会で認定を受けている、時刻配信事業者や時刻認証事業者が当たり前のように行っていたことが、JIS規格として後ろ盾を持つことができるようになりました。

日本標準時とのトレーサビリティーの標準化で面倒だったのが、タイムスタンプサービスの標準がISOにはあるのにJISには無かったことです。このことで、タイムスタンプサービスを参照せずに、JIS化する必要があり、用語など手間がかかりました。

そして、今回のJISからISO/IEC規格へ

そして、世界各国のタイムスタンプが互いに信頼できるようにするために、言い換えると、世界各国の標準時とのトレーサビリティを持つ時刻配信が信頼できるようにするために、標準時からのトレーサビリティを持つ時刻配信のJIS標準をISOに持って行くことになり、ISOのドラフト版を作成しました。

関係者いろいろな伝をあたって頂き、暗号セキュリティ関係のISO/IEC SC27でお世話になることになり、SC27会議で正式に受理されました。

丁度、ISO/IEC 18014シリーズのタイムスタンプサービスのISO/IEC標準を見直す時期に来ていたそうで、これ幸いと、持っていったら追加でPart 4として標準化良いのでは？という事でワーキンググループが立ち上がりました。

その後、表現や細かい文言の修正など関係者の協力のおかげで、数多く対応してきましたが、私に関係するところとしては、当時nCipher製品でサポートされていた、PKI方式で電子署名された時刻監査証について参考情報として掲載したのですが、米国ではXML形式の電子署名されないデータを監査証として使っていました。先行するサービスの監査情報に適用できないのはまずいということで、これも比較できるよう掲載し、各項目の対応関係の補足説明を追加させていただきました。

後は、本当に長い時間のかかる、表現や文言の調整で、単に英語表現の問題だけではなくて、ISO/IECにふさわしい英語表現というのがあるようで、本当にWGの英国の方には細かく見ていただけました。

もうすぐ、承認されるかも、されるかもと、言っては、国際会議で流れ、また手直しをし、2014年10月のSC27メキシコ総会でPublishしてよいとの承認を頂いたそうです。それで、みな1月頃にはでるんじゃないの？と心待ちにしていたんですが、結局は4月になっちゃいました。

今後のISO/IEC規格からJISへ

JIS規格からISO/IEC規格にする際に、何点か国際間の整合を取れるような改正をしています。ISO/IEC規格は、翻訳さえすればそのままJIS規格にすることができるルールになっているそうです。ただ、関係省庁にお伺いをたてたところ、このUターンのJIS化は、今年は実施せずに、来年がJIS X 5094:2011が制定後、ちょうど5年になり見直しの年になるので、来年にやりましょうという話になったそうです。

盛大に祝杯をあげねばっ！！！

参考リンク

• ISO/IEC 18014-4 CD1次投票、CD2次投票、FCD1次投票、FCD2次投票の結果
• 入札「ISO/IEC 18014-4標準化制定作業及びJIS X 5094の見直し作業 」
• ISO/IEC JTC1/SC27/WG2 2011年10月ナイロビ会議報告
• ISO/IEC JTC1/SC27/WG2 2012年5月ストックホルム会議報告
• ISO/IEC JTC1/SC27/WG2 2012年10月ローマ会議報告
• ISO/IEC JTC1/SC27/WG2 2013年4月ニース会議報告
• ISO/IEC JTC1/SC27/WG2 2014年4月香港会議報告
• ISO/iEC 18014シリーズの標準ドラフト、NBコメント等番号一覧

メキシコの会議報告が見つからないなぁ。しかし、会議報告の置き場所がバラバラだったり、一覧になってないのは何でなんですかねぇ。

標準ドラフト、NBコメント等一覧

年月日	番号	文書名
2011.05.31	N 10047	Call for contributions to the proposed new project
2011.06.16	N 9659	Text for ISO/IEC 1st WD
2011.09.05	N 10225	Summary of NB comments on document SC 27 N9659
2011.09.20	N 10388	UK NB comments on document SC 27 N9659
2011.10.03	N 10328	Draft disposition of NB comments on document SC 27 N9659
2011.12.12	N 10425	Text for ISO/IEC 2nd WD
2011.12.12	N 10426	Disposition of NB comments received on SC 27 N9659 - 1st WD
2012.04.13	N 10851	Summary of NB comments on document SC 27 N10425 2nd WD
2012.04.27	N 11060	Draft disposition of NB comments on document SC 27 N10425 - 2nd WD
2012.06.06	N 11173	ISO/IEC 1st CD
2012.06.06	N 11174	Disposition of NB comments received on document SC 27 N10425
2012.09.12	N 11485	Summary of voting on document SC 27 N11173
2012.10.05	N 11613	Draft disposition of comments received on document SC 27 N11173 1st CD
2012.12.14	N 11808	ISO/IEC 2nd CD
2012.12.14	N 11809	Dispositions of NB comments received on document SC 27 N11173 1st CD
2013.03.26	N 12185	Summary of voting on document SC 27 N11808 2nd CD
2013.04.08	N 12341	Draft disposition of comments received on SC 27 N11808 2nd CD
2013.06.10	N 12567	Text for ISO/IEC DIS
2013.06.10	N 12568	Disposition of comments received in SC 27 N12185 on document SC 27 N11808 2nd CD
2013.07.02		ISO/IEC DIS

DIS以降も改変があった記憶があるんですが、それはN番号つかないのかな？

つい先日、MさんのTLで中国のタイムスタンプサービスのURLがあって、面白そうだからいろいろ調べてみました。UniTrust Time Stamp Authority(http://www.tsa.cn/)というのだそうです。

タイムスタンプサービスとは

例えば何か発明した時に、自分の発明の方が先だったとかテキストメモで書いたりしたとしても、パソコンの時間は自由に変更できますし、テキストメモの内容だって自由に変更できちゃいますから証明するの難しいですよね。そんな時、タイムスタンプサービスが発行してくれるデジタルタイムスタンプ使うと「ある時点にそのデータが存在してて、それ以降変更されてないこと」を証明することができます。

デジタル署名も証明書が有効だった「時」に署名された事がわからないと困るので、特にデータを保管する際には「デジタル署名にはデジタルタイムスタンプをつけましょう」というのが定石になっています。

日本ではタイムスタンプサービスをタイムビジネス協議会が普及促進をしていて、米国、欧州、アジアの幾つかの国でもこのようなサービスが始まっています。

で、tsa.cnはどうなの？

中国語は全く読めないんですが、

• 画像やデータをスマホからアップしてタイムスタンプをつけたりするAndroidアプリも充実
• Windows用デスクトップアプリも提供
• タイムスタンプつき文書をオンラインで検証できるページもある
• 値段は1タイムスタンプ10元(160円)?

となかなかサービスは充実しているようです。

タイムスタンプの取得方法ですが、http://timestamp.tsa.cn/tsa がRFC 3161 over HTTPで取得するためのURLになっているようでBasic認証で取得するみたいです。 Basic認証なのにHTTPSじゃなくていいのかな？tsa.cnではHTTPSのページは一切無いように見えます。

マニュアルなどのドキュメントは署名タイムスタンプつきPDF署名(PAdES-Tフォーマット)になっているようで 署名やタイムスタンプや証明書などを取り出して見てみました。

興味深いところはこんなとこです。

• タイムスタンプトークンについて
  • タイムスタンプ局のポリシが公開されていないようだ
  • トークンのTSA Policyは1.3.6.1.4.1.8291.1.1になっており米国Digistamp社の OIDになっている。OEMかもしれないし、単にOIDをパクってきただけなのかもしれない。
  • genTimeはミリ秒まで対応している
  • ordering=True
  • トークンへの署名アルゴリズムはSHA1withRSA
  • トークンのCMS SignedDataにはSigningTime属性が入っている。tSTInfoに時刻が含まれるのでSigningTimeは含めない方がよい
• TSA証明書について
  • ルートは"O=China Time-Stamp Authority, CN=China TSA Root"、2048bit RSA、SHA1withRSA
  • TSA証明書は"O=China Time-Stamp Authority, CN=China TSA"、2048bit RSA、SHA1withRSA
  • TSA署名書にはCRLDP拡張が無い
• PDF署名に使った署名者用証明書について
  • これは面白いところが満載
  • シリアル番号が負の値になっている。(RFC 5280的にNG)
  • 自己署名証明書
  • DNはCN=UniTrust, O=beijing unitrust, OU=, E=unitrust@unitrust.com.cn, C=<无
  • CNがUTF8の中国語になっている。本来なら"CN=cn" (RFC 5280的にNG)
  • OUの値が長さ0 (RFC 5280的にNG)
  • 不明の拡張がある1.2.840.113583.1.1.10。これ自体はAdobe社のOID
  • 普通はこのような証明書は発行できないので、独自のエンコーダーを使った CAアプリがあるのではと想像する。

アカウントを取っていろいろ調べて見ようともしているんですが、 アカウントの取り方がわかりそうになく断念してしまいました。今日はこの辺で。

最近、ちらほらAdobe AIRを使ったプログラムが増えてきてますね。プログラムを配布する時はコードサイニングしないといけないという話はわかっていたんですが、まぁ、Adobe AIRの実行プログラム *.air は言っちゃえばjarファイルなもんでjarコマンドやZIP対応のアーカイバで解凍でき、Javaのjarに対する署名だとタカをくくっていたわけです。

久々にAdobe AIRの面白そうなプログラム「てれびなう」なんてものを見つけてしまったのでインストールしようとしたら、こんな画面が、、、

「発行者」とか「発行者ID：検証済み」とか出てますが、ボタンを押せば証明書やコード署名の内容が表示されるわけでもなく、どこから出た証明書でコード署名したもんか知る術がないので「こりゃ〜Adobe AIRは酷い作りだなぁ。何を信じていいのかわからないぢゃん」と思ったわけです。

折角なのでコード署名の中身を見てみるべ〜かなと"mv foo.air foo.zip"して解凍してみました。するとjarファイルよろしくMETA-INFがありまして

おお〜〜〜〜〜っ！！！ signatures.xml

XMLDSigなのか〜〜〜〜っ！！と鼻血が出そうになりながら中を覗いてみると

<Object xmlns:xades="http://uri.etsi.org/01903/v1.1.1#">

ずご〜〜〜〜っ！！！ETSI TS 101 903 XAdES 1.1.1ではないですか〜〜〜っ！！！ それも

<xades:SignatureTimeStamp>
 <xades:HashDataInfo uri="#PackageSignatureValue">
  <Transforms>
  <Transform
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
  </Transforms>
   <xades:EncapsulatedTimeStamp>

XML形式の長期署名フォーマットで署名タイムスタンプ付きXAdES-Tじゃないですか〜〜っ！！！うんうん、Microsoft Office 2010といい、これといい、ちゃんとこんなところでひっそり使われていたんだなぁ、、、(どんどん、仕様は改悪されていくような気はするけどね、、、)。こんなちゃんとした署名がついてるなら、署名者情報や認証された署名時刻を表示した方がいいんじゃないかなぁ、、、と強く思います。

XAdES-Tを検証してみたり、署名者証明書や署名タイムスタンプを取り出してエンジョイしました。見たコード署名はGeoTrust Timestamping Signer1のタイムスタンプがついてるんですが、このTSAポリシOIDが"1.1.2"って、TSAポリシが無いって事も同然の怪しさな気がします。

今晩はこんなとこで、、、

日本国内の認定タイムスタンプ局の発行するタイムスタンプトークンには、上位の時刻配信局からの時刻差がどの程度であったかを証明するための時刻監査証(TAC)がX.509属性証明書v2の形式で付与されています。

このTACが取り外されたり、違うものに置き換えられたりするのを防ぐ目的でタイムスタンプトークンのESSSigningCertificateV1/V2の署名属性を用いてTACの参照情報を含めるようにしています。日本の多くのタイムスタンプトークンのESSSigningCerticateの内容はTSA証明書とTACを保護するようにできており、内容は以下のようになっています。

・TSA証明書の参照情報 (証明書の発行者名、シリアル番号、拇印ハッシュ値による参照)
・TACの参照情報 (拇印ハッシュ値のみによる参照)

以前からTACの参照情報が拇印となるハッシュ値だけでいいものか疑問に思っていました。何を参照しているのかを示すには不十分なんじゃないかと、、、そこで、規定をちょっと見なおしてみました。

ESSSigningCertificate属性の定義はRFC 2634 Enhanced Security Services for S/MIMEで規定されていますが、暗号アルゴリズムの危殆化に対応するために、その更新差分RFC 5035 Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agilityが出ています。

ESSSigningCertificate(V1)の構造は以下のようになっており

SigningCertificate ::= SEQUENCE {
　certs SEQUENCE OF ESSCertID,
　policies SEQUENCE OF PolicyInformation OPTIONAL
}
ESSCertID ::= SEQUENCE {
　certHash Hash,
　issuerSerial IssuerSerial OPTIONAL
}
IssuerSerial ::= SEQUENCE {
　issuer GeneralNames,
　serialNumber CertificateSerialNumber
}

ESSSigningCertificate(V1)のIssuerSerialの議論はRFC 5035 5.4.1.1節を見ろとのことになっているんですが、 issuerSerialとissuerについて以下のような記述があります。

RFC 5035 5.4.1.1:
issuerSerial
　holds the identification of the certificate. The issuerSerial
　would normally be present unless the value can be inferred from
　other information (e.g., the sid field of the SignerInfo object).

The fields of IssuerSerial are defined as follows:

issuer
　contains the issuer name of the certificate. For non-attribute
　certificates, the issuer MUST contain only the issuer name from
　the certificate encoded in the directoryName choice of
　GeneralNames. For attribute certificates, the issuer MUST contain
　the issuer name field from the attribute certificate.

つまり、issuerSerialフィールドはオプションなんだけども、ほかに特定できる情報がないなら通常入るもので、属性証明書ならば属性証明書のissuer名のフィールドをissuerに入れなければならない(MUST)と書いてあります。

従って属性証明書である時刻監査証(TAC)をcertHashのハッシュ値だけで参照するのは、この規定に則っていないんじゃないかと思うわけです。(悪いかどうかは別にして、、、)

ここで厄介なのが、時刻監査証(TAC)はタイムスタンプトークンの検証者は一切検証する必要がなくて、時刻配信局(TA)のサービス運用者やタイムスタンプ局(TSA)の監査者だけが検証すればよいものなので、中身を深く観たくないのと、TAC用にissuerSerialを入れてしまうと見た目上 X.509公開鍵証明書への参照と区別がつかないので両方を(属性証明書を扱えないのに)チェックしようとして戸惑う実装が出てくるんじゃないかと危惧される所です。

一昨日も飲みながら話してしまいましたが、時刻配信と時刻精度のトレーサビリティーを保証するために時刻監査証の仕組みはよくできているものですが、タイムスタンプトークンにこれを含めることの意義が未だに理解できず、単にTSA事業者さんがTACに基づく監査結果を定期的にホームページなどで公開すればよくトークンには入れなくてもいいのかな、、、と思うわけです。TACをトークンに含めなければ今回のTACのissuerSerialの問題とか、そのほかにも幾つかある悩ましい問題が解決するんじゃないかと思っています。

てなわけで、規定には沿わないんだけど、現状のままでも仕方ないかとモヤモヤした気持ちのまま寝ることにします。

セイコーさんのSHA2タイムスタンプテストサイトを使うのに自前のJava(Jython)プログラムを使っているんですが、まぁ、他にも方法があってもいいでしょうってことで、Perl、wget、OpenSSL 1.0.0、tailを使ってタイムスタンプトークンを取得するスクリプトを作ってみました。cygwinやUnix上なら動くんじゃないかと思います。

• http://www9.atwiki.jp/kurushima/pub/misc/wgetts.txt

例えばこんな感じで使えます。

% wgetts -i data.txt -o data.tst -u http://tsp.com/ -p 1.2.3.4 -d SHA256

短くて大したプログラムじゃないですが、よかったら使ってみてください。OpenSSL 1.0.0 に標準で入っているtsget は、PerlのCurlパッケージを入れなきゃいけないので結構厄介だし、時刻監査証(TAC)を含んだトークンをOpenSSL 1.0.0でタイムスタンプ応答をそのまま解析するとエラーでコケちゃうので、そのあたり面倒くさくないようにちょっと工夫しております。

はじめに

米国政府で使用する暗号を2010年までに強固なアルゴリズムに移行することを決定し、政府以外の様々な分野でも同様に暗号の移行の実施が迫られており、これを「暗号の2010年問題」呼んでいます。

タイムスタンプについては、現時点で作成したデータが今後10年といった長いスパンで利用できることが求められるため、他の暗号の応用よりもかなり強固なアルゴリズムに早急に移行する必要があります。国内のタイムスタンプ局事業者では、すでにトークン内の一部分においてSHA2への移行が完了していますが、タイムスタンプトークンは様々な部分で暗号アルゴリズムが使われているので、移行できていない箇所が幾つか存在しています。

タイムビジネス協議会でも、暗号アルゴリズム移行のワーキンググループを立ち上げ、移行計画と移行内容の策定を進めています。

そのような状況の中、セイコーインスツルさんやセイコープレシジョンさんが共同で、開発者なら誰でも無償でRFC 3161デジタルタイムスタンプのSHA2アルゴリズムへの移行を試すことができる体験サイトを公開して頂けるようになりました。 いつもお世話になっているUさんから案内頂き、ようやく時間も取れたのでいろいろ試してみたので、レポートしたいと思います。

体験サイトで試せるSHA2のパターン

RFC 3161タイムスタンプトークンは、ざっくりと以下の場所で暗号アルゴリズムの移行を進めていかなければいけません。

• タイムスタンプトークンの主構造となる暗号メッセージ構文の署名データ(CMS SignedData)でのSHA2、SHA2withRSAの使用。
• タイムスタンプトークン情報(TSTInfo)でのSHA2の利用。
• タイムスタンプトークン内で使われるTSA証明書(=X.509公開鍵証明書)や時刻監査証(=X.509 属性証明書v2)のSHA2withRSAの使用。

どの場所で移行が必要になるか、体験サイトのトークンで違いがあるかを下図に示します。

体験サイトでのタイムスタンプの取得

体験サイトでは使い方を解説したPDFに記載されているタイムスタンプサービスのURLに対して、認証なしでタイムスタンプ要求を送ることにより取得できます。Adobe AcrobatやMicrosoft Office 2010やその他のCAdESやXAdESなどのタイムスタンプを利用するアプリケーションから利用することも可能です。私は自前開発のJavaベースのクライアントで試してみました。

タイムスタンプ要求でreqPolicyという値をいろいろ切り替えることによりタイムスタンプトークンのどの部分をSHA2対応にしたのか切り替えられるようになっています。reqPolicyと、取得できるタイムスタンプトークンのパターンを示したのが下表になります。

タイムスタンプトークンフォーマットにおける2つの課題

タイムスタンプトークンのフォーマットはRFC 3161で規定されていますが、2つの課題があります。

1. 国内の多くのタイムスタンプ局が発行するタイムスタンプトークンには時刻監査証と呼ばれる上流の時計との時間差を示す証明書がX.509属性証明書v2の形式で発行され、これがトークンに含まれます。現行のトークンではv1AttrCertというV1の属性証明書を格納する領域にV2の属性証明書を入れてしまっています。ASN.1を厳密にパースするアプリだとエラーになってしまうケースもあるようです。これを正しくv2AttrCertに格納し、その結果CMS SignedDataのバージョンをv4にしたものが体験サイトで試せるようになっています。
2. タイムスタンプトークンでTSA証明書の置換攻撃を防ぐためにESSSigningCertificate(V1)という属性を使いますが、これはSHA1しか使えない仕様になっています。これをSHA2でも使えるようにESSSigningCertificateV2を規定しタイムスタンプでも使えるように新しいRFC(RFC 5816)が公開されました。体験サイトではこれも試せるようになっています。体験サイトで公開されているESSSigningCertificateV2は、ちょっとおかしいような気がするので確認してみます。

おわりに

自前開発のCAdESやXAdESのフル実装では既にSHA2の対応は終わっていて、そのようなテストをするためにパラメーターをいろいろいじれるテスト用タイムスタンプ局を実装したんですが、そのような実装がなくても自分の実装がSHA2タイムスタンプに対応しているのか簡単に確認できるので、このような体験サイトの存在はとてもありがたいんじゃないかと思います。

ちなみに、セイコーさんのタイムスタンプはマイクロ秒単位でトークンが出てくるので、これについてはちょっとハマる実装もあるかもしれませんね。一般的なコンピュータではミリ秒単位までしか時刻を扱えないのと、ASN.1の時刻表現を秒単位までしか扱えないような実装も多いため注意が必要です。

最近、セキュリティ関係のニュースを見逃すことが多くて申し訳ないんですが、2010年6月10日にIETF SMIME Working Groupのメーリングリストでインターネットドラフト「Additional CMS Revocation Information Choices」がIESGに承認されProposed Standardになったとアナウンスがありました。

CMS署名データのcrlsフィールドには、元々X.509かデータ型を表すOIDの規定された失効情報が格納できるようになっていたんですが、そのOIDが他で全く規定されていないためにOCSPレスポンスやSCVPのデータが格納できないようになっていました。

特にOCSPレスポンスを標準で格納できるようになったことは、タイムスタンプ付きのCAdES/XAdESを長期保存することを考えている方々には朗報なんじゃないかと思います。

CMS署名における失効情報の格納

CMS署名データには失効情報を格納するためにcrlsフィールドというものがあり、ここに格納できるASN.1シンタックスの定義は以下のようになっています。

RevocationInfoChoices ::= SET OF RevocationInfoChoice
RevocationInfoChoice ::= CHOICE {
　　　crl CertificateList,
　　　other [1] IMPLICIT OtherRevocationInfoFormat }
OtherRevocationInfoFormat ::= SEQUENCE {
　　　otherRevInfoFormat OBJECT IDENTIFIER,
　　　otherRevInfo ANY DEFINED BY otherRevInfoFormat }


格納できるデータはcrlかotherがあってX.509 CRLか他のデータが格納できます。 OCSPレスポンスなどは他のデータということになりますが、 otherの中にどんな種類のデータを格納するかはotherRevInfoFormatというオブジェクト 識別子(OID)で区別することになっていて、このOIDを定めた標準がこれまで何年も 無かったためにOCSPレスポンスなどを格納できずにいました。

OCSPレスポンスの格納

今回、このProposed Standardができたことにより、OCSPレスポンスを格納する場合には otherRevInfoFormatにid-ri-ocsp-response "1.3.6.1.5.5.7.16.2" を指定すればotherRevInfoにOCSPレスポンスを入れられるようになったのです。

CAdES、XAdESおよびタイムスタンプの長期保存に与える影響

今回のProposed Standard化の意義を深く考えている人はそう多くないんじゃないかと 思うんですが、自分としては心待ちにしていた標準化だったりします。 それは、

• アーカイビングの際、タイムスタンプ検証用の失効情報にOCSPが使いやすくなる。
• XAdES用のタイムスタンプ検証情報の格納にcrlsフィールドが使えるようになる。

タイムスタンプ検証情報にOCSPが使える事の意義

長期署名において署名やタイムスタンプを検証するためにCRLを使った場合、 そのCRLが検証するのに十分な猶予期間を持って取得されていることを考慮する必要があります。 簡単に言っちゃうと、署名をしたまさにその時刻にCRLを取得して含めたのではダメで、 署名時刻に失効申請たとしてそれが次のCRLに反映されるまでの十分な時間待ってから 取得したCRLを使わなければいけません。 毎日発行されるCRLならば割と話は簡単で数営業日待てばいいんですが、 CRLの発行周期が1ヶ月とか失効申請の都度CRLを発行するようなケースだと 適切なCRLかどうかを判断するのはすごく難しいです。 特に、サブCAやタイムスタンプ局証明書用のの失効情報については局によって例えば1ヶ月や 1年といった周期のところが多いので、次のアーカイビングを行うための待ち時間は 尋常ではなく、一般的な実装ではあきらめてしまっているケースが多いのではないでしょうか。 CRLでは、いつ取得したCRLであるかを第三者に示す仕掛けが無いために苦労するわけです。 OCSPレスポンスを使えば、所詮CRLを元にOCSPレスポンスを発行するので情報の新鮮さ は同じだったとしても、失効情報を取得した時間は明らかにできるので 猶予期間をまともに扱う事ができるようになるわけです。

XAdES中のタイムスタンプの失効情報にOCSPレスポンスが使える

タイムスタンプ局証明書がOCSPでしか失効情報を提供していない、または敢えて OCSPを使わなければならないってことが相互運用テストの場合にはあったりします。 XAdESの数世代のアーカイブタイムスタンプを行う場合には少し厄介で、 アーカイブタイムスタンプの検証情報はXAdES 1.4.1だったとしても タイムスタンプトークンの中に含めるしかなく、今回のProposed Standardが 出てくる前はcrlsフィールドには格納できなかったので、 CAdESと同等の非署名属性を用いてタイムスタンプトークンに格納する しかありませんでした。 XAdESを実装したいのにタイムスタンプのためのCMS実装だけでは 不十分でCAdESの属性まで扱える必要があったのです。 今回のProposed Standardを使えば、XAdESのアーカイブタイムスタンプの OCSPレスポンスによる失効情報をCMSの標準の範囲内で含めることができるわけです。

夏休みの宿題で自前のライブラリでOCSPレスポンスの格納に対応させようかなぁ。 早くこれがDraft Standard、Standardと進んで行くといいなぁ、と思っています。

前にAdobe CDSのPDF署名について書きましたが、証明書や署名データなどをdumpasn1というASN.1ダンプツールで表示させると不明の(説明されない)OID(オブジェクト識別子)のように表示されてしまいます。

オフィシャルなものでもありませんが、とりあえず dumpasn1.cfg ファイルに以下を追加してみました。

# Adobe

OID = 06 09 2A 86 48 86 F7 2F 01 01 08
Comment = Adobe AdobeRevocationInfoArchival CMS attribute for PDF
Description = adobeRevocationInfoArchival (1 2 840 113 583 1 1 8)

OID = 06 0A 2A 86 48 86 F7 2F 01 01 09 01
Comment = Adobe CDS timestamp information extension (unofficial name)
Description = adobeCDSTimeStampInfo (1 2 840 113583 1 1 9 1)

OID = 06 0A 2A 86 48 86 F7 2F 01 01 09 02
Comment = Adobe CDS certificate verification information extension (unofficial name)
Description = adobeCDSCertVerifyInfo (1 2 840 113583 1 1 9 2)

OID = 06 09 2A 86 48 86 F7 2F 01 02 01
Comment = Adobe CDS certificate policy
Description = adobeCDSCertificatePolicy (1 2 840 113583 1 2 1)

これを入れておけば、Adobe CDS証明書やPDF署名のPKCS#7署名データを見たときに役に立つかもしれません。

adobeCDSTimeStampInfo、adobeCDSCertVerifyInfoについては正しい名称がわからないし、公開されないままなので、とりあえずで付けています。また何か情報得られたら、こちらで紹介したいと思います。

最近、セキュリティに関係したトピックをサボっていてすみません。書きたいと思っているネタは幾つかあるんですが、ナカナカ時間が取れなくて、、、セキュリティ関係のやつはTwitterで紹介して済ませることも多かったので、興味ある方は、よかったら私のTwitterやFriendFeedなんかのつぶやきも見てやってください。

今回は、久しぶりにAdobe CDS(Certified Document Services)について署名、タイムスタンプ、PKI的にニッチな話を書いてみたいと思います。

ここに書いていることは、自分が所属する組織の立場によるものではなく、ウェブなどで公開されている情報から個人的に調べて思ったことを書いただけです。問題があればコメント欄にお願いします。なるべく誠意を持って対処するつもりではいます（＾＾；

Adobe CDSとは何か

PDFにはデジタル署名をつけたり、これを検証したりする機能を持っているが、これを進化（？）させたのがAdobe CDS(Certified Document Services)である。




PDF文書をAcrobat Readerで開いたとき、署名が無い場合には単に文書だけが表示されるが、署名がある場合には署名情報バーが文書の上に表示される。署名検証はプラグイン不要で自動的に行われ、署名結果が正しければバーは水色となり、合わせて以下の情報が表示される：
・署名検証結果
・署名者は誰か
・どの認証局が発行する証明書によるものか

CDSを使うメリットをまとめてみると、こんなとこ、、、

• PDF文書ではデジタル署名やデジタルタイムスタンプを付与できるが、CDSの場合は署名やタイムスタンプを検証するために何ら追加のプラグインを必要としない。(従来の署名やタイムスタンプではAcrobat Readerに検証プラグインのインストールが必要なケースがあった。)


• プラットフォームに依存せず、WindowsでもLinuxでも同じように検証結果が表示される。(Windowsの証明書ストアなどに依存しない。追加プラグインが無いのでAcrobat Readerさえあれば、プラットフォームも気にする必要がない。)


• ルート証明書のインストールをする必要がない。変な認証局が入ってくる心配は(今のところ多分あまり)ない。


• Adobe CDSに準じたPDF文書を検証するのにAcrobat Readerの検証設定を何ら変更する必要がなく、デフォルトで正しい検証結果が得られる。

ちなみに、Ubuntu上のAcrobat Readerを使って同じように表示すると、何もアドオンを入れたりルートを追加をしなくても、このように表示される。

Adobe CDSのPKIってどんなの？

Adobe CDSのルートCAは、Windowsのルート証明書ストアや、他のルートストアとは一切関係なく、専用のAdobe Trust Services Root CAのみを信頼点としている。このルートCAは他のデフォルトの信頼リストに含まれていることはない。そのルートの下位には、幾つかの商用証明書発行サービスのサブCAがあって、
・個人
・組織に属する個人
・組織
に対してAdobe CDS署名用の証明書を発行している。

現在対応している証明書発行サービスは5つあり、対応しているサービスはこのAdobe社のページで公開されている。




Adobe CDSの署名者用証明書には、署名用証明書を見たり、証明書発行サービスの説明を見てみると以下のような特徴があるようだ。

・秘密鍵はUSBトークンかHSMに格納される事が要件になっているよう
・拡張鍵使用法にはAcrobat認証文書(1.2.840.113583.1.1.5)を指定
・失効検証にOCSP利用可能
・証明書ポリシはAdobe CDS用ポリシ(1.2.840.113583.1.2.1)を指定
・デジタルタイムスタンプが利用可能でタイムスタンプサービスのURLが記載される

CDSに共通の証明書ポリシ(CP)は以下で公開されている。
・Adobe Systems Incorporated CDS Certificate Policy October 2005 Revision #14 (PDF)

下位CAやエンドエンティティ証明書は、発行会社の異なる証明書であっても、全て同じ証明書ポリシ拡張のOID、Adobe CDS証明書ポリシが設定されている。



CDS用証明書が一般の証明書とは違う大きな特徴として、どの認証サービスから発行される署名者用のエンドエンティティ証明書にも、これまで見たことがないプライベート拡張が含まれている。

・1.2.840.113583.1.1.9.1
・1.2.840.113583.1.1.9.2

Adobeで公開されている証明書ポリシ(CP)にも説明が無く、これらのASN.1シンタックスについても公開されている文書が無いようだが、それぞれ、どうやら

・1.2.840.113583.1.1.9.1 (TSA局に関する情報)
・1.2.840.113583.1.1.9.2 (アーカイブバージョン情報もしくはOCSP検証に関する属性)

の情報を持たせているようだ。タイムスタンプに関する証明書拡張は次のようなASN.1構造になっている。

SEQUENCE {
　OBJECT IDENTIFIER '1 2 840 113583 1 1 9 1'
　OCTET STRING, encapsulates {
　　　SEQUENCE {
　　　　INTEGER タイムスタンプサービスの属性
　　　　[6]
　　　　　'認証サービスの持つタイムスタンプサービスのURL'
　　　　}
　　　}
　}

タイムスタンプ属性に関しては、フラグを意味するものらしく、値が1のとき、Acrobat Readerで見ると「認証=必須」という意味を持っているらしい。

もう一つのプライベート拡張についてはウェブなどで検索してみるとOCSP検証を行うかどうかのフラグのようなものらしいが正確な情報は何ら得られていない。Acrobat Readerで参照すると「アーカイブバージョン情報」に相当するように思われるが、この値が何を意味するかについては何も情報がない。

SEQUENCE {
　OBJECT IDENTIFIER '1 2 840 113583 1 1 9 2'
　OCTET STRING, encapsulates {
　　　SEQUENCE {
　　　　INTEGER 1
　　　　}
　　　}
　}

CRLの発行周期はどうか

全てのエンドエンティティ証明書、サブCA証明書はOCSPで検証できるようになっているが、PDF長期署名(PAdES)などのことを考えるとCRLの発行周期は気になるところである。調べたところ以下であった。

・RootCA - 1年
・SubCA(A社) - 7日
・SubCA(B社) - 7日
・SubCA(C社) - 7日
・SubCA(D社) - 7日
・SubCA(E社) - 1日

多くのサブCAが7日周期を採用していた。システム設計上、長期署名検証の猶予期間(Grace Period)に配慮する必要がある場合にはCRL発行周期に留意しなければならない。

ちなみにAdobe CDSのCPを見るとCRLについて
・X.509 V2 CRLでなければならない
・AuthorityKeyIdentifierとCRLNumberの拡張を持たなければならない
とあるが、これに準拠しないサブCAもあるようだ。

Adobe CDSのタイムスタンプ

Adobe CDS用の証明書発行サービスでは、OCSPサーバーの他にRFC 3161に基づくタイムスタンプサービスを運営することを求めらているようだ。

タイムスタンプサーバー用のタイムスタンプ局(TSA)証明書は各認証サービスのサブCAから発行されている。



各認証サービスが発行する署名者証明書のプロファイルは認証サービスの公開するCPS(認証実施規定)で規定されているようだが、同じサブCAが発行するTSA証明書やOCSPレスポンダ証明書については、どの認証サービスも記述していないようだ。

タイムスタンププロトコルについては、4社がRFC 3161方式を採用しているが、1社だけOASIS DSS(Digital Signature Service)を採用しているように見える。(その1社の発行するトークンもRFC 3161型のトークンである。)

公開されているPDF署名文書からタイムスタンプトークンのプロファイルを比較してみた。まとめると以下のような特徴があった。

タイムスタンプ局ポリシーOID

(実際はどのようなタイムスタンプポリシーで運用しているかは疑わしいものもあるが)きちんとタイムスタンプサービスの自前のポリシーOIDを付与しているものもあれば、Adobe CDSの証明書ポリシOIDを記載している所や、とてもそのサービスが維持権限を持っているとは思われないポリシーOIDを(恐らく勝手に)使用している所もあった。ちなみに、Adobe CDSの証明書ポリシにはタイムスタンプトークンやTSTInfoのプロファイルの記述は無い。従ってCDS証明書ポリシーOIDをTSAポリシーOIDとして記載することは適切でないように思う。

messageImprint(PDFのタイムスタンプ対象部分のハッシュ値)

全てSHA1アルゴリズムを使用している。

genTime

マイクロ秒単位から秒単位までと幅がある。

accuracy(時刻精度)

フィールドが無いもの、500ミリ秒、1秒のものがある。中には60秒というものもある。

ordering(順序保証)

有るもの、無いもの様々である。60秒でordering=trueであったり、マイクロ秒単位のgenTimeで1秒のaccuracyでordering=falseであるケースなど結構扱いに困るケースがあると思う。

nonce

全てのサービスで本フィールドがある。

tsa(TSAの名称(GeneralName))

サービスにより有ったりなかったり。

時刻監査証(TAC)

1つのサービスだけ、時刻監査証(TAC)を含んだトークンを発行するサービスがあった。TACとは、時刻配信局(TA)から見たTSAの装置との時差予測を時刻監査証は上位との時刻のずれの予測をX.509属性証明書の形式でTAより発行するものである。TACに関する課題は、ここ何年か幾つかの場所でコメントさせて頂く機会があったが、これを盛り込んで日本データ通信協会(デ協)でまとめたものが近日公開される予定だそうなので、また別の機会に紹介させて頂こうと思う。この課題およびコンセンサス抜きにはTACを使用することはあまり適切でないように思う。デ協で議論されたのと同じ問題が含まれるTACには見受けられた。(今回の調査で、また別の属性値の問題も見つけてしまった(T_T))

署名者の認証については、どの認証サービスもセキュアな署名デバイスを必須とするなど厳密になっているが、タイムスタンプについてはあまりのサービスのバラつきに愕然としてしまった。

どのCDS用認証サービスのページからも正しくタイムスタンプポリシーの記述を辿れるようなサービスは見当たらなかった(1社は日本のタイムスタンプ局なので知っている人は辿ることができるかもしれない)。Adobe CDSで使われている多くのタイムスタンプサービスはどのような時刻源、もしくは時刻配信局(TA)に基づいてタイムスタンプを発行しているか知ることはできないし、どのような運用をしているのか、例えば運用するTSAと協定世界時(UTC)との時刻差からどれだけ離れたら正しくタイムスタンプサービスを停止するかなど一切知ることはできない。(検索すれば間接的に情報を入手できるところもある。)

タイムスタンプポリシーについては以下の規格がある。
・ETSI TS 102 023, V1.2.1 (2003-01), Policy Requirements for time-stamping authorities
・RFC 3628 Policy Requirements for Time-Stamping Authorities (TSAs) (Informational)
これらに基づいたタイムスタンプポリシーもしくはRFC 3628の付録にあるModel TSA Disclosure Statement Structureに準じて書かれたタイムスタンプ局開示規定が無ければ利用者はこのタイムスタンプトークンを信じてよいのかどうか判断が付かない。

IETF PKIX WGやETSI TC ESIでは、RFC 3161の改訂の議論が一時期盛り上がりそうになったが、結局本体は改訂されないことが決定した。現行のタイムスタンプトークンのフォーマットで大変残念に思うのは、タイムスタンプポリシーを記述したドキュメントやホームページへのURLを記載する正式な場所が無いことである。タイムスタンプポリシーのOIDからタイムスタンプポリシーのドキュメントが(運が良ければ)見つかることがあるかもしれないが、今回のAdobe CDSのように怪しいポリシーOIDが記載されている場合には、ほぼ不可能である。

ISOのタイムスタンプの標準によりタイムスタンプトークンの拡張領域も使うことはできそうにないので、例えば、タイムスタンプ局の名前を表すtSTInfoのtsaフィールドのGeneralNameの値にタイムスタンプポリシを示すURLの記載を必須とするような要件を追加するべきだと思っている。

詰まる所、Adobe CDSのタイムスタンプサービスの多くは、どれもにわかには信じがたいというのが率直な印象である。

もう一点だけ、TSA証明書のほとんどは鍵使用法拡張の値はDigiatal SignatureとNon-Repudiationのビットの両方が立っているが、1社だけNon-Repudiationのビットのみしか立っていないものがあった。以前にもこのブログで述べたようにJava JCEで実装された検証器の場合、障害となるかもしれない[参照1][参照2]。

署名回数の制限の謎

5つある証明書発行サービスを比較してみると、年に500回まで等、署名の回数に制限を設けているサービスが多い。これは、どうのような仕組みで実現されているのかとても興味が有るところだ。例えば

・利用者との紳士協定である。とか、
・配布するUSBトークンで署名回数の制限を設けている。とか、
・タイムスタンプトークンの発行回数で制限を設けている。とか、

回数制限がある場合に極端に安いとかいうこともあまり無いようなので、個人的には回数制限の無いタイプの方が使い勝手が良いような気もしているが、どうだろうか。

以上、今回は長々とAdobe AcrobatのAdobe CDSというフレームワークについて調べた事、思った事を述べさせて頂いた。

今回もニッチな話ですみませんｍ（＿　＿）ｍ