ネットワーク WG
Request for Comments: 3161
分類: スタンダードトラック

C. Adams
Entrust
P. Cain
BBN
D. Pinkas
Integris
R. Zuccherato
Entrust
2001年 8月

English

X.509インターネット PKI タイムスタンププロトコル(TSP)
(Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP))

このメモの位置付け

本書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、それを改良するための議論や提言を求めるものである。 このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」(STD 1) の最新版を参照すること。 このメモの配布に制限は無い。

著作権表記

Copyright (C) The Internet Society (2001). All Rights Reserved.

要旨

本書は、TSA (Time Stamping Authority:タイムスタンプ局)に送られるリクエストと、それに返されるレスポンスのフォーマットを記述する。本書は、TSA の運用について、レスポンスを生成するためにリクエストを処理することに関するいくつかのセキュリティ関連要件も確立する。

目次

1. はじめに

2. TSA
2.1. TSA の要件
2.2. TSA トランザクション
2.3. TSA の識別
2.4. リクエストとレスポンスのフォーマット

3. トランスポート
3.1. E メールを使うタイムスタンププロトコル
3.2. ファイルに基づくプロトコル
3.3. ソケットに基づくプロトコル
3.4. HTTP 経由のタイムスタンププロトコル

4. セキュリティについての考慮事項

5. 知的財産権

6. 参考文献

7. 著者のアドレス

付録 A: CMS を使った Signature Time-stamp 属性

付録 B: 特定時刻における署名

付録 C: 1988年版 シンタックスを使う ASN.1 モジュール

付録 D: タイムスタンピングのためのアクセス記述子

 

1. はじめに English

タイムスタンピングサービスは、あるデータが特定の時刻前に存在したことを証明する言明を支援する。TSA (Time Stamping Authority:タイムスタンプ局)は、TTP (Trusted Third Party:信頼できる第三者)サービスとして運用される可能性があるが、他の運用モデルが適切である場合もあろう。(例: ある組織体が、TSA を内部的なタイムスタンピング目的のために要求する可能性がある。)

否認防止サービス [ISONR] は、「特定の時刻以前におけるデータの存在を立証する能力」を要求する。このプロトコルは、このようなサービスを行うための構成要素として使われる可能性がある。「デジタル署名が公開鍵証明書の有効期間内に生成されたこと」の証明方法の例は、付録において提供される。

本書中の(大文字で書かれた)キーワード "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "SHALL", "RECOMMENDED", "MAY", "OPTIONAL"は、[RFC2119] に記述されたように解釈されるべきものである。

あるデータに対して特定の時刻を関連づけるために、TSA が使われる必要がある可能性がある。この TTP は、この関心ある時刻における特定のデータについて「存在証明(proof-of-existence)」を提供する。

TSA の役割は、あるデータが特定時刻前に存在していたことを示す証拠を確立するために、データにタイムスタンプすることにある。このことは、例えば、 「デジタル署名が対応する証明書が失効する前にメッセージに適用されていたので、失効された公開鍵証明書が失効時刻前になされた署名を検証するために使うことを許容できること」を検証するために使うことができる。このことは、重要な PKI(公開鍵インフラストラクチャ)利用である。TSA は、また、締め切りが極めて重要であるとき、受理の時刻を示したり、ログ中の項目のためにトランザクションの時刻を示したりするのに使うことができる。TSA の包括的な用途のリストは、本書の範囲外である。

他の PKIX 標準が CA 運用の要件を定めないのと同様に、この標準は TSA 運用の全てのセキュリティ要件を定めるものではない。むしろ、TSA は、予想されるクライアントに正確なタイムスタンプ生成を保証するために実施しているポリシーを知らせること、そして、クライアントがこれらのポリシーが自ら要求に見合うと満足した場合にのみ TSA のサービスを利用することが期待される。

2. TSA English

TSA は、データが特定時刻において存在したことを示すために、タイムスタンプ トークンを作成する TTP (信頼できる第三者)である。

本書において以降、"valid request"は、正しくデコードできるものであり、2.4 節 において規定した形態のものであり、サポートされた TSA 登録者(subscriber)から送信されたものを意味するものとする。

2.1. TSA の要件 English

TSA には、次の事項が要求される(REQUIRED)。:

  1. 信頼に値する時刻の情報源を使うこと。
     
  2. 各タイムスタンプ トークンに信頼に値する時刻の値を含めること。
     
  3. 新たに生成された各タイムスタンプ トークンに、一意な数値を含めること。
     
  4. 可能であれば、有効なリクエストを要求者から受け取ってからタイムスタンプ トークンを作成すること。
     
  5. トークンが作成されたときに従ったセキュリティポリシーを指し示すために、各タイムスタンプ トークンと識別子の中に含めること。
     
  6. データのハッシュ結果(すなわち、OID によって識別される一方向性と衝突困難性をもつハッシュ関数と関連づけられるデータへの押印)についてのみタイムスタンプすること。
     
  7. 一方向性と衝突困難性をもつハッシュ関数の OID を試験することと、ハッシュ値の長さがハッシュ アルゴリズムと整合することを検証すること。
     
  8. いかなるやり方でタイムスタンプされた押印をも(前の項目において仕様としたように、その長さをチェックすること以外に)試験しないこと。
     
  9. タイムスタンプ トークン中に、いかなる要求主体の身元をも含まないこと。
     
  10. この目的のために生成された鍵を使って各タイムスタンプ トークンに署名し、対応する証明書上に示された鍵の属性(訳注: タイムスタンプのこと)をもつ。
     
  11. 拡張フィールドを使っている要求者によって依頼された場合、TSA によってサポートされている拡張についてのみ、タイムスタンプ トークン中に追加的情報を含める。これが不可能な場合、TSA は、エラーメッセージで応答すること(SHALL)

2.2. TSA トランザクション English

このメカニズムの最初のメッセージとして、要求主体は、リクエストを TSA (Time Stamping Authority)に送ることによってタイムスタンプ トークンを要求する。(リクエストは、以下に規定されるように TimeStampReq であるか、あるいは、これを含む。)2番目のメッセージとして、TSA は、レスポンスを要求主体に送ることによって 応答する。(レスポンスは、以下に規定されるように TimeStampResp であるか、あるいは、これを含む。)

