|
ネットワーク WG Request for Comments： 3161 分類： スタンダードトラック |
C. Adams Entrust P. Cain BBN D. Pinkas Integris R. Zuccherato Entrust 2001年8月 |
本書は、 インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、 それを改良するための議論や提言を求めるものである。 このプロトコルの標準化状態およびステータスについては、 「Internet Official Protocol Standards」(STD 1)の最新版を参照すること。 このメモの配布に制限は無い。
Copyright (C) The Internet Society (2001). All Rights Reserved.
本書は、TSA (Time Stamping Authority：タイムスタンプ局)に送られるリクエストと、 それに返されるレスポンスのフォーマットを記述する。 本書は、TSAの運用について、 レスポンスを生成するためにリクエストを処理することに関するいくつかのセキュリティ関連要件も確立する。
タイムスタンピングサービスは、 あるデータが特定の時刻前に存在したことを証明する言明を支援する。 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のサービスを利用することが期待される。
TSAは、データが特定時刻において存在したことを示すために、 タイムスタンプトークンを作成するTTP(信頼できる第三者)である。
本書において以降、"valid request"は、正しくデコードできるものであり、 2.4 節において規定した形態のものであり、 サポートされたTSA登録者(subscriber)から送信されたものを意味するものとする。
TSAには、次の事項が要求される(REQUIRED)。：
このメカニズムの最初のメッセージとして、要求主体は、 リクエストを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)。
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)}
タイムスタンピングのリクエストは、次のとおり。：
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回のみ生成された可能性が高い大きな乱数である。 (例：64bit数値。) そのような場合、 同一の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]。)
タイムスタンピングレスポンスは、次のとおり。：
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] において規定されている。
特定の拡張フィールドタイプは、標準において仕様とされる可能性、あるいは、 あらゆる組織体もしくはコミュニティによって規定・登録される可能性がある。
TSAメッセージ用に必須のトランスポートメカニズムは、本書中に無い。 次に述べるメカニズムは、オプションとしてのものである。； 追加的なオプションとしてのメカニズムは、将来、規定される可能性がある。
この節は、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文字のファイル名は、いかなる別個の名前であることができる。
タイムスタンプメッセージを含むファイルは、 TSAメッセージのDER encodingのみを含まなければならない(MUST)。 すなわち、ファイル中に、 無関係のヘッダーや付随情報があってはならない(MUST)。 そのようなファイルは、タイムスタンプメッセージを、 例えばFTPを使って配送するために使うことができる。
タイムスタンプリクエストは、 (タイムスタンプQueryのように) ファイル拡張子.tsq のファイル中に含まれる必要がある(SHOULD)。 タイムスタンプレスポンスは、 (タイムスタンプReplyのように)ファイル拡張子.tsrのファイル中に含まれる必要がある(SHOULD)。
次のシンプルな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 人が読解可能なエラーメッセージ
-- エラーが検知された場合に生成される。(例えば、存在しないか終了したポーリングリファレンスを受信した場合等。)
起こりうるメッセージの順序は、次のとおり。：
"time-to-check-back"パラメータは、unsigned 32ビットの数値である。 これは、秒単位の時刻であり、クライアントがstatusを再度、 チェックする必要がある(SHOULD)最小限の間隔を示す。
これは、 エンドエンティティがその次のpollReqを送る必要がある時刻の見積もりを提供する。
この節は、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)。
本書全体が、セキュリティについての考慮事項に関するものある。 TSAサービスを設計するとき、 次の考慮事項がタイムスタンプトークンにおける有効性もしくは「信頼(trust)」に影響があると識別されている。
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.,
| [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日. |
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
タイムスタンピングの主要な利用法のひとつは、 デジタル署名が一定時刻より前に作成されたことを証明するためにデジタル署名にタイムスタンプすることである。 対応する公開鍵証明書が失効した場合、 このことは、 検証者に署名が失効日の前／後に作成されたか否かを知ることを許容する。
タイムスタンプを格納するにふさわしい場所は、 [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中の署名フィールドの値のハッシュとなる。
我々は、 この一般的なタイムスタンピングサービスの可能性ある利用法の例を提供する。 これは、特定時刻に署名をし、この時から、 適切な証明書status情報(例：CRL)が、 チェックされなければならない(MUST)。 このアプリケーションは、 デジタル署名メカニズムを使って生成された証拠と組み合わせて使われることが意図されている。
否認防止のポリシーに従って、署名を検証することができる。 このポリシーは明示的であることも暗黙的である(すなわち、 署名者により提供される証拠中に示される)可能性がある(MAY)。 他の方法も含めて、 否認防止ポリシーにより署名者がデジタル署名の生成のために使われた署名鍵の危殆化を宣言することができる。 従って、署名は、 この期間の終わりまで有効であることを保証できない可能性がある。
デジタル署名を検証するために、 以下の基本的テクニックが使われる可能性がある。：
これらの条件すべてが成功する場合、デジタル署名は、 有効として宣言される。
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
[本付録においては、 「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エディターのための資金は、 インターネットソサエティーによって提供されている。