タイムスタンプのメカニズム

4.2.3.1 デジタル署名を用いたタイムスタンプ

このメカニズムはPKI方式によるもので、TSAが鍵ペアを持ちタイムスタン プ・トークンにデジタル署名を行う。ExtMethod拡張で陽にデジタル署名方式を 指定せず、この拡張を用いなければRFC 3161のタイムスタンプ・トークンと同 じになる。詳しくは3章を参照のこと。

PKI方式なので署名されたタイムスタンプ・トークンの署名を検証するために は、TSA証明書からトラストアンカーまでの認証パスの有効性を検証しなければ ならない。

4.2.3.2 MACを用いたタイムスタンプ

このメカニズムはTSAが時刻と関連させるデータを結合させるために秘密鍵を 用いる。タイムスタンプ・トークンはメッセージ認証コード(MAC)によって認証 される。この方式を用いる場合、TSAは検証も請け負うことになる。したがって TSAは、偽操作したことを検出する外部の証拠を持たないので、完全に信頼され るものでなければならない。TSAは適切なセキュリティログと秘密鍵を検証する ために外部の監査を受けなければならない。

それぞれの登場者(タイムスタンプ要求者、タイムスタンプ検証者、TSA)間での 情報交換はデータの完全性とメッセージ源の認証保護がなされなければならない。

例えばSSL/TLSなどのセキュアなチャネルを用いるなどである。

このメカニズムを用いるにはExtMethod拡張でMACを用いることを指定する。

TSA応答

TSAの応答ではContentsがCMSのAuthenticatedDataであることを示 す。

AuthenticatedDat ::= SEQUENCE { version CMSVersion,

recipientInfos RecipientInfos,

macAlgorithm MessageAuthenticationCodeAlgorithm, encapContentInfo EncapsulatedContentInfo,

mac MessageAuthenticationCode }

MessageAuthenticationCode ::= OCTED STRING RecipientInfosは存在するが、ここでは空の集合にする。

RecipientInfos ::= SET SIZE(0) OF RecipientInfo

MAC生成

MACの入力はTSTInfo構文をDERエンコードしたオクテットストリング である。MACアルゴリズムはOIDで指定するが、ここでは特定のMACア ルゴリズムは指定していない。

トークンの検証

MACの秘密鍵はTSAしかもっていないので、トークンの検証者は

ISO/IEC 18014-1の検証プロトコルでTSAに検証依頼する。この際データの 完全性とデータ発信源認証が可能なセキュアなチャネルを用いる。

4.2.3.3 アーカイブを用いたタイムスタンプ

このメカニズムではTSAは、タイムスタンプとしてのmessageImprintと時刻 を結合した情報への参照のみを持つタイムスタンプ・トークンを返す。TSAはタ イムスタンプが正しいことを検証するために十分な情報をローカルにアーカイブ する。

TSAアーカイブは、用いたメカニズム、監査ログ、送受ログなどからなるタイ ムスタンプ・トークンをアーカイブしても良い。この意味ではTSAは電子公証の 役割を果たす。TSAは偽操作を検出できる外部証拠を持たないので、完全に信頼 されなければならない。TSAは適切なセキュリティログと秘密鍵を検証するため に外部の監査を受けなければならない。

それぞれの登場者(タイムスタンプ要求者、タイムスタンプ検証者、TSA)間での 情報交換はデータの完全性とメッセージ源の認証保護がなされなければならない。

例えばSSL/TLSなどのセキュアなチャネルを用いるなどである。

このメカニズムはExtMethod拡張でアーカイブであることのOIDで識別する。

TSA応答

タイムスタンプ・トークンはcontentTypeにid-data、contentにTSTInfo をDERエンコードした値が入れられる。

TimestampToken ::= SEQUENCE { contentType id-data

content DER-encoded value of TSTInfo }

トークン検証

トークンの原本であるアーカイブはTSAしかもっていないので、タイムス タンプ検証者はISO/IEC 18014-1の検証プロトコルでTSAに検証依頼する。

この際データの完全性とデータ発信源認証が可能なセキュアなチャネルを用