レスポンス を受け取ったとき、要求主体は、レスポンス中で返された状態エラーを検証するものとする(SHALL)。(レスポンスは、以下に規定されるように、通常 TSP (TimeStampToken)を含む TimeStampResp であるか、あるいは、これを含む。)そして、エラーが無い場合、要求主体は、TimeStampToken に含まれている様々なフィールドと、TimeStampToken のデジタル署名の有効性を検証するものとする(SHALL)。特に、要求主体は、何がタイムスタンプされることを要求されたかに対応して、何がタイムスタンプされたかを検証するものとする(SHALL)。要求者は、TimeStampToken が TSA の正しい証明書識別子、正しいデータ押印および正しいハッシュ アルゴリズム OID を含んでいることを検証するものとする(SHALL)。 次に要求主体は、レスポンスに含まれている時刻をローカルな信頼された時刻リファレンスが利用可能であれば、それに照らして検証するか、あるいは、レスポンスに含まれている nonce の値(クライアントによって 1回のみ生成された可能性が高い大きな乱数) をリクエストに含まれた値に照らして検証することによって、レスポンスの timeliness を検証するものとする(SHALL)。リプレイ攻撃検出の詳細については、「セキュリティに関する考慮事項」の章 (item 6) を参照。上記の検証のいずれかが失敗した場合、TimeStampToken は、却下されるものとする(SHALL)

次に、TSA の証明書は失効されるので、証明書の状態は、証明書がまだ有効であることを検証するためにチェックされる必要がある。(例: 適切な CRL をチェックすることによる。)

次に、クライアント アプリケーションは、トークンが発行されたときに従ったポリシーがアプリケーションについて許容できるか否かを判定するために policy フィールド をチェックする必要がある(SHOULD)

2.3. TSA の識別 English

TSA は、各タイムスタンプ メッセージに、署名目的で特別に用意された鍵で署名しなければならない(MUST)。 TSA は、個別複数の私有鍵をもつことができる(MAY)。 (例: 異なるポリシー、異なるアルゴリズム、異なる私有鍵長、性能向上に対応するため。)対応する証明書は、拡張された鍵用途フィールド拡張を KeyPurposeID の値が id-kp-timeStamping であるものがひとつのみ、[RFC2459] の 4.2.1.13 節に規定されたように含まなければならない(MUST)。この拡張は、クリティカルでなければならない(MUST)

次のオブジェクト識別子は、値 id-kp-timeStamping をもつ KeyPurposeID を識別する。

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

identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
kp (3) timestamping (8)}

2.4. リクエストとレスポンスのフォーマット English

2.4.1. リクエストフォーマット English

タイムスタンピングのリクエストは、次のとおり。:

TimeStampReq ::= SEQUENCE { 

version INTEGER { v1(1) }, 
messageImprint MessageImprint, -- タイムスタンプされるべきデータのハッシュアルゴリズム OID およびハッシュ値
reqPolicy TSAPolicyId OPTIONAL,
nonce INTEGER OPTIONAL,
certReq BOOLEAN DEFAULT FALSE,
extensions [0] IMPLICIT Extensions OPTIONAL    }

バージョン フィールド(現行 v1)は、Time- Stamp リクエストのバージョンを記述する。

messageImprint フィールドは、タイムスタンプされるべきデータのハッシュ を含む必要がある(SHOULD)。ハッシュは、OCTET STRING として表現される。その長さは、そのアルゴリズムについてのハッシュ値の長さと一致しなければならない(MUST)
(例: SHA-1 については 20 バイトであり、MD5 については 16バイトである。)

MessageImprint ::= SEQUENCE { 

hashAlgorithm AlgorithmIdentifier, 
hashedMessage OCTET STRING }

hashAlgorithm フィールドに示されたハッシュアルゴリズムは、既知の(一方向性・衝突困難性ある)ハッシュアルゴリズムである必要がある(SHOULD)。これは、一方向性であり、かつ、衝突困難性(collision resistant)ある必要がある(SHOULD)ことを意味する。TSA (Time Stamp Authority)は、与えられたハッシュ アルゴリズムが「十分」であるとされているか否かについて、チェックする必要がある(SHOULD)。(例えば、暗号解析における知識の現状に基づく、計算資源における実践の現状に基づく。) TSA がハッシュ アルゴリズムを理解できない、もしくは、ハッシュアルゴリズムが弱いと知っている場合、(各個別の TSA の裁量に判断が残されており、)TSA は、pkiStatusInfo として 'bad_alg' を返すことによって、タイムスタンプ トークンを提供することを断る必要がある(SHOULD)

reqPolicy フィールドが含まれる場合、reqPolicy フィールドは、TSA ポリシーを示す。このもとで、TimeStampToken が提供される必要がある(SHOULD)。TSAPolicyId は、次のように規定される。:

TSAPolicyId ::= OBJECT IDENTIFIER

nonce が含まれる場合、nonce は、ローカルな時計が利用不能なとき、クライアントがレスポンスの timeliness を検証することを許容する。nonce は、クライアントによって 1回のみ生成された可能性が高い大きな乱数 である。 (例: 64 bit 数値。) そのような場合、同一の nonce 値がレスポンスにおいて示されなければならず(MUST)、そうでなければ、レスポンスは、棄却される。

certReq フィールドがあり、true が設定されている場合、レスポンス中の SigningCertificate 属性の中の ESSCertID 識別子によって参照されている TSA の公開鍵証明書 は、TSA によって、そのレスポンス中の SignedData 構造体からの証明書のフィールドにおいて提供されなければならない(MUST)。そのフィールドは、他の証明書も含む可能性がある。

certReq フィールドが無い場合、もしくは、certReq フィールドがあり、false が設定されている場合、SignedData 構造体からの証明書のフィールドは、レスポンス中にあってはならない(MUST)

拡張フィールドは、将来、追加的情報をリクエストに追加するための一般的なやり方である。拡張は、[RFC 2459] において規定されている。拡張が、(クリティカルと印付けされていようが、ノンクリティカルと印付けされていようが、) 要求者によって使われているがタイムスタンピング サーバーによって理解されない場合、サーバーは、トークンを発行しないものとし(SHALL)、失敗(unacceptedExtension)を返すものとする(SHALL)

