自堕落な技術者の日記

つい先日、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 Acrobatで使うと便利な証明書とタイムスタンプサービスのセットである Adobe CDSに関する前回の記事を書いてから半年すこし立ちましたが、それまで5つあった証明書発行サービスがもう一つ増えて6つになっていました。 今日はちょっと補足情報を書いてみようと思います。

Adobe CDSサービスの価格比較

Adobe CDS対応の証明書発行サービスには、個人向けと企業(組織)向けがありまして、 発行サービスによって署名可能回数が無制限のものや回数制限を設けているものがあります。 以前、自腹で証明書買おうと思って、最初にあった国内1社を含む6社で価格を比較したメモを作っていました。 これに、新たに加わった1社を入れて表にまとめてみました。

結構価格差ありますよね。購入の際の参考にしてみてください。 個人的には署名回数に制限無いものの方が、心置きなくテストで使えるのでいいかなとも思うんですが、 たまにしか使わない個人の人ならTC TrustCenterの500署名2万円弱/年っていうのでも十分なのかもしれません。

署名回数制限の方法について想像してみる

証明書発行サービスによっては署名回数に上限を設けて価格設定している所があります。この署名回数の制限をどのように行うのか、上限を超えると本当にできなくなるのか、単なる紳士協定なのか、システムエラーなどで失敗した場合に回数のカウントはどうなるのかずっと疑問に思っていました。以下のようなこともあって署名回数のカウント方法がよくわからなかったのです。

• USBトークン自体には秘密鍵を使用する回数に制限を設けられているといった話を聞いたことがない。
• Adobe CDSで使用するタイムスタンプサービスはどこも認証無であるし、Adobe Acrobatで タイムスタンプサービスの認証設定の画面などは無い。

署名回数制限があるサービスの中で、タイムスタンプ署名の回数として制限をしているところがありました。Adobe CDS署名に使われた証明書にはスタンプサービスのURLが拡張領域に書かれていますがそれを見てみると

http://TSPのホスト/TSPアプリ/乱数のような長い値

となっていました。おそらくこのURL中の乱数のような長い値を以てユーザの認証をしているのかな、と思いました。

タイムスタンプURLによる認証の問題

タイムスタンプ要求の差異のURLへのアクセスにより認証していて、その回数がAdobe CDSの署名回数と同等だったとすると少し困った問題が起きると思います。

• タイムスタンプ付き署名されたPDF文書はコピーされて不特定多数に渡ったりするので、渡した先は必ずしも悪い事をしない人とは限りません。
• Adobe CDSのPDF署名文書から、この署名に利用したタイムスタンプサービスのURLは誰でも知る事ができます。署名者の証明書に記載されています。
• 記載されているタイムスタンプサービスは特にIDパスワードなどの認証も無いので、URLさえ知っていればアクセスすることができます。接続元IPなどを制限している風でもありません。
• すると、Adobe CDS署名されたPDF文書を受け取った誰か意地悪な人が何人かいたとして、署名に回数制限があるサービスだったとすると、そのURL誰かが何回もアクセスして、Adobe CDSの証明書を持っている人(サブスクライバ)の残り署名可能回数を0にしてしまう事ができるかもしれません。

どんな運用になってるのかは、開示されている情報も無いのでよくわかりませんが、実際のところどうなんでしょうね。自分のやつは回数制限の無いタイプにしたので、とりあえずこんな不安は無くて良かったなぁと思います。

ではでは、今朝はこんなところで。

関連記事

• 2009.11.15 AcrobatのAdobe CDSについて書いてみる
• 2009.11.22 dumpasn1用のAdobe CDS関連の設定の追加

みなさんも見たかもしれませんが、今日Tech Crunchでちょっとびっくりするニュースが出ていました。

電子署名界に革命勃発：Adobeが電子署名サービスのeSignatureを無料でベータ公開
Adobeが金曜日にeSignaturesをパブリックベータとして公開した。 eSignaturesというのは、オンラインドキュメントに簡単に電子署名を追加するクラウドサービスだ。ドキュメントをアップロードして、受信者のメールアドレスを記入し、日付と説明を記した後、当該ファイルに電子署名を付加する。電子署名を記載した文書は、署名後に改変されていないことが保証される。もし改変が行われた場合には証明書が表示されなくなる。手順は非常に簡単で（操作を初めてから完了するまで2分とかからなかった）、しかも無料で提供される。(Tech Crunch Japanの記事より引用)

