付録

タイムスタンプ・プロトコルに関する技術調査

この仕組みでは、タイムスタンプ要求者がレスポンスを受けるとき、レスポン スの時刻がその時間枠の範囲であることと、その時間枠内で一度だけのハッシュ 値の発生であることを確認する。もし同じハッシュ値が時間枠内に複数存在する ならば、タイムスタンプ要求者はnonceを使うか、時間枠が、同じハッシュ値が 時間枠内に一度だけ存在するような状態に戻るまで待つ。

messageImprint

要求者 TSA

同じmessageImprint は受け取らない

messageImprint

time window time window

初見のmessageImprint なので受け取る

moving

同じmessageImprintを再度受け取る(再送する)ためには time windowがmovingするまで待たなければならない。

同じmessageImprintを再度受け取る(再送する)ためには time windowがmovingするまで待たなければならない。

ローカル クロック

図 3.1-2moving time window

タイムスタンプ・プロトコルに関する技術調査

3.1.5.1 特定の時間における署名

本節は、一般的なタイムスタンプ・サービスに対する利用法の一例として、タ イムスタンプ要求者(Subscriber)とタイムスタンプ検証者(Verifier)の振る舞いを 示している。

適切な証明書ステータス情報がチェック(MUST)された上で、ある時点である署 名データが生成される。このアプリケーションは、電子署名メカニズムによって 生成された証拠とともに使われることを想定している。署名データは否認防止ポ リシーによってのみ検証されることができる。このポリシーは暗黙的かもしれな いし、明示的かも知れない(MAY)。とりわけ否認防止ポリシーは、署名者によって その署名鍵の危殆化を告知することが許される期間を指定することができる。

このように署名データは、この期間の最後まで有効であることを保証されない かも知れない。電子署名を検証するために、以下の基本的な技術が使われるだろ う。

(a) タイムスタンプ情報は、署名された後(例えば数分あるいは数時間以内)直ちに 得られる必要がある。

① 署名がTSAに提出され、TSAはその署名にタイムスタンプ・トークンを返す。

② サービス利用者はそのタイムスタンプ・トークンが正しいことを検証しなけ ればならない(MUST)。

(b) 電子署名の有効性は、以下の手順によって検証される(may)。

① タイムスタンプ・トークン自身が検証され(MUST)、署名者の署名に対して適 用されていることが検証されなければならない(MUST)。

② タイムスタンプ・トークン内でTSAによって示された日時が、読み出されな ければならない(MUST)。

③ 署名者によって使われた証明書が、同定され、取り出されなければならない (MUST)。

④ TSAによって示された日時が、署名者証明書の有効期間内でなければならな い(MUST)。

⑤ タイムスタンプ操作時におけるその証明書の失効情報が、取り出されなけれ ばならない(MUST)。

タイムスタンプ・プロトコルに関する技術調査

⑥ 証明書は失効されていたなら、その失効日時はTSAが示した日時よりも後で あるべきである(shall)。

これら全ての条件が成功ならば、その電子署名は有効であると宣言されるべき である(shall)。

3.1.5.2 タイムスタンプのアクセス記述子

RFC 3161[TSP]とRFC2459[old-PKIX]、RFC3280[PKIX]の前後関係

RFC 3161では、TSA証明書プロファイルとしてRFC2459を参照している。

RFC 3161がインターネットドラフトとして検討されていた頃、同じくRFC2459も並行して改訂作業 が進んでおり、その中でsubjectInformationAccess(SIA)拡張の導入が検討されていた。このためRFC 3161もこのSIA拡張を利用することを意識して設計されたが、RFC 3161はRFC3280よりも先にRFC 化されてしまった。

IETFではRFC化されていないインターネットドラフトをリファレンスとすることができないため、

RFC 3161では公式にはRFC2459をリファレンスとして用い、RFC3280にて規定されるべき要件につ いては、付録(APPENDIX C)において補足した形となっている。

補足：本節は、([TSP]執筆時点でRFC化されていなかった)[PKIX]に記載され るべき項目として、TSA証明書のsubjectInformationAccess拡張に関する要件を 記述している。

TSA証明書は、TSAにアクセスする方法を示すために subjectInformationAccess拡張を含む(MAY)。

このSIA拡張のaccessMethodフィールドには、OID id-ad-timestampingが含 まれなければならない(MUST)。

id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }

SubjectInfoAccessSyntax ::=

SEQUENCE SIZE (1..MAX) OF AccessDescription

AccessDescription ::= SEQUENCE {

accessMethod OBJECT IDENTIFIER, accessLocation GeneralName }

id-ad-timeStamping OBJECT IDENTIFIER ::= {iso(1)

タイムスタンプ・プロトコルに関する技術調査

internet(1) security(5) mechanisms(5) pkix(7) ad (48) timestamping (3)}

このSIA拡張のaccessLocationフィールドの値は、TSAへのアクセスに使われ る転送プロトコルを定義し、各転送プロトコルに依存した情報を含むかも知れな い(may)。

なお、その後公開されたRFC 3280では、以下のように記述されている。

RFC 3280より:

証明書主体者がタイムスタンプ・サービスを提供する場合、accessMethodフィ ールドにはid-ad-timeStamping OIDが使われる。

タイムスタンプ・サービスの提供方法によって、accessLocationフィールドは 以下のように定義される。

サービス提供方法 accessLocationのタイプ httpまたはftp URI(MUST)

e-mail rfc822Name(MUST) TCP/IP(ソケットベース) iPAddressまたはdNSName(may)

なお、他のPKIX仕様において追加のアクセス記述子が定義されるかも知れな い(may)。