タイムスタンプ リクエストは、この情報は、TSA によって検証されたものではないので、要求者を識別しない。(2.1 節参照。)TSA が要求主体の身元を要求する状況において、代替的な識別/認証の手段が使われる必要がある。(例: CMS カプセル化 [CMS] もしくは TLS 認証 [RFC2246]。)

2.4.2. レスポンスフォーマット English

タイムスタンピング レスポンス は、次のとおり。:

TimeStampResp ::= SEQUENCE { 

status PKIStatusInfo, 
timeStampToken TimeStampToken OPTIONAL }

status は、次のように、[RFC2510] の 3.2.3 節における status の定義に基づく。:

PKIStatusInfo ::= SEQUENCE { 

status PKIStatus, 
statusString PKIFreeText OPTIONAL, 
failInfo PKIFailureInfo OPTIONAL }

status が値 0 または 1 を含むとき、TimeStampToken がなければならない(MUST)。 status が 0 または 1 以外の値を含むとき、TimeStampToken は、存在してはならない。(MUST NOT)。次の値のひとつが、status に含まれなければならない(MUST)。:

PKIStatus ::= INTEGER { 

granted (0), -- PKIStatus が値 0 をもつとき、要求された TimeStampToken が存在する。
grantedWithMods (1), -- PKIStatus が値 1 をもつとき、変更された TimeStampToken が存在する。
rejection (2), 
waiting (3), 
revocationWarning (4),-- このメッセージは、失効が差し迫っているという警告を含む。
revocationNotification (5) -- 失効が起きたということの通知。 }

対応するサーバーは、いかなる他の値も作成してはいけない(SHOULD NOT)。対応するクライアントは、判定できない値がある場合、エラーを生成しなければならない(MUST)

TimeStampToken が無い場合、failInfo は、タイムスタンプ リクエストが棄却された理由を示し、次の値のいずれかとなる可能性がある。

PKIFailureInfo ::= BIT STRING { 

badAlg (0), -- 解釈されない、あるいは、サポートされていないアルゴリズム識別子である。
badRequest (2), -- トランザクションが許可されていないか、サポートされていない。
badDataFormat (5), -- 送信されたデータのフォーマットに誤りがある。
timeNotAvailable (14), -- TSAの時刻源が利用できない。
unacceptedPolicy (15), -- 要求された TSA ポリシーが TSA によってサポートされていない。
unacceptedExtension (16), -- 要求された拡張がTSAによりサポートされていない。
addInfoNotAvailable (17) -- 要求された追加的情報は、理解不能であったか、あるいは、利用不能であった。
systemFailure (25) -- リクエストは、システム障害によりリクエストが処理できなかった。 }

これらのみが、サポートされるものとする(SHALL) PKIFailureInfo の値である。

対応するサーバーは、いかなる他の値を作成してはいけない(SHOULD NOT)。対応するクライアントは、判定できない値がある場合、エラーを生成しなければならない(MUST)

PKIStatusInfo の statusString フィールドは、「messageImprint フィールドは、正しくフォーマットされていない」のような理由を含むように使うことができる(MAY)

TimeStampToken は、次のとおり。:
これは、ContentInfo ([CMS]) として定義されており、署名されたデータ content type をカプセル化するものとする(SHALL)

TimeStampToken ::= ContentInfo 

-- contentType は、id-signedData ([CMS]) である。
-- content は、SignedData ([CMS]) である。

SignedData 構造体の type EncapsulatedContentInfo のフィールドは、次の意味をもつ。:

eContentType は、content type を一意に仕様とするオブジェクト識別子である。タイムスタンプ トークンについて、これは、次のように規定される。:

id-ct-TSTInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)

us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}

eContent は、オクテットストリングとして運ばれるコンテンツ自体である。eContent は、TSTInfo の DER-encoded 値とする(SHALL)

タイムスタンプ トークンは、TSA の署名以外のいかなる署名をも含んではならない(MUST NOT)。TSA 証明書の証明書識別子 (ESSCertID) は、signerInfo 属性として SigningCertificate 属性中に含まれなければならない(MUST)

TSTInfo ::= SEQUENCE { 

version INTEGER { v1(1) }, 
policy TSAPolicyId, 
messageImprint MessageImprint, -- TimeStampReq の同じフィールドと同じ値を持たなければならない(MUST)。 
serialNumber INTEGER, -- タイムスタンピングユーザは、160 ビットまでの数値に対応できるようにしておかなければならない(MUST)。 
genTime GeneralizedTime, 
accuracy Accuracy OPTIONAL,
ordering BOOLEAN DEFAULT FALSE,
nonce INTEGER OPTIONAL,-- TimeStampReq に同じフィールド (nonce) があった場合、(nonce が)存在しなければならない(MUST)。その場合、(nonce は)同じ値でなければならない(MUST)
tsa [0] GeneralName OPTIONAL,
extensions [1] IMPLICIT Extensions OPTIONAL }

バージョン フィールドは、time- stamp トークンのバージョン(現行 v1)を記述する。

Conforming タイムスタンピング サーバーは、バージョン 1のタイムスタンプ トークンを提供できなければならない(MUST)

オプションとしてのフィールドの中で、nonce フィールドのみがサポートされなければならない(MUST)

タイムスタンピングを確認要求する者は、すべてのオプションとしてのフィールドがあるバージョン 1 のタイムスタンプ トークンを理解できなければならない(MUST)が、拡張がある場合、いかなる拡張の意味をも理解することを強制されるものではない。

policy フィールドは、レスポンスが作成されたときに従った TSA のポリシーを示さなければならない(MUST)。同様のフィールドが TimeStampReq にあった場合、それは、同一の値をもたなければならない(MUST)。そうでなければ、エラー(unacceptedPolicy)が返されなければならない(MUST)。このポリシーは、以下の種類の情報を含むことができる(MAY)。(ただし、このリストは、網羅的なものではない。):

messageImprint は、TimeStampReq 中の同じフィールドと同じ値を持っていなければならず、ハッシュ値のサイズは、hashAlgorithm で指定されるハッシュアルゴリズムにより期待されるサイズと一致しなければならない(MUST)