無料でPDF署名してくれるクラウドサービスなんて、ちょっとワクワクしますよね。

最初はAdobeは電子署名について標準からややズレた事をやっている感じがしてたんですが、PDF署名のISO化や、ETSI ESIでのPAdES PDF長期署名や、Adobe CDSといった認証のスキームなどとても力を入れてまともな方向に注力しておられるようです。その、Adobeが署名をサービスでやってしまうとは、署名の普及に大きく寄与すると思いますし、どんな仕組みなのかとても興味あるところだったので実際に試してみました。

今日の午前中は時間にログインが全くできない状態だったりしたようですが、今日の午後あたりから落ち着いて使えていたみたいですね。

結局、どんなことをしてくれるのか

ユーザ個人に証明書や鍵なんか配ってくれて、ローミングで署名しちゃうのかとか、鍵預託なのかとか、期待しちゃうところですが、実際試してみたところこのようなサービスのようです。

1. 署名付きPDFを交換したいような人は全てAdobe eSIGNATURESのサービスに入っておく。メールだけで誰でもアカウントをもらえ、既存のAdobe IDも使える。
2. 基本は、あるPDF文書について、送り主と一人以上の受取人が全て承認したら署名付きPDFが生成されるというワークフローサービスである。
3. 送り主はPDFをアップロードし、PDFの内容について承認を得るように複数のAdobe eSIGNATURESのユーザに対してメールアドレスを指定することによりPDFを送信する。
4. PDFはサーバーに置かれるが、PDFファイルが各人のボックスに届いた旨、案内メールが届く。
5. 受取人はAdobe eSIGNATURESにアクセスし、自分のボックスを見る。
6. 自分のボックスに入っているPDF文書について、閲覧し(Flash使用、日本語可)、承認するか、しないかを(承認できない場合、内容に承認できない、自分宛に承認を求めるのは不適切、その他の理由など指定可能)入力する。
7. 送り主と受取人の全てが承認した場合は、オリジナルの文書の最後に送り主と全ての受取人の手書き署名ロゴ(画像指定可能)、メールアドレスが書かれた電子署名では無い署名シールと、文末にAdobeの免責事項が書かれたページが追加され、その上で、Adobe eSignaturesサービスのサーバーによるAdobe CDS PDF署名が付与される。
8. そしてPDFが全員により承認された旨メールが届き、各人のボックスには上述のPDF署名ファイルがダウンロードできるようになる。
9. 受取人の誰かが承認しなかった場合には、その旨のメールが全員に届き、ボックスには何も入らない。

と、サービスはこのようなものである。本人の署名ではなくサーバーによる署名なので少しがっかりしてしまった。また、必ず受取人が必要で、自分を受取人にして自分のために署名するようなことはできない。

PDF署名について

生成される署名はデジタルタイムスタンプ付きのPDF署名でPAdES Basic(「連載:PAdES(PDF長期署名)について(第4回) PAdES Basic」参照)に準拠しているようだ。ハッシュアルゴリズムはSHA256である。 署名に用いられている証明書はサービス利用者毎のものではなく、 本サービスのサーバー "esign-help@adobe.com" に GeoTrustから発行された共通の Adobe CDS 証明書が用いられている。、 GeoTrustのAdobe CDS認証サービス・タイムスタンプサービスについて執筆時点で4つほど疑問に感じていることがある。

• タイムスタンプサービスで精度(Accuracy)が60秒と他のタイムスタンプサービスに比較して極端に長いにも関わらずordering TRUE、即ち発行の時間的順序性が保証されているとベンダーは言っているので注意が必要である。技術的にはaccuracyとorderingをこの精度で正しく運用しているかは少し疑問で、NTPで調時してシステム時刻が巻き戻ることが無いと保証しているのか不安に思う。
• タイムスタンプトークンにおいて、TSAポリシが1.1.2になっている事が気にかかる。OID 1.1は廃止になったISO OID Registration Authorityのもので、このOIDを使う権限がなく適切でないのではないか？
• タイムスタンプ局運用規定(TSAポリシ)が公開されていない。
• Adobe CDSの証明書ポリシによると、発行されるCRLはX.509v2 CRLでAuthorityKeyIdentifierとCRLNumberが必要であると記されているが、GeoTrust CA for Adobeから発行されるCRLは、これに則していない。