serialNumber フィールドは、TSA によって各 TimeStampToken のために確保された数値である。これは、与えられた TSA によって発行された各 TimeStampToken について、固有でなければならない(MUST)。(すなわち、TSA 名とシリアル番号が固有の TimeStampToken を識別する。) この属性は、可能性あるサービスの中断(例: クラッシュ)後であっても保存されなければならない(MUST)ことを知っておく必要がある。

GeneralizedTime の ASN.1 シンタックスは小数点以下の秒の単位を含むことができる。GeneralizedTime が 1秒単位の粒度で表現するよう制限されているといった [RFC 2459] の 4.1.2.5.2 節の制限を受けることなく、ここでは、この ASN.1 シンタックスを使うことができる。

GeneralizedTime 値は、秒を含まなければならない(MUST)。しかし、秒単位より正確なものをもつ必要がないとき、([RFC 2459] におけるように)秒単位に制限された GeneralizedTime が使われる必要がある(SHOULD)

構文は、右のとおり。: YYYYMMDDhhmmss[.s...]Z 
例: 19990609001326.34352Z

X.690 | ISO/IEC 8825-1 は、DER-encoding について、次の制約を提供する。

このエンコーディングは、"Z" (これは、"Zulu" time を意味する。)で終わらなければならない(MUST)。10 進数の小数点がある場合、これは、"."でなければならない(MUST)。小数点以下の要素がある場合、末尾に続く 0 は省略しなければならない(MUST)。; 小数点以下の要素が 0 である場合、小数点以下全体を省略し、小数点要素もまた省略しなければ(MUST)

Midnight (GMT) は、次の形式で表現されるものとする。: "YYYYMMDD000000Z"。ここで "YYYYMMDD" は、問題中の午前 0 時に続く日付である。

ここに有効な表現の例を掲げる。:

"19920521000000Z" 
"19920622123421Z" 
"19920722132100.3Z"

accuracy は、GeneralizedTime に含まれる UTC 時間の時間偏差を表現する。

Accuracy ::= SEQUENCE { 

seconds INTEGER OPTIONAL, 
millis [0] INTEGER (1..999) OPTIONAL, 
micros [1] INTEGER (1..999) OPTIONAL }

seconds、millis もしくは micros が無い場合、空いているフィールドについて値 0 が採用されなければならない(MUST)

accuracy 値を GeneralizedTime に加えることによって、タイムスタンプ トークンが TSA によって作成された時刻 の上限(最近の値)が入手可能である。同様に、accuracy を GeneralizedTime から引くことによって、タイムスタンプ トークンが TSA によって作成された時刻の下限が入手可能である。

accuracy は、秒、ミリ秒(1-999)およびマイクロ秒(1-999)に分解されることができ、全て整数で表現される。

accuracy のオプションとしてのフィールドが無い場合、accuracy は、他の手段によって入手可能である。(例: TSAPolicyId)

ordering フィールドが存在しないか、存在しても FALSE に設定されている場合、genTime フィールドは、TSA によってタイムスタンプトークンが生成された時刻のみを示す。そのような場合、同じ TSA あるいは別の TSA から発行された複数のタイムスタンプトークンの順序付けはひとつ目のタイムスタンプトークンの genTime と 2つ目のタイムスタンプトークンの genTime との差が個々のタイムスタンプトークンの genTime の accuracy の和よりも大きい場合に可能となる。

ordering フィールドが有り、true が設定されている場合、同一の TSA からのすべてのタイムスタンプ トークンは、genTime の精度に関わらず、常に genTime フィールドに基づいて依頼できる。

nonce フィールドは、それが TimeStampReq にあった場合、存在しなければならない(MUST)。そのような場合、これは、TimeStampReq 構造体において提供された値と等しくなければならない(MUST)

tsa フィールドは、TSAの名前を特定するためのヒントを与えることを目的としている。存在する場合、トークンを検証するのに使われる証明書に含まれる主体者名のうちのひとつと関連づけられなければならない(MUST)。しかし、実際のレスポンスに署名したエンティティの特定は、常に signerInfo の一部である SigningCertificate 属性の中にある証明書識別子(ESSCertID 属性)を使用して行われる。([ESS] の 5章を参照。)

拡張は、追加的情報を将来、追加するための一般的なやり方である。拡張は、[RFC 2459] において規定されている。

特定の拡張フィールドタイプは、標準において仕様とされる可能性、あるいは、あらゆる組織体もしくはコミュニティによって規定・登録される可能性がある。

 

3. トランスポート English

TSA メッセージ用に必須のトランスポートメカニズムは、本書中に無い。次に述べるメカニズムは、オプションとしてのものである。; 追加的なオプションとしてのメカニズムは、将来、規定される可能性がある。

3.1. E メールを使うタイムスタンププロトコル English

この節は、2 章 付録 D に記述された「プロトコル交換についての ASN.1-エンコードされたメッセージ」をインターネットメール経由で運ぶための方法を仕様とする。

2つの MIME オブジェクトは、次の仕様とされる。:

Content-Type: application/timestamp-query 
Content-Transfer-Encoding: base64 
<<ASN.1 DERエンコードされたタイムスタンプリクエストメッセージを BASE64 エンコーディングしたもの>>>

Content-Type: application/timestamp-reply 
Content-Transfer-Encoding: base64 
<<ASN.1 DERエンコードされたタイムスタンプリクエストメッセージを BASE64 エンコーディングしたもの>>

これらの MIME オブジェクトは、それぞれ、通常の MIME 処理エンジンを使って送受信することができ、タイムスタンプ メッセージについてシンプルなインターネットメール配送を提供する。

application/timestamp-query と application/timestamp-reply MIME types について、実装は、オプションとしての"name" と "filename"パラメータを含む必要がある(SHOULD)。ファイル名を含めることは、タイムスタンプ queries と replies がファイルとして保存されるとき、type 情報を保持するのに役立つ。これらのパラメータが含まれているとき、適切な拡張子をもったファイル名が選択される必要がある(SHOULD)。

MIME Type File Extension 
application/timestamp-query .TSQ 
application/timestamp-reply .TSR

さらに、ファイル名は、3 文字の拡張子を伴った 8 文字に制限される必要がある(SHOULD)。その 8 文字のファイル名は、いかなる別個の名前であることができる。

3.2. ファイルに基づくプロトコル English

タイムスタンプ メッセージを含むファイルは、TSA メッセージの DER encoding のみを含まなければならない(MUST)。すなわち、ファイル中に、無関係のヘッダーや付随情報があってはならない(MUST)。そのようなファイルは、タイムスタンプメッセージを、例えば FTP を使って配送するために使うことができる。

タイムスタンプリクエストは、(タイムスタンプ Query のように)ファイル拡張子 .tsq のファイル中に含まれる必要がある(SHOULD)。タイムスタンプレスポンスは、(タイムスタンプ Reply のように)ファイル拡張子 .tsr のファイル中に含まれる必要がある(SHOULD)

3.3. ソケットに基づくプロトコル English

次のシンプルな TCP に基づくプロトコルは、TSA メッセージの配送のために使われるべきものである。このプロトコルは、主体がトランザクションを開始し、結果を得るために 投げることができる場合に適切である。

このプロトコルは、基本的に、定義されたポート(IP ポート番号 318)上で TSA メッセージを受け入れることができる TSA 上の待機プロセス を想定している。

典型的には、開始者は、このポートにバインドし、初期 TSA メッセージを送る。応答者は、TSA メッセージ、かつ/または、後で実際の TSA メッセージ レスポンスを投げるときに使われるべき参照番号で応答する。

数多くの TSA レスポンス メッセージが与えられたリクエストについて作成されるべき場合、(例えば、実際のトークンが作成されうる前にレシートが送られなければならない場合、) 新しい polling reference も返される。

最後の TSA レスポンス メッセージがその数値によって抽出されている場合、新しい polling reference は与えられない。

トランザクションの開始者は、「直接 TCP に基づく TSA メッセージ」を受信者に送る。受信者は、同様のメッセージで応答する。

「直接 TCP に基づく TSA メッセージ」は、次のものから成る。: length (32bit), flag (8bit), value (以下で定義される。)

length フィールドは、メッセージ (すなわち、"value" のオクテット数 + 1)の残りのオクテット数を含む。このプロトコル中のすべての 32 ビットの値は、ネットワーク バイト順となるように規定される。

 

メッセージ名   フラグ   値

tsaMsg '00'H DERエンコードされたTSAメッセージ
-- TSAメッセージ。
pollRep '01'H ポーリングリファレンス(32 ビット),
再チェック時間(32 ビット)
-- TSAメッセージレスポンスが準備されていない場合のポーリングレスポンス。; 後のポーリングのためにポーリングリファレンスの値(および予測時間の値)を使う。
pollReq '02'H ポーリングリファレンス(32 ビット)
-- 最初のメッセージに対する TSA メッセージレスポンスの要求。
negPollRep '03'H '00'H
-- 次のポーリングレスポンスは無い。(すなわち、トランザクションは完了した。)
partialMsgRep '04'H 次のポーリングリファレンス(32 ビット),
再チェック時間(32 ビット),
DER エンコードされた TSA メッセージ
-- 最初のメッセージに対する部分的なレスポンス(レシート)およびレスポンスの次の部分を取得するのに利用される新しいポーリングリファレンス(と予測時間値)。
finalMsgRep '05'H DER エンコードされたTSA メッセージ
-- 最初のメッセージに対する最後の(一回だけの場合もある)レスポンス。
errorMsgRep '06'H 人が読解可能なエラーメッセージ
-- エラーが検知された場合に生成される。(例えば、存在しないか終了したポーリングリファレンスを受信した場合等。)

起こりうるメッセージの順序は、次のとおり。:

a) エンド主体は、tsaMsg を送信し、レスポンス中に pollRep, negPollRep, partialMsgRep もしくは finalMsgRep のいずれかを受信する。

b) エンド主体は、pollReq メッセージを送信し、レスポンス中に negPollRep, partialMsgRep, finalMsgRep もしくはerrorMsgRep のいずれかを受信する。

"time-to-check-back" パラメータは、unsigned 32 ビットの数値である。これは、秒単位の時刻であり、クライアントが status を再度、チェックする必要がある(SHOULD)最小限の間隔を示す。

これは、エンドエンティティがその次の pollReq を送る必要がある時刻の見積もりを提供する。

3.4. HTTP 経由のタイムスタンププロトコル English

この節は、2 章 付録 D に記述された「プロトコル交換についての ASN.1-エンコードされたメッセージ」を HTTP プロトコル経由で運ぶための方法を仕様とする。

2つの MIME オブジェクトは、次の仕様とされる。

Content-Type: application/timestamp-query

<<ASN.1 DERエンコードされたタイムスタンプリクエストメッセージ>>

Content-Type: application/timestamp-reply

<<ASN.1 DERエンコードされたタイムスタンプリクエストメッセージ>>

これらの MIME オブジェクトは、通常の HTTP 処理エンジンを使って WWW リンク上で送受信することができ、タイムスタンプ メッセージについてシンプルなブラウザとサーバー間配送を提供する。

正規のリクエストを受けたとき、サーバーは、content type として application/timestamp-reply(訳注: 原文の application/timestamp-response は、誤り)をもった有効なレスポンス、または、HTTP エラーで応答しなければならない(MUST)

 

4. セキュリティについての考慮事項 English