何に対して署名しているのか？

このサービスで少し疑問に思ったのは、何に対してデジタル署名していて、何を証明してくれるのかという事だ。

• ユーザ各人について氏名•メールアドレス•手書き署名風のが画像が出てくるが、これらはデジタル署名ではなく、何も証明はしてくれない。
• ユーザ各人の本人確認は単にメールアドレスが届く人というだけで、氏名が本人かはわからない。単にメールアドレスの認証だ。
• Adobeの免責事項にもある通り、オリジナルのPDF文書の内容についてAdobeは何も保証するものではない。
• デジタルタイムスタンプが付与されて以降は、文書が改ざんされていないとは言える。

もし、Adobeが正しい運用しかせず、利用者も信頼できるならば、このPDF文書は

あるメールアドレスをもつユーザ全員が、あるPDF文書に対して承認したというワークフローが完了し、タイムスタンプが付与された時刻以降改ざんされていない

ことを認証するかもしれない。

ところが、もしAdobeが悪い会社だったり、悪い人がいて勝手にPDF文書を改ざんしたりでっちあげたりして、何人かのユーザに署名付きで正しいと主張するPDF文書を送りつけるかもしれない。誰かが承認しなかったとしても、それを承認したとしてワークフローを流すこともできる。

また、ユーザについても、メールにつけられるメッセージはPDF文書に反映されるわけではないので、メール本文に「この文章に反対ならば署名してください」などと書けば受取人は署名するかもしれず、Adobe eSIGNATURESのシステムではこれは文書に対して「承認」したことにされてしまう可能性だってあるのだ。

結局のところ、Adobe eSIGNATURESは、直前に改ざんしちゃう可能性もあるのでみんなが承認しようとした文書そのままの形であるかどうかは別にして、Adobe eSIGNATURESのシステムを通った文書であり、タイムスタンプの時刻以降、暗号が危殆化せず、TSA証明書が有効限りは改ざんされていないこと「だけ」を証明しているだけだと思う。

おわりに

「無料で署名できる」という言葉に踊らされてしまったが、 現状のサービスのままならば、ユーザら本人の署名ではなくAdobeの署名がつく事の意義や有り難みがわからず、Adobeが署名するよりも、単に署名無しで匿名でデジタルタイムスタンプを付与するので十分なような気がするし、効果も大きく変わらないように思う。

とはいえ、電子署名、PDF署名、PAdES長期署名、デジタルタイムスタンプの応用サービスとしてこのサービスは十分に野心的かつ革新的だと思うし、正直びっくりした。まだベータ版のサービスとの事なので、今後の改良にとても期待しています。

このブログは私の所属とは関係なく個人的な見解に基づいて書いています。勉強が足りないために間違っている点もあるかもしれませんが、その際にはコメント欄でご指摘頂ければ幸いです。

関連リンク

• Adobe eSIGNATURES - 無料、PDF署名サービスベータサイト
• Adobe Labs - Adobe eSignatures
• Adobe Featured Blog - Adobe launches new cloud-based eSignature service
• Tech Crunch Japan: 電子署名界に革命勃発：Adobeが電子署名サービスのeSignatureを無料でベータ公開

本ブログ内の関連記事

• AcrobatのAdobe CDSについて書いてみる
• dumpasn1用のAdobe CDS関連の設定の追加
• 連載:PAdES(PDF長期署名)について(第4回) PAdES Basic
• 連載:PAdES(PDF長期署名)について(第5回) PAdES Basicと署名ポリシ

最近、セキュリティに関係したトピックをサボっていてすみません。書きたいと思っているネタは幾つかあるんですが、ナカナカ時間が取れなくて、、、セキュリティ関係のやつは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というフレームワークについて調べた事、思った事を述べさせて頂いた。

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