本書全体が、セキュリティについての考慮事項に関するものある。TSA サービスを設計するとき、次の考慮事項がタイムスタンプ トークンにおける有効性もしくは 「信頼(trust)」に影響があると識別されている。

  1. ある TSA がもはや使われないが、その TSA 私有鍵が確かなものでなくされたとき、その TSA の証明書は、失効されるものとする(SHALL)。TSA からの失効された証明書に関連する reasonCode 拡張が CRL entry 拡張にあるとき、unspecified (0), affiliationChanged (3), superseded (4) か、あるいは、 cessationOfOperation (5) のいずれかに設定されるものとする(SHALL)。その場合、いかなる将来の時刻においても、対応する鍵で署名されたトークンは、無効であると考えられるが、失効時刻以前に生成されたトークンは、有効なままとなる。TSA からの失効された証明書に関連する reasonCode 拡張が CRL entry 拡張中に無いとき、その対応する鍵によって署名されたすべてのトークンは、無効であるとみなされるものとする(SHALL)。この理由により、reasonCode 拡張を使うことが推奨される。
     
  2. TSA 私有鍵が確かのものでなくされたとき、対応する証明書は、失効されるものとする(SHALL)。その場合、TSA からの失効された証明書に関するreasonCode 拡張は、CRL 項目拡張の中にある可能性がありますが、無い可能性もあります。これがあるとき、これは、鍵 Compromise (1) に設定されるものとする(SHALL)。その私有鍵を使って TSA によって署名された、いかなるトークンは、もはや信頼できない。この理由により、TSA の私有鍵が確かなものでなくなる可能性を最小化するために、正しいセキュリティとコントロールによって護られていることは、命令に近い。私有鍵が確かなものでなくされた場合、TSA によって生成されたすべてのトークンの監査証跡は、過去日付のトークンの真偽を区別する手段を提供することができる(MAY)。異なる 2つの TSA からの 2つのタイムスタンプ トークンは、この論点に対応するための別のやり方である。
     
  3. TSA の署名鍵は十分に長い期間生存することが可能なように十分な長さを持っていなければならない(MUST)。しかし、鍵の生存期間は、十分に長くしても有限である。それゆえ、TSA によって署名されたいかなるトークンも、後日 TSA の署名によって存在する信頼を更新するために、(古いCRL の信頼すべきコピーが利用可能ならば)再度タイムスタンプされる必要があり(SHOULD)、あるいは、 (そのような CRL が存在しない場合)公証される必要がある (SHOULD)。また、タイムスタンプトークンは、この信頼を保持するために証拠保管局で保存しておくことも可能である。
     
  4. nonce のみを使い、ローカルな時計を使わないクライアント アプリケーションは、レスポンスを待つ用意のある時間について考慮される必要がある(SHOULD)。「中間者による攻撃(man-in-the-middle' attack)」は、遅延をもたらすことができる。それゆえ、許容可能時間以上かかる、いかなる TimeStampResp も、疑わしいと考える必要がある(SHOULD)。本書において規定されたそれぞれの転送方法は異なる遅延特性を持っているので、受け入れ可能と考えられる時間は、他の環境要因だけでなく使用する特定の転送方法に依存する。
     
  5. 異なるエンティティが同じハッシュアルゴリズムを用いて同一のデータオブジェクトのタイムスタンプトークンを取得する場合、あるいは、一つのエンティティが同一のオブジェクトの複数のタイムスタンプを取得する場合、生成されたタイムスタンプトークンは同一のメッセージインプリントを含むことになる。; その結果、これらのタイムスタンプトークンにアクセスできる観察者は複数のタイムスタンプが同じ元となるデータを参照していることを推定できる。
     
  6. 同じハッシュアルゴリズムと値を結合したリクエストの、不慮のあるいは故意のリプレイが、起きる可能性がある。不慮のリプレイは、介在するネットワーク要素の問題により、同じリクエストメッセージのコピーが一回以上 TSA に送信される場合に発生する。故意のリプレイは、中間者が正当な TSA レスポンスをリプレイする場合に発生する。これらの状況を検知するためにいくつかのテクニックが利用可能である。nonce を使用することによって、常にリプレイを検知できるようになる。それゆえ、nonce の使用が推奨される(RECOMMENDED)。もうひとつの可能性として、ローカルクロックとリクエスト側がタイムウィンドウ内に送信する全てのハッシュを覚えている時間間隔である移動するタイムウィンドウを併用することである。レスポンスを受信した場合、リクエスタはレスポンスが期間内にあったかという事と、そのタイムウィンドウにそのハッシュ値が一回のみしか発生しなかったことの両方を確認する。同じハッシュ値がひとつのタイムウィンドウ中に一回以上存在する場合、リクエスタは、nonce を使うか、その期間中に 1度だけしか同じハッシュ値が出現しなくなるように期間を移動するまで待つのである。

 

5. 知的財産権 English

IETF は、本書に記述された技術に対し実装や利用において関係があると主張される可能性があるいかなる知的所有権やその他の権利に対する有効性や範囲、もしくは、そのような権利の元に置かれている任意のライセンスが利用可能であるかどうかという範囲を注視する立場をとらない;また、そのような任意の権利を特定する努力を行ったという表明もしない。スタンダードトラックおよび標準に関係するドキュメントにおける権利に対して取り組んでいる IETF の手続きに関する情報は、BCP-11 にある。出版において利用可能な権利の主張のコピーや利用可能なライセンスのどのような保証、あるいは、一般的なライセンスの取得を試みようとした結果、もしくは、本標準の実装者やユーザによるこのような所有権の使用権は、IETF事務局より取得できる。

IETF は、あらゆる関心ある主体が、いかなる著作権、特許/特許の応用、もしくは、この標準を実装するために要求される可能性がある技術に該当する 他の財産権 について注目するようにする。その情報を IETF のエグゼクティブ ディレクター宛に送っていただきたい。

次の 8つのタイムスタンピングに関する米国特許 (日付順)は、現時点において著者が知っているものである。これは、網羅的なリストではない可能性がある。他の特許が存在している可能性、または、いつでも発行される可能性がある(MAY)。このリストは、情報の目的で提供されている;現在のところ IETF は、本書に含まれているいかなる仕様に対しても主張を受けた知的所有権は知らされていない。この状況が変化した場合、現状は主張を受けた権利のオンラインのリストにある可能性がある。(知的所有権告知の IETF のホームページ。)

このプロトコルの実装者は、自身で特許検索を行い、かれらの実装において何らかの問題があるか否かを判断する必要がある(SHOULD)

このプロトコルのユーザは、自身で特許検索を行い、この標準の利用において何らかの問題があるか否かを判断する必要がある(SHOULD)

# 5,001,752 Public/Key Date-Time Notary Facility 
Filing date: October 13, 1989 
Issued: March 19, 1991 
Inventor: Addison M. Fischer

# 5,022,080 Electronic Notary 
Filing date: April 16, 1989 
Issued: June 4, 1991 
Inventors: Robert T. Durst, Kevin D. Hunter

# 5,136,643 Public/Key Date-Time Notary Facility 
Filing date: December 20, 1990 
Issued: August 4, 1992 
Inventor: Addison M. Fischer 
Note: This is a continuation of patent # 5,001,752.)

# 5,136,646 Digital Document Time-Stamping with Catenate Certificate 
Filing date: August 2, 1990 
Issued: August 4, 1992 
Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr. 
(assignee) Bell Communications Research, Inc.,

# 5,136,647 Method for Secure Time-Stamping of Digital Documents 
Filing date: August 2, 1990 
Issued: August 4, 1992 
Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr. 
(assignee) Bell Communications Research, Inc.,

# 5,373,561 Method of Extending the Validity of a Cryptographic Certificate 
Filing date: December 21, 1992 
Issued: December 13, 1994 
Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr. 
(assignee) Bell Communications Research, Inc.,

# 5,422,953 Personal Date/Time Notary Device 
Filing date: May 5, 1993 
Issued: June 6, 1995 
Inventor: Addison M. Fischer

# 5,781,629 Digital Document Authentication System 
Filing date: February 21, 1997 
Issued: July 14, 1998 
Inventor: Stuart A. Haber, Wakefield S. Stornetta Jr. 
(assignee) Surety Technologies, Inc.,

 

6. 参考文献

[RFC2119] Bradner, S.,
「RFC において要請の程度を示すために用いるキーワード(Key words for use in RFCs to Indicate Requirement Levels)」,
BCP 14
, RFC 2119, 1997年 3月.
 
[RFC2246] Dierks, T. and C. Allen,
「TLS プロトコル v1.0 (The TLS Protocol, Version 1.0)」,
RFC 2246, 1999年 1月.
 
[RFC2510] Adams, C. and S. Farrell,
「インターネット X.509 インフラストラクチャ証明書管理プロトコル(Internet X.509 Public Key Infrastructure, Certificate Management Protocols)」,
RFC 2510, 1999年 3月.
 
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo,
「インターネットX.509公開鍵インフラストラクチャ(Internet X.509 Public Key Infrastructure, Certificate and CRL Profile)」,
RFC 2459, 1999年 1月.
 
[CMS] Housley, R.,
"Cryptographic Message Syntax",
RFC 2630(English), 1999年 7月.
 
[DSS] Digital Signature Standard.
FIPS Pub 186. National Institute of Standards and Technology. 1994年 5月19日.
 
[ESS] Hoffman, P.,
"Enhanced Security Services for S/MIME",
RFC 2634(English), 1999年 7月.
 
[ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems. Non-Repudiation Framework. 1997年 4月.
 
[MD5] Rivest, R.,
「MD5 メッセージダイジェストアルゴリズム (The MD5 Message-Digest Algorithm)」,
RFC 1321, 1992年 4月.
 
[SHA1] Secure Hash Standard. FIPS Pub 180-1. National Institute of Standards and Technology. 1995年 4月17日.

 

7. 著者のアドレス

Carlisle Adams 
Entrust, Inc. 
1000 Innovation Drive 
Ottawa, Ontario 
K2K 3E7 
CANADA

EMail: cadams@entrust.com

Pat Cain 
BBN 
70 Fawcett Street 
Cambridge, MA 02138 
U.S.A.

EMail: pcain@bbn.com

Denis Pinkas 
Integris 
68 route de Versailles 
B.P. 434 
78430 Louveciennes 
FRANCE

EMail: Denis.Pinkas@bull.net

Robert Zuccherato 
Entrust, Inc. 
1000 Innovation Drive 
Ottawa, Ontario 
K2K 3E7 
CANADA

EMail: robert.zuccherato@entrust.com

翻訳者のアドレス

宮川 寧夫
独立行政法人 情報処理推進機構
セキュリティセンター

EMail: miyakawa@ipa.go.jp

漆島 賢二
セコム株式会社 IS 研究所

EMail: k-urushima@secom.co.jp

 


付録 A: CMS を使った Signature Time-stamp 属性 English

タイムスタンピングの主要な利用法のひとつは、デジタル署名が一定時刻より前に作成されたことを証明するために デジタル署名に タイムスタンプすることである。対応する公開鍵証明書が失効した場合、 このことは、検証者に署名が失効日の前/後に作成されたか否かを知ることを許容する。

タイムスタンプを格納するにふさわしい場所は、[CMS] 構造体中の unsigned 属性としてである。

この付録は、デジタル署名にタイムスタンプするために使うことができる署名タイムスタンプ属性を規定する。

次のオブジェクト識別子は、署名タイムスタンプ属性を識別する。:

id-aa-timeStampToken OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 14 }

署名タイムスタンプ属性値は、ASN.1 type SignatureTimeStampToken をもつ。:

SignatureTimeStampToken ::= TimeStampToken

TimeStampToken にある messageImprint フィールドの値は、タイムスタンプされる signedData についての SignerInfo 中の署名フィールドの値のハッシュとなる。

 


付録 B: 特定時刻における署名 English

我々は、この一般的なタイムスタンピング サービスの可能性ある利用法の例を提供する。これは、特定時刻に署名をし、この時から、適切な証明書 status 情報 (例: CRL)が、チェックされなければならない(MUST)。 このアプリケーションは、デジタル署名メカニズムを使って生成された証拠と組み合わせて使われることが意図されている。

否認防止のポリシーに従って、署名を検証することができる。このポリシーは明示的であることも暗黙的である(すなわち、署名者により提供される証拠中に示される)可能性がある(MAY)。他の方法も含めて、否認防止ポリシーにより署名者がデジタル署名の生成のために使われた署名鍵の危殆化を宣言することができる。従って、署名は、この期間の終わりまで有効であることを保証できない可能性がある。

デジタル署名を検証するために、以下の基本的テクニックが使われる可能性がある。:

A) 署名が生成された後すぐに(例えば、数分あるいは数時間のうちに)タイムスタンプを行う情報を取得しなければならない。

1) 署名は、TSA に提供される。 TSA は、次に、その署名上に TST(TimeStampToken)を返す。

2) サービスの利用者はTimeStampTokenが正しいかどうか検証しなければならない(MUST)

B) デジタル署名の有効性は、次に以下のやり方で検証される。:

1) タイムスタンプ トークン自体は、検証されなければならない(MUST)し、これは、署名者の署名 に適用されることを検証されなければならない(MUST)

2) TimeStampToken 中の TSA によって示された日付/時刻は、取得されなければならない(MUST)

3) 署名者によって使われた証明書は、識別され、取得されなければならない(MUST)

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

5) タイムスタンピング操作の日付/時刻におけるその証明書についての失効情報は、取得されなければならない(MUST)

6) 証明書が失効された場合、失効日付/時刻は、TSA によって示された日付/時刻よりも大きくなる。

これらの条件すべてが成功する場合、デジタル署名は、有効として宣言される。

 


付録 C: 1988年版 シンタックスを使う ASN.1 モジュール English

PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)}

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

-- EXPORTS ALL --

IMPORTS

Extensions, AlgorithmIdentifier FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)}

GeneralName FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)}

ContentInfo FROM CryptographicMessageSyntax {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)}

PKIFreeText FROM PKIXCMP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cmp(9)} ;

-- Locally defined OIDs --

--  タイムスタンプ トークンについての eContentType

id-ct-TSTInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}

-- 2.4.1

TimeStampReq ::= SEQUENCE { 

version INTEGER { v1(1) }, 
messageImprint MessageImprint, 
-- タイムスタンプを付与されるデータのハッシュアルゴリズム OID およびデータのハッシュ値
reqPolicy TSAPolicyId OPTIONAL,
nonce INTEGER OPTIONAL,
certReq BOOLEAN DEFAULT FALSE,
extensions [0] IMPLICIT Extensions OPTIONAL }

MessageImprint ::= SEQUENCE { 

hashAlgorithm AlgorithmIdentifier, 
hashedMessage OCTET STRING }

TSAPolicyId ::= OBJECT IDENTIFIER

-- 2.4.2

TimeStampResp ::= SEQUENCE { 

status PKIStatusInfo, 
timeStampToken TimeStampToken OPTIONAL }

-- status は、[RFC2510] の3.2.3節におけるstatusの定義に基づく

PKIStatusInfo ::= SEQUENCE { 

status PKIStatus, 
statusString PKIFreeText OPTIONAL, 
failInfo PKIFailureInfo OPTIONAL }

PKIStatus ::= INTEGER { 

granted (0), 
-- PKIStatus が値 0 を含む場合、要求された通り TimeStampToken が存在しなければならない。
grantedWithMods (1), 
-- PKIStatusが値1を含む場合、変更を伴う TimeStampToken が存在しなければならない。
rejection (2), 
waiting (3), 
revocationWarning (4), 
-- このメッセージは失効が逼迫しているという警告を含むことを示す。
revocationNotification (5) 
-- 失効が発生したという通知。 }

-- TimeStampToken が存在しない場合、failInfo は、タイムスタンプリクエストが棄却された理由を示し、次の値のうちのひとつとなる。

PKIFailureInfo ::= BIT STRING { 

badAlg (0), 
-- 解釈されない、あるいは、サポートされていないアルゴリズム識別子である。
badRequest (2), 
-- トランザクションが許可されていないか、サポートされていない。
badDataFormat (5), 
-- 送信されたデータのフォーマットに誤りがある。
timeNotAvailable (14), 
-- TSA の時刻源が利用できない。
unacceptedPolicy (15), 
-- 要求された TSA ポリシーが TSA によってサポートされていない。
unacceptedExtension (16), 
-- 要求された拡張はTSAによりサポートされていない。
addInfoNotAvailable (17) 
-- 要求された追加情報が解釈できないか、利用不可である。
systemFailure (25) 
-- システム障害によりリクエストが処理できなかった。 }

TimeStampToken ::= ContentInfo

-- contentType は、[CMS] で定義されている id-signedData である。
-- content は、[CMS] で定義されている SignedData である。
-- SignedData 中の eContentType は、id-ct-TSTInfo である。
-- SignedData 中の eContentは、TSTInfo である。

TSTInfo ::= SEQUENCE { 

version INTEGER { v1(1) }, 
policy TSAPolicyId, 
messageImprint MessageImprint, 
-- TimeStampReq の同じフィールドの値と同じ値を持たなければならない(MUST)
serialNumber INTEGER, 
-- タイムスタンプユーザは、160 ビットまでの整数に適応する準備をしておかなければならない(MUST)
genTime GeneralizedTime, 
accuracy Accuracy OPTIONAL, 
ordering BOOLEAN DEFAULT FALSE, 
nonce INTEGER OPTIONAL, 
-- TimeStampReq に同じフィールドがあった場合、同じ値でなければならない(MUST)
tsa [0] GeneralName OPTIONAL, 
extensions [1] IMPLICIT Extensions OPTIONAL }

Accuracy ::= SEQUENCE { 

seconds INTEGER OPTIONAL, 
millis [0] INTEGER (1..999) OPTIONAL, 
micros [1] INTEGER (1..999) OPTIONAL }

END

 


付録 D: タイムスタンピングについてのアクセス記述子 English

[本付録においては、「RFC 2459 の後継」で定義されている SIA 拡張に基づく拡張について述べる。本書の配布時に「RFC 2459 の後継」は、まだ利用可能でないため、この記述は付録情報として置くこととした。この付録のコンテンツは将来的には RFC 2459 の後継に含められるようになるであろう。そのようになれば、この付録も不要となる。本書の将来のバージョンは、おそらくこの付録を省略し、RFC 2459の後継を直接参照するようになるであろう。(訳注: 「RFC 2459 の後継」とは、現在、RFC 5280 を指す。)]

TSA の証明書は、TSA にアクセスする方法を伝えるために SIA(Subject Information Access)拡張(RFC 2459 の後継)を含む可能性がある(MAY)。本拡張の accessMethod フィールドは、id-ad-timestamping の OID を含まなければならない(MUST)。:

次のオブジェクト識別子は、タイムスタンピングについてのアクセス記述子を識別する。

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

identified-organization(3) dod(6) 
internet(1) security(5) mechanisms(5) pkix(7) 
ad (48) timestamping (3)}

accessLocation フィールドの値は、TSA にアクセスするために使われる transport (例: HTTP) を規定し、他の transport に依存する情報を含む可能性がある。(例: URL)

 


著作権表記全文

Copyright (C) The Internet Society (2001). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the 情報 contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

謝辞

現在、RFCエディターのための資金は、インターネットソサエティーによって提供されている。