[要約] RFC 3161は、インターネット X.509 パブリックキーインフラストラクチャの一部として、タイムスタンププロトコル（TSP）を定義しています。このプロトコルの主な目的は、デジタルデータが特定の時点で存在していたことを証明するための手段を提供することです。これは、デジタル署名の有効性を長期にわたって検証するためや、文書の改ざん検出などに利用されます。関連するRFCには、RFC 5280（X.509証明書とCRLのプロファイル）、RFC 5652（暗号化メッセージ構文）、RFC 5912（X.509証明書のASN.1モジュール）などがあります。
Network Working Group C. Adams
Request for Comments: 3161 Entrust
Category: Standards Track P. Cain
BBN
D. Pinkas
Integris
R. Zuccherato
Entrust
August 2001
Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)
インターネットX.509公開鍵インフラストラクチャタイムスタンププロトコル（TSP）
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（C）The Internet Society（2001）。全著作権所有。
Abstract
概要
This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses.
このドキュメントでは、タイムスタンピング機関（TSA）に送信される要求と返される応答の形式について説明します。また、要求を処理して応答を生成することに関して、TSA操作のいくつかのセキュリティ関連の要件を確立します。
A time-stamping service supports assertions of proof that a datum existed before a particular time. A TSA may be operated as a Trusted Third Party (TTP) service, though other operational models may be appropriate, e.g., an organization might require a TSA for internal time-stamping purposes.
タイムスタンプサービスは、データが特定の時間より前に存在したという証明のアサーションをサポートします。 TSAはTrusted Third Party（TTP）サービスとして運用できますが、他の運用モデルが適切な場合もあります。たとえば、組織は内部のタイムスタンプの目的でTSAを必要とする場合があります。
Non-repudiation services [ISONR] require the ability to establish the existence of data before specified times. This protocol may be used as a building block to support such services. An example of how to prove that a digital signature was generated during the validity period of a public key certificate is given in an annex.
否認防止サービス[ISONR]には、指定された時間の前にデータの存在を確立する機能が必要です。このプロトコルは、このようなサービスをサポートするためのビルディングブロックとして使用できます。公開鍵証明書の有効期間中にデジタル署名が生成されたことを証明する方法の例は、付録に記載されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "SHALL", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHOULD」、「SHOULD NOT」、「SHALL」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、大文字で示されています。 ）は、[RFC2119]で説明されているように解釈されます。
In order to associate a datum with a particular point in time, a Time Stamp Authority (TSA) may need to be used. This Trusted Third Party provides a "proof-of-existence" for this particular datum at an instant in time.
データを特定の時点に関連付けるために、Time Stamp Authority（TSA）を使用する必要がある場合があります。この信頼できるサードパーティは、この特定のデータに「存在証明」を瞬時に提供します。
The TSA's role is to time-stamp a datum to establish evidence indicating that a datum existed before a particular time. This can then be used, for example, to verify that a digital signature was applied to a message before the corresponding certificate was revoked thus allowing a revoked public key certificate to be used for verifying signatures created prior to the time of revocation. This is an important public key infrastructure operation. The TSA can also be used to indicate the time of submission when a deadline is critical, or to indicate the time of transaction for entries in a log. An exhaustive list of possible uses of a TSA is beyond the scope of this document.
TSAの役割は、データにタイムスタンプを付けて、特定の時間より前にデータが存在したことを示す証拠を確立することです。これは、たとえば、対応する証明書が取り消される前にデジタル署名がメッセージに適用されたことを確認するために使用できるため、取り消される前に作成された署名を確認するために、取り消された公開鍵証明書を使用できます。これは重要な公開鍵インフラストラクチャの運用です。 TSAは、締め切りが重要な場合の提出時間を示すため、またはログのエントリのトランザクション時間を示すためにも使用できます。 TSAの可能な使用の完全なリストは、このドキュメントの範囲を超えています。
This standard does not establish overall security requirements for TSA operation, just like other PKIX standards do not establish such requirements for CA operation. Rather, it is anticipated that a TSA will make known to prospective clients the policies it implements to ensure accurate time-stamp generation, and clients will make use of the services of a TSA only if they are satisfied that these policies meet their needs.
他のPKIX標準がCA操作のそのような要件を確立しないのと同じように、この標準はTSA操作の全体的なセキュリティ要件を確立しません。むしろ、TSAが将来のクライアントに、正確なタイムスタンプの生成を確実にするために実装するポリシーを知らせることが予想され、クライアントは、これらのポリシーがニーズを満たしていると満足した場合にのみ、TSAのサービスを利用します。
The TSA is a TTP that creates time-stamp tokens in order to indicate that a datum existed at a particular point in time.
TSAは、特定の時点でデータが存在したことを示すためにタイムスタンプトークンを作成するTTPです。
For the remainder of this document a "valid request" shall mean one that can be decoded correctly, is of the form specified in Section 2.4, and is from a supported TSA subscriber.
このドキュメントの残りの部分では、「有効なリクエスト」とは、正しくデコードでき、セクション2.4で指定された形式であり、サポートされているTSAサブスクライバーからのものを意味します。
The TSA is REQUIRED:
TSAが必要です：
1. to use a trustworthy source of time.
1. 信頼できる時間の源を使用する。
2. to include a trustworthy time value for each time-stamp token.
2. 各タイムスタンプトークンに信頼できる時間値を含める。
3. to include a unique integer for each newly generated time-stamp token.
3. 新しく生成された各タイムスタンプトークンに一意の整数を含めます。
4. to produce a time-stamp token upon receiving a valid request from the requester, when it is possible.
4. 可能であれば、リクエスタから有効なリクエストを受け取ったときにタイムスタンプトークンを生成します。
5. to include within each time-stamp token an identifier to uniquely indicate the security policy under which the token was created.
5. 各タイムスタンプトークン内に、トークンが作成されたセキュリティポリシーを一意に示す識別子を含めます。
6. to only time-stamp a hash representation of the datum, i.e., a data imprint associated with a one-way collision resistant hash-function uniquely identified by an OID.
6. データのハッシュ表現、つまり、OIDによって一意に識別される一方向の衝突耐性ハッシュ関数に関連付けられたデータインプリントにタイムスタンプを付けるだけです。
7. to examine the OID of the one-way collision resistant hash-function and to verify that the hash value length is consistent with the hash algorithm.
7. 一方向の衝突耐性ハッシュ関数のOIDを調べ、ハッシュ値の長さがハッシュアルゴリズムと一致していることを確認します。
8. not to examine the imprint being time-stamped in any way (other than to check its length, as specified in the previous bullet).
8. （前の箇条書きで指定されたように、その長さをチェックする以外に）タイムスタンプされているインプリントを検査しないこと。
9. not to include any identification of the requesting entity in the time-stamp tokens.
9. タイムスタンプトークンに要求元エンティティのIDを含めないでください。
10. to sign each time-stamp token using a key generated exclusively for this purpose and have this property of the key indicated on the corresponding certificate.
10. この目的のために排他的に生成されたキーを使用して各タイムスタンプトークンに署名し、対応する証明書に示されているキーのこのプロパティを持つ。
11. to include additional information in the time-stamp token, if asked by the requester using the extensions field, only for the extensions that are supported by the TSA. If this is not possible, the TSA SHALL respond with an error message.
11. TSAでサポートされている拡張機能についてのみ、拡張機能フィールドを使用して要求者から要求された場合に、タイムスタンプトークンに追加情報を含める。これが不可能な場合、TSAはエラーメッセージで応答する必要があります（SHALL）。
As the first message of this mechanism, the requesting entity requests a time-stamp token by sending a request (which is or includes a TimeStampReq, as defined below) to the Time Stamping Authority. As the second message, the Time Stamping Authority responds by sending a response (which is or includes a TimeStampResp, as defined below) to the requesting entity.
このメカニズムの最初のメッセージとして、要求元のエンティティは、タイムスタンプ機関に要求（以下に定義されているように、TimeStampReqであるか、またはこれを含む）を送信することにより、タイムスタンプトークンを要求します。 2番目のメッセージとして、タイムスタンピング機関は、応答（以下に定義されているように、TimeStampRespであるか、それを含む）を要求元エンティティに送信することによって応答します。
Upon receiving the response (which is or includes a TimeStampResp that normally contains a TimeStampToken (TST), as defined below), the requesting entity SHALL verify the status error returned in the response and if no error is present it SHALL verify the various fields contained in the TimeStampToken and the validity of the digital signature of the TimeStampToken. In particular, it SHALL verify that what was time-stamped corresponds to what was requested to be time-stamped. The requester SHALL verify that the TimeStampToken contains the correct certificate identifier of the TSA, the correct data imprint and the correct hash algorithm OID. It SHALL then verify the timeliness of the response by verifying either the time included in the response against a local trusted time reference, if one is available, or the value of the nonce (large random number with a high probability that it is generated by the client only once) included in the response against the value included in the request. For more details about replay attack detection, see the security considerations section (item 6). If any of the verifications above fails, the TimeStampToken SHALL be rejected.
応答を受信すると（以下に定義されているように、通常はTimeStampToken（TST）を含むTimeStampRespが含まれる）、要求元のエンティティは、応答で返されたステータスエラーを確認する必要があり（SHALL）、エラーがない場合は、含まれるさまざまなフィールドを確認する必要があります（SHALL）。 TimeStampTokenおよびTimeStampTokenのデジタル署名の有効性。特に、タイムスタンプされたものがタイムスタンプされるように要求されたものに対応することを検証する必要があります。要求者は、TimeStampTokenにTSAの正しい証明書識別子、正しいデータインプリント、および正しいハッシュアルゴリズムOIDが含まれていることを確認する必要があります（SHALL）。次に、応答に含まれている時刻がローカルの信頼できる時刻の参照（利用可能な場合）に照らして検証するか、nonceの値（大きな乱数が高い確率で生成される確率）を検証して、応答の適時性を検証する必要があります（SHALL）。クライアントは1回だけ）要求に含まれている値に対する応答に含まれています。リプレイ攻撃検出の詳細については、セキュリティに関する考慮事項のセクション（アイテム6）を参照してください。上記の検証のいずれかが失敗した場合、TimeStampTokenは拒否されます。
Then, since the TSA's certificate may have been revoked, the status of the certificate SHOULD be checked (e.g., by checking the appropriate CRL) to verify that the certificate is still valid.
次に、TSAの証明書が失効している可能性があるため、証明書のステータスをチェックして（適切なCRLをチェックするなどして）、証明書がまだ有効であることを確認する必要があります（SHOULD）。
Then, the client application SHOULD check the policy field to determine whether or not the policy under which the token was issued is acceptable for the application.
次に、クライアントアプリケーションはポリシーフィールドをチェックして、トークンが発行されたポリシーがアプリケーションで受け入れ可能かどうかを判断する必要があります（SHOULD）。
The TSA MUST sign each time-stamp message with a key reserved specifically for that purpose. A TSA MAY have distinct private keys, e.g., to accommodate different policies, different algorithms, different private key sizes or to increase the performance. The corresponding certificate MUST contain only one instance of the extended key usage field extension as defined in [RFC2459] Section 4.2.1.13 with KeyPurposeID having value:
TSAは、その目的のために特別に予約されたキーで各タイムスタンプメッセージに署名する必要があります。 TSAは、たとえば、異なるポリシー、異なるアルゴリズム、異なる秘密鍵サイズに対応するため、またはパフォーマンスを向上させるために、別個の秘密鍵を持つ場合があります。対応する証明書は、[RFC2459]セクション4.2.1.13で定義されている拡張キー使用法フィールド拡張の1つのインスタンスのみを含み、KeyPurposeIDには次の値が含まれている必要があります。
id-kp-timeStamping. This extension MUST be critical.
id-kp-timeStamping。この拡張は重要である必要があります。
The following object identifier identifies the KeyPurposeID having value id-kp-timeStamping.
次のオブジェクト識別子は、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)}
A time-stamping request is as follows:
タイムスタンプ要求は次のとおりです。
TimeStampReq ::= SEQUENCE {
version INTEGER { v1(1) },
messageImprint MessageImprint,
--a hash algorithm OID and the hash value of the data to be
--time-stamped reqPolicy TSAPolicyId OPTIONAL, nonce INTEGER OPTIONAL, certReq BOOLEAN DEFAULT FALSE, extensions [0] IMPLICIT Extensions OPTIONAL }
--time-stamped reqPolicy TSAPolicyId OPTIONAL、nonce INTEGER OPTIONAL、certReq BOOLEAN DEFAULT FALSE、extensions [0] IMPLICIT Extensions OPTIONAL}
The version field (currently v1) describes the version of the Time-Stamp request.
バージョンフィールド（現在v1）は、タイムスタンプリクエストのバージョンを示します。
The messageImprint field SHOULD contain the hash of the datum to be time-stamped. The hash is represented as an OCTET STRING. Its length MUST match the length of the hash value for that algorithm (e.g., 20 bytes for SHA-1 or 16 bytes for MD5).
messageImprintフィールドには、タイムスタンプが付けられるデータのハッシュが含まれる必要があります（SHOULD）。ハッシュはOCTET STRINGとして表されます。その長さは、そのアルゴリズムのハッシュ値の長さと一致する必要があります（たとえば、SHA-1の場合は20バイト、MD5の場合は16バイト）。
MessageImprint ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashedMessage OCTET STRING }
The hash algorithm indicated in the hashAlgorithm field SHOULD be a known hash algorithm (one-way and collision resistant). That means that it SHOULD be one-way and collision resistant. The Time Stamp Authority SHOULD check whether or not the given hash algorithm is known to be "sufficient" (based on the current state of knowledge in cryptanalysis and the current state of the art in computational resources, for example). If the TSA does not recognize the hash algorithm or knows that the hash algorithm is weak (a decision left to the discretion of each individual TSA), then the TSA SHOULD refuse to provide the time-stamp token by returning a pkiStatusInfo of 'bad_alg'.
hashAlgorithmフィールドに示されているハッシュアルゴリズムは、既知のハッシュアルゴリズム（一方向かつ衝突耐性）である必要があります（SHOULD）。これは、一方向で衝突耐性があるべきであることを意味します。タイムスタンプ機関は、指定されたハッシュアルゴリズムが「十分」であることがわかっているかどうかを確認する必要があります（たとえば、暗号解読における現在の知識と計算リソースにおける現在の技術に基づく）。 TSAがハッシュアルゴリズムを認識しないか、ハッシュアルゴリズムが弱いことがわかっている場合（個々のTSAの裁量に委ねられた決定）、TSAは 'bad_alg'のpkiStatusInfoを返すことにより、タイムスタンプトークンの提供を拒否する必要があります（SHOULD）。 。
The reqPolicy field, if included, indicates the TSA policy under which the TimeStampToken SHOULD be provided. TSAPolicyId is defined as follows:
reqPolicyフィールドが含まれている場合は、TimeStampTokenを提供する必要があるTSAポリシーを示します。 TSAPolicyIdは次のように定義されています。
TSAPolicyId ::= OBJECT IDENTIFIER
The nonce, if included, allows the client to verify the timeliness of the response when no local clock is available. The nonce is a large random number with a high probability that the client generates it only once (e.g., a 64 bit integer). In such a case the same nonce value MUST be included in the response, otherwise the response shall be rejected.
nonceが含まれている場合、ローカルクロックが利用できないときに、クライアントは応答の適時性を検証できます。 nonceは、クライアントが一度だけ生成する可能性が高い大きな乱数です（64ビット整数など）。そのような場合、同じノンス値が応答に含まれなければなりません（MUST）。そうでない場合、応答は拒否されます。
If the certReq field is present and set to true, the TSA's public key certificate that is referenced by the ESSCertID identifier inside a SigningCertificate attribute in the response MUST be provided by the TSA in the certificates field from the SignedData structure in that response. That field may also contain other certificates.
certReqフィールドが存在し、trueに設定されている場合、応答のSigningCertificate属性内のESSCertID識別子によって参照されるTSAの公開鍵証明書は、その応答のSignedData構造の証明書フィールドのTSAによって提供される必要があります。そのフィールドには、他の証明書が含まれる場合もあります。
If the certReq field is missing or if the certReq field is present and set to false then the certificates field from the SignedData structure MUST not be present in the response.
certReqフィールドが欠落している場合、またはcertReqフィールドが存在し、falseに設定されている場合、SignedData構造の証明書フィールドが応答に存在してはなりません（MUST）。
The extensions field is a generic way to add additional information to the request in the future. Extensions is defined in [RFC 2459]. If an extension, whether it is marked critical or not critical, is used by a requester but is not recognized by a time-stamping server, the server SHALL not issue a token and SHALL return a failure (unacceptedExtension).
extensionsフィールドは、将来リクエストに追加情報を追加するための一般的な方法です。拡張機能は[RFC 2459]で定義されています。クリティカルとしてマークされているかどうかに関係なく、リクエスターによって拡張が使用されても、タイムスタンプサーバーによって認識されない場合、サーバーはトークンを発行せず、失敗を返す必要があります（unacceptedExtension）。
The time-stamp request does not identify the requester, as this information is not validated by the TSA (See Section 2.1). In situations where the TSA requires the identity of the requesting entity, alternate identification /authentication means have to be used (e.g., CMS encapsulation [CMS] or TLS authentication [RFC2246]).
この情報はTSAによって検証されないため（セクション2.1を参照）、タイムスタンプ要求は要求者を識別しません。 TSAが要求エンティティのIDを必要とする状況では、代替の識別/認証手段を使用する必要があります（たとえば、CMSカプセル化[CMS]またはTLS認証[RFC2246]）。
A time-stamping response is as follows:
タイムスタンプの応答は次のとおりです。
TimeStampResp ::= SEQUENCE {
status PKIStatusInfo,
timeStampToken TimeStampToken OPTIONAL }
The status is based on the definition of status in section 3.2.3 of [RFC2510] as follows:
ステータスは、[RFC2510]のセクション3.2.3のステータスの定義に基づいています。
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL }
When the status contains the value zero or one, a TimeStampToken MUST be present. When status contains a value other than zero or one, a TimeStampToken MUST NOT be present. One of the following values MUST be contained in status:
ステータスに値0または1が含まれる場合、TimeStampTokenが存在する必要があります。ステータスに0または1以外の値が含まれる場合、TimeStampTokenが存在してはなりません（MUST NOT）。次のいずれかの値がステータスに含まれている必要があります。
PKIStatus ::= INTEGER {
granted (0),
-- when the PKIStatus contains the value zero a TimeStampToken, as
requested, is present.
grantedWithMods (1),
-- when the PKIStatus contains the value one a TimeStampToken,
with modifications, is present.
rejection (2),
waiting (3),
revocationWarning (4),
-- this message contains a warning that a revocation is -- imminent revocationNotification (5) -- notification that a revocation has occurred }
-このメッセージには、失効の警告-差し迫ったrevocationNotification（5）-失効の通知}
Compliant servers SHOULD NOT produce any other values. Compliant clients MUST generate an error if values it does not understand are present.
準拠サーバーは他の値を生成してはいけません。準拠していないクライアントは、理解できない値が存在する場合、エラーを生成する必要があります。
When the TimeStampToken is not present, the failInfo indicates the reason why the time-stamp request was rejected and may be one of the following values.
TimeStampTokenが存在しない場合、failInfoはタイムスタンプ要求が拒否された理由を示し、次のいずれかの値である可能性があります。
PKIFailureInfo ::= BIT STRING {
badAlg (0),
-- unrecognized or unsupported Algorithm Identifier
badRequest (2),
-- transaction not permitted or supported
badDataFormat (5),
-- the data submitted has the wrong format
timeNotAvailable (14),
-- the TSA's time source is not available
unacceptedPolicy (15),
-- the requested TSA policy is not supported by the TSA
unacceptedExtension (16),
-- the requested extension is not supported by the TSA
addInfoNotAvailable (17)
-- the additional information requested could not be understood
-- or is not available
systemFailure (25)
-- the request cannot be handled due to system failure }
These are the only values of PKIFailureInfo that SHALL be supported.
これらは、サポートされる必要があるPKIFailureInfoの唯一の値です。
Compliant servers SHOULD NOT produce any other values. Compliant clients MUST generate an error if values it does not understand are present.
準拠サーバーは他の値を生成してはいけません。準拠していないクライアントは、理解できない値が存在する場合、エラーを生成する必要があります。
The statusString field of PKIStatusInfo MAY be used to include reason text such as "messageImprint field is not correctly formatted".
PKIStatusInfoのstatusStringフィールドを使用して、「messageImprintフィールドが正しくフォーマットされていない」などの理由テキストを含めることができます。
A TimeStampToken is as follows. It is defined as a ContentInfo ([CMS]) and SHALL encapsulate a signed data content type.
TimeStampTokenは次のとおりです。これはContentInfo（[CMS]）として定義され、署名されたデータコンテンツタイプをカプセル化するものとします（SHALL）。
TimeStampToken ::= ContentInfo
-- contentType is id-signedData ([CMS])
-- content is SignedData ([CMS])
The fields of type EncapsulatedContentInfo of the SignedData construct have the following meanings:
SignedDataコンストラクトのEncapsulatedContentInfoタイプのフィールドには、次の意味があります。
eContentType is an object identifier that uniquely specifies the content type. For a time-stamp token it is defined as:
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}
eContent is the content itself, carried as an octet string. The eContent SHALL be the DER-encoded value of TSTInfo.
eContentはコンテンツ自体であり、オクテット文字列として伝送されます。 eContentはTSTInfoのDERエンコード値である必要があります。
The time-stamp token MUST NOT contain any signatures other than the signature of the TSA. The certificate identifier (ESSCertID) of the TSA certificate MUST be included as a signerInfo attribute inside a SigningCertificate attribute.
タイムスタンプトークンには、TSAの署名以外の署名を含めることはできません。 TSA証明書の証明書識別子（ESSCertID）は、SigningCertificate属性内のsignerInfo属性として含まれている必要があります。
TSTInfo ::= SEQUENCE {
version INTEGER { v1(1) },
policy TSAPolicyId,
messageImprint MessageImprint,
-- MUST have the same value as the similar field in
-- TimeStampReq
serialNumber INTEGER,
-- Time-Stamping users MUST be ready to accommodate integers
-- up to 160 bits.
genTime GeneralizedTime,
accuracy Accuracy OPTIONAL,
ordering BOOLEAN DEFAULT FALSE,
nonce INTEGER OPTIONAL,
-- MUST be present if the similar field was present
-- in TimeStampReq. In that case it MUST have the same value.
tsa [0] GeneralName OPTIONAL,
extensions [1] IMPLICIT Extensions OPTIONAL }
The version field (currently v1) describes the version of the time-stamp token.
バージョンフィールド（現在はv1）は、タイムスタンプトークンのバージョンを示します。
Conforming time-stamping servers MUST be able to provide version 1 time-stamp tokens.
適合タイムスタンプサーバーは、バージョン1のタイムスタンプトークンを提供できる必要があります。
Among the optional fields, only the nonce field MUST be supported.
オプションのフィールドのうち、ナンスフィールドのみをサポートする必要があります。
Conforming time-stamping requesters MUST be able to recognize version 1 time-stamp tokens with all the optional fields present, but are not mandated to understand the semantics of any extension, if present.
準拠するタイムスタンプ要求者は、すべてのオプションフィールドが存在するバージョン1のタイムスタンプトークンを認識できなければなりません（MUST）が、存在する場合、拡張機能のセマンティクスを理解することは義務付けられていません。
The policy field MUST indicate the TSA's policy under which the response was produced. If a similar field was present in the TimeStampReq, then it MUST have the same value, otherwise an error (unacceptedPolicy) MUST be returned. This policy MAY include the following types of information (although this list is certainly not exhaustive):
ポリシーフィールドは、応答が生成されたTSAのポリシーを示さなければなりません（MUST）。同様のフィールドがTimeStampReqに存在する場合は、同じ値を持つ必要があります。それ以外の場合は、エラー（unacceptedPolicy）を返す必要があります。このポリシーには、次のタイプの情報を含めることができます（ただし、このリストは完全ではありません）。
* The conditions under which the time-stamp token may be used.
* タイムスタンプトークンを使用できる条件。
* The availability of a time-stamp token log, to allow later verification that a time-stamp token is authentic.
* タイムスタンプトークンが本物であることを後で検証できるようにするためのタイムスタンプトークンログの可用性。
The messageImprint MUST have the same value as the similar field in TimeStampReq, provided that the size of the hash value matches the expected size of the hash algorithm identified in hashAlgorithm.
ハッシュ値のサイズがhashAlgorithmで識別されるハッシュアルゴリズムの予想サイズと一致する場合、messageImprintはTimeStampReqの同様のフィールドと同じ値を持つ必要があります。
The serialNumber field is an integer assigned by the TSA to each TimeStampToken. It MUST be unique for each TimeStampToken issued by a given TSA (i.e., the TSA name and serial number identify a unique TimeStampToken). It should be noticed that the property MUST be preserved even after a possible interruption (e.g., crash) of the service.
serialNumberフィールドは、TSAによって各TimeStampTokenに割り当てられる整数です。これは、特定のTSAによって発行されたTimeStampTokenごとに一意である必要があります（つまり、TSA名とシリアル番号は一意のTimeStampTokenを識別します）。サービスの中断（クラッシュなど）の可能性があっても、プロパティを保持する必要があることに注意してください。
genTime is the time at which the time-stamp token has been created by the TSA. It is expressed as UTC time (Coordinated Universal Time) to reduce confusion with the local time zone use. UTC is a time scale, based on the second (SI), as defined and recommended by the CCIR, and maintained by the Bureau International des Poids et Mesures (BIPM). A synonym is "Zulu" time which is used by the civil aviation and represented by the letter "Z" (phonetically "Zulu").
genTimeは、タイムスタンプトークンがTSAによって作成された時刻です。ローカルタイムゾーンの使用との混乱を減らすために、UTC時間（協定世界時）として表されます。 UTCは、CCIRによって定義および推奨された秒（SI）に基づいたタイムスケールであり、国際事務局インターナショナルデポイズエメシュール（BIPM）によって維持されています。同義語は、民間航空で使用され、文字「Z」（音声では「ズールー」）で表される「ズールー」時間です。
The ASN.1 GeneralizedTime syntax can include fraction-of-second details. Such syntax, without the restrictions from [RFC 2459] Section 4.1.2.5.2, where GeneralizedTime is limited to represent the time with a granularity of one second, may be used here.
ASN.1 GeneralizedTime構文には、秒未満の詳細を含めることができます。このような構文は、[RFC 2459]セクション4.1.2.5.2の制限なしで、GeneralizedTimeが1秒の粒度で時間を表すように制限されているため、ここで使用できます。
GeneralizedTime values MUST include seconds. However, when there is no need to have a precision better than the second, then GeneralizedTime with a precision limited to one second SHOULD be used (as in [RFC 2459]).
GeneralizedTime値には秒を含める必要があります。ただし、秒よりも高い精度が必要ない場合は、精度が1秒に制限されたGeneralizedTimeを使用する必要があります（[RFC 2459]のように）。
The syntax is: YYYYMMDDhhmmss[.s...]Z Example: 19990609001326.34352Z
構文は次のとおりです。YYYYMMDDhhmmss[.s ...] Z例：19990609001326.34352Z
X.690 | ISO/IEC 8825-1 provides the following restrictions for a DER-encoding.
X.690 | ISO / IEC 8825-1は、DERエンコードに対して次の制限を提供します。
The encoding MUST terminate with a "Z" (which means "Zulu" time). The decimal point element, if present, MUST be the point option ".". The fractional-seconds elements, if present, MUST omit all trailing 0's; if the elements correspond to 0, they MUST be wholly omitted, and the decimal point element also MUST be omitted.
エンコーディングは "Z"（ "Zulu"時間を意味する）で終了する必要があります。存在する場合、小数点要素はポイントオプション「。」でなければなりません。小数秒要素が存在する場合は、後続の0をすべて省略しなければなりません。要素が0に対応する場合、それらは完全に省略されなければならず、小数点要素も省略されなければなりません（MUST）。
Midnight (GMT) shall be represented in the form: "YYYYMMDD000000Z" where "YYYYMMDD" represents the day following the midnight in question.
深夜（GMT）は、「YYYYMMDD000000Z」の形式で表されます。「YYYYMMDD」は、問題の深夜の翌日を表します。
Here are a few examples of valid representations:
有効な表現の例をいくつか示します。
"19920521000000Z" "19920622123421Z" "19920722132100.3Z"
19920521000000 g
accuracy represents the time deviation around the UTC time contained in GeneralizedTime.
精度は、GeneralizedTimeに含まれるUTC時間の時間偏差を表します。
Accuracy ::= SEQUENCE {
seconds INTEGER OPTIONAL,
millis [0] INTEGER (1..999) OPTIONAL,
micros [1] INTEGER (1..999) OPTIONAL }
If either seconds, millis or micros is missing, then a value of zero MUST be taken for the missing field.
秒、ミリ、またはマイクロのいずれかが欠落している場合、欠落しているフィールドにはゼロの値を指定する必要があります。
By adding the accuracy value to the GeneralizedTime, an upper limit of the time at which the time-stamp token has been created by the TSA can be obtained. In the same way, by subtracting the accuracy to the GeneralizedTime, a lower limit of the time at which the time-stamp token has been created by the TSA can be obtained.
GeneralizedTimeに精度の値を追加することにより、タイムスタンプトークンがTSAによって作成された時刻の上限を取得できます。同様に、精度をGeneralizedTimeから差し引くことにより、TSAによってタイムスタンプトークンが作成された時刻の下限を取得できます。
accuracy can be decomposed in seconds, milliseconds (between 1-999) and microseconds (1-999), all expressed as integer.
精度は、秒、ミリ秒（1〜999）、マイクロ秒（1〜999）で分解でき、すべて整数で表されます。
When the accuracy optional field is not present, then the accuracy may be available through other means, e.g., the TSAPolicyId.
精度のオプションフィールドが存在しない場合は、TSAPolicyIdなどの他の手段で精度を利用できる場合があります。
If the ordering field is missing, or if the ordering field is present and set to false, then the genTime field only indicates the time at which the time-stamp token has been created by the TSA. In such a case, the ordering of time-stamp tokens issued by the same TSA or different TSAs is only possible when the difference between the genTime of the first time-stamp token and the genTime of the second time-stamp token is greater than the sum of the accuracies of the genTime for each time-stamp token.
順序付けフィールドが欠落している場合、または順序付けフィールドが存在し、falseに設定されている場合、genTimeフィールドは、タイムスタンプトークンがTSAによって作成された時刻のみを示します。このような場合、同じTSAまたは異なるTSAによって発行されたタイムスタンプトークンの順序付けは、最初のタイムスタンプトークンのgenTimeと2番目のタイムスタンプトークンのgenTimeの差が、各タイムスタンプトークンのgenTimeの精度の合計。
If the ordering field is present and set to true, every time-stamp token from the same TSA can always be ordered based on the genTime field, regardless of the genTime accuracy.
順序フィールドが存在し、trueに設定されている場合、genTimeの精度に関係なく、同じTSAからのすべてのタイムスタンプトークンをgenTimeフィールドに基づいて常に順序付けることができます。
The nonce field MUST be present if it was present in the TimeStampReq. In such a case it MUST equal the value provided in the TimeStampReq structure.
nonceフィールドは、TimeStampReqに存在する場合は存在する必要があります。そのような場合、それはTimeStampReq構造で提供される値と等しくなければなりません。
The purpose of the tsa field is to give a hint in identifying the name of the TSA. If present, it MUST correspond to one of the subject names included in the certificate that is to be used to verify the token. However, the actual identification of the entity that signed the response will always occur through the use of the certificate identifier (ESSCertID Attribute) inside a SigningCertificate attribute which is part of the signerInfo (See Section 5 of [ESS]).
tsaフィールドの目的は、TSAの名前を識別する際のヒントを与えることです。存在する場合は、トークンの検証に使用される証明書に含まれるサブジェクト名の1つに対応する必要があります。ただし、応答に署名したエンティティの実際の識別は、signerInfoの一部であるSigningCertificate属性内の証明書識別子（ESSCertID属性）を使用して常に行われます（[ESS]のセクション5を参照）。
extensions is a generic way to add additional information in the future. Extensions is defined in [RFC 2459].
拡張機能は、将来追加情報を追加するための一般的な方法です。拡張機能は[RFC 2459]で定義されています。
Particular extension field types may be specified in standards or may be defined and registered by any organization or community.
特定の拡張フィールドタイプは、標準で指定されるか、任意の組織またはコミュニティによって定義および登録されます。
There is no mandatory transport mechanism for TSA messages in this document. The mechanisms described below are optional; additional optional mechanisms may be defined in the future.
このドキュメントでは、TSAメッセージの必須のトランスポートメカニズムはありません。以下で説明するメカニズムはオプションです。将来、追加のオプションのメカニズムが定義される可能性があります。
This section specifies a means for conveying ASN.1-encoded messages for the protocol exchanges described in Section 2 and Appendix D via Internet mail.
このセクションでは、セクション2と付録Dで説明されているプロトコル交換用のASN.1でエンコードされたメッセージをインターネットメール経由で伝達する方法を指定します。
Two MIME objects are specified as follows:
2つのMIMEオブジェクトは次のように指定されます。
Content-Type: application/timestamp-query
Content-Transfer-Encoding: base64
<<the ASN.1 DER-encoded Time-Stamp message, base64-encoded>>
Content-Type: application/timestamp-reply
Content-Transfer-Encoding: base64
<<the ASN.1 DER-encoded Time-Stamp message, base64-encoded>>
These MIME objects can be respectively sent and received using common MIME processing engines and provides a simple Internet mail transport for Time-Stamp messages.
これらのMIMEオブジェクトは、一般的なMIME処理エンジンを使用してそれぞれ送信および受信でき、タイムスタンプメッセージに簡単なインターネットメールトランスポートを提供します。
For the application/timestamp-query and application/timestamp-reply MIME types, implementations SHOULD include the optional "name" and "filename" parameters. Including a file name helps preserve type information when time-stamp queries and replies are saved as files. When these parameters are included, a file name with the appropriate extension SHOULD be selected:
application / timestamp-queryおよびapplication / timestamp-reply MIMEタイプの場合、実装にはオプションの「name」および「filename」パラメーターを含める必要があります（SHOULD）。ファイル名を含めると、タイムスタンプクエリと返信がファイルとして保存されるときに、タイプ情報を保持するのに役立ちます。これらのパラメーターが含まれている場合、適切な拡張子を持つファイル名を選択する必要があります（SHOULD）。
MIME Type File Extension application/timestamp-query .TSQ application/timestamp-reply .TSR
MIMEタイプファイル拡張子application / timestamp-query .TSQ application / timestamp-reply .TSR
In addition, the file name SHOULD be limited to eight characters followed by a three letter extension. The eight character filename base can be any distinct name.
また、ファイル名は8文字に制限し、その後に3文字の拡張子を付ける必要があります。 8文字のファイル名ベースは、異なる名前にすることができます。
A file containing a time-stamp message MUST contain only the DER encoding of one TSA message, i.e., there MUST be no extraneous header or trailer information in the file. Such files can be used to transport time stamp messages using for example, FTP.
タイムスタンプメッセージを含むファイルには、1つのTSAメッセージのDERエンコードのみが含まれている必要があります。つまり、ファイル内に無関係なヘッダーやトレーラー情報があってはなりません。このようなファイルは、FTPなどを使用してタイムスタンプメッセージを転送するために使用できます。
A Time-Stamp Request SHOULD be contained in a file with file extension .tsq (like Time-Stamp Query). A Time-Stamp Response SHOULD be contained in a file with file extension .tsr (like Time-Stamp Reply).
タイムスタンプリクエストは、ファイル拡張子が.tsqのファイルに含まれる必要があります（タイムスタンプクエリのように）。タイムスタンプ応答は、ファイル拡張子が.tsrのファイルに含める必要があります（タイムスタンプ応答のように）。
The following simple TCP-based protocol is to be used for transport of TSA messages. This protocol is suitable for cases where an entity initiates a transaction and can poll to pick up the results.
TSAメッセージの転送には、次の単純なTCPベースのプロトコルが使用されます。このプロトコルは、エンティティがトランザクションを開始し、ポーリングして結果を取得できる場合に適しています。
The protocol basically assumes a listener process on a TSA that can accept TSA messages on a well-defined port (IP port number 318).
プロトコルは基本的に、明確に定義されたポート（IPポート番号318）でTSAメッセージを受け入れることができるTSAのリスナープロセスを想定しています。
Typically an initiator binds to this port and submits the initial TSA message. The responder replies with a TSA message and/or with a reference number to be used later when polling for the actual TSA message response.
通常、イニシエーターはこのポートにバインドし、初期TSAメッセージを送信します。レスポンダは、TSAメッセージで応答するか、実際のTSAメッセージ応答をポーリングするときに後で使用される参照番号で応答します。
If a number of TSA response messages are to be produced for a given request (say if a receipt must be sent before the actual token can be produced) then a new polling reference is also returned.
特定の要求に対して多数のTSA応答メッセージが生成される場合（たとえば、実際のトークンが生成される前にレシートを送信する必要がある場合）、新しいポーリング参照も返されます。
When the final TSA response message has been picked up by the initiator then no new polling reference is supplied.
最後のTSA応答メッセージがイニシエーターによってピックアップされると、新しいポーリング参照は提供されません。
The initiator of a transaction sends a "direct TCP-based TSA message" to the recipient. The recipient responds with a similar message.
トランザクションの開始者は、「直接TCPベースのTSAメッセージ」を受信者に送信します。受信者は同様のメッセージで応答します。
A "direct TCP-based TSA message" consists of: length (32-bits), flag (8-bits), value (defined below)
「直接TCPベースのTSAメッセージ」は、長さ（32ビット）、フラグ（8ビット）、値（以下で定義）で構成されます。
The length field contains the number of octets of the remainder of the message (i.e., number of octets of "value" plus one). All 32-bit values in this protocol are specified to be in network byte order.
長さフィールドには、メッセージの残りのオクテット数が含まれます（つまり、「値」のオクテット数に1を加えた数）。このプロトコルのすべての32ビット値は、ネットワークバイトオーダーで指定されています。
Message name flag value tsaMsg '00'H DER-encoded TSA message -- TSA message pollRep '01'H polling reference (32 bits), time-to-check-back (32 bits) -- poll response where no TSA message response ready; use polling -- reference value (and estimated time value) for later polling pollReq '02'H polling reference (32 bits) -- request for a TSA message response to initial message negPollRep '03'H '00'H -- no further polling responses (i.e., transaction complete) partialMsgRep '04'H next polling reference (32 bits), time-to-check-back (32 bits), DER-encoded TSA message -- partial response (receipt) to initial message plus new polling -- reference (and estimated time value) to use to get next part of -- response finalMsgRep '05'H DER-encoded TSA message -- final (and possibly sole) response to initial message errorMsgRep '06'H human readable error message -- produced when an error is detected (e.g., a polling reference -- is received which doesn't exist or is finished with)
メッセージ名フラグ値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人間が読めるエラーに対する最後の（そしておそらく唯一の）応答メッセージ-エラーが検出されたときに生成されます（たとえば、ポーリング参照-存在しない、または終了した受信）
The sequence of messages that can occur is:
発生する可能性のあるメッセージのシーケンスは次のとおりです。
a) entity sends tsaMsg and receives one of pollRep, negPollRep, partialMsgRep, or finalMsgRep in response.
a) エンティティはtsaMsgを送信し、応答としてpollRep、negPollRep、partialMsgRep、またはfinalMsgRepのいずれかを受信します。
b) end entity sends pollReq message and receives one of negPollRep, partialMsgRep, finalMsgRep, or errorMsgRep in response.
b) エンドエンティティはpollReqメッセージを送信し、応答としてnegPollRep、partialMsgRep、finalMsgRep、またはerrorMsgRepのいずれかを受信します。
The "time-to-check-back" parameter is an unsigned 32-bit integer. It is the time in seconds indicating the minimum interval after which the client SHOULD check the status again.
「チェックバックまでの時間」パラメーターは、符号なし32ビット整数です。これは、クライアントが再度ステータスをチェックする必要がある最小間隔を示す秒単位の時間です。
It provides an estimate of the time that the end entity should send its next pollReq.
これは、エンドエンティティが次のpollReqを送信する時間の見積もりを提供します。
This subsection specifies a means for conveying ASN.1-encoded messages for the protocol exchanges described in Section 2 and Appendix D via the HyperText Transfer Protocol.
このサブセクションでは、ハイパーテキスト転送プロトコルを介して、セクション2および付録Dで説明されているプロトコル交換のためにASN.1でエンコードされたメッセージを伝達する手段を指定します。
Two MIME objects are specified as follows.
2つのMIMEオブジェクトは次のように指定されます。
Content-Type: application/timestamp-query
Content-Type：application / timestamp-query
<<the ASN.1 DER-encoded Time-Stamp Request message>>
Content-Type: application/timestamp-reply
Content-Type：application / timestamp-reply
<<the ASN.1 DER-encoded Time-Stamp Response message>>
These MIME objects can be sent and received using common HTTP processing engines over WWW links and provides a simple browser-server transport for Time-Stamp messages.
これらのMIMEオブジェクトは、WWWリンクを介して一般的なHTTP処理エンジンを使用して送受信でき、タイムスタンプメッセージ用のシンプルなブラウザーサーバートランスポートを提供します。
Upon receiving a valid request, the server MUST respond with either a valid response with content type application/timestamp-response or with an HTTP error.
有効なリクエストを受信すると、サーバーは、コンテンツタイプapplication / timestamp-responseを使用した有効な応答か、HTTPエラーのいずれかで応答する必要があります。
This entire document concerns security considerations. When designing a TSA service, the following considerations have been identified that have an impact upon the validity or "trust" in the time-stamp token.
このドキュメント全体は、セキュリティの考慮事項に関するものです。 TSAサービスを設計するとき、タイムスタンプトークンの有効性または「信頼」に影響を与える次の考慮事項が確認されています。
1. When a TSA shall not be used anymore, but the TSA private key has not been compromised, the authority's certificate SHALL be revoked. When the reasonCode extension relative to the revoked certificate from the TSA is present in the CRL entry extensions, it SHALL be set either to unspecified (0), affiliationChanged (3), superseded (4) or cessationOfOperation (5). In that case, at any future time, the tokens signed with the corresponding key will be considered as invalid, but tokens generated before the revocation time will remain valid. When the reasonCode extension relative to the revoked certificate from the TSA is not present in the CRL entry extensions, then all the tokens that have been signed with the corresponding key SHALL be considered as invalid. For that reason, it is recommended to use the reasonCode extension.
1. TSAをもう使用しないが、TSA秘密鍵が危険にさらされていない場合、認証局の証明書を取り消す必要があります（SHALL）。 TSAからの失効した証明書に関連するreasonCode拡張がCRLエントリ拡張に存在する場合、それは未指定（0）、affiliationChanged（3）、置き換え（4）、またはcessationOfOperation（5）のいずれかに設定する必要があります。その場合、対応するキーで署名されたトークンは今後無効と見なされますが、失効時間より前に生成されたトークンは引き続き有効です。 TSAから取り消された証明書に関連するreasonCode拡張がCRLエントリ拡張に存在しない場合、対応するキーで署名されたすべてのトークンは無効と見なされるものとします（SHALL）。そのため、reasonCode拡張機能を使用することをお勧めします。
2. When the TSA private key has been compromised, then the corresponding certificate SHALL be revoked. In that case, the reasonCode extension relative to the revoked certificate from the TSA may or may not be present in the CRL entry extensions. When it is present then it SHALL be set to keyCompromise (1). Any token signed by the TSA using that private key cannot be trusted anymore. For this reason, it is imperative that the TSA's private key be guarded with proper security and controls in order to minimize the possibility of compromise. In case the private key does become compromised, an audit trail of all tokens generated by the TSA MAY provide a means to discriminate between genuine and false backdated tokens. Two time-stamp tokens from two different TSAs is another way to address this issue.
2. TSA秘密鍵が危険にさらされた場合、対応する証明書を取り消す必要があります（SHALL）。その場合、TSAからの失効した証明書に関連するreasonCode拡張が、CRLエントリ拡張に存在する場合と存在しない場合があります。存在する場合は、keyCompromise（1）に設定する必要があります。その秘密鍵を使用してTSAによって署名されたトークンは、信頼できなくなります。このため、妥協の可能性を最小限に抑えるために、TSAの秘密鍵を適切なセキュリティと制御で保護することが不可欠です。秘密鍵が危険にさらされた場合、TSAによって生成されたすべてのトークンの監査証跡は、真正なトークンと偽の古いトークンを区別する手段を提供する場合があります。 2つの異なるTSAからの2つのタイムスタンプトークンは、この問題に対処するもう1つの方法です。
3. The TSA signing key MUST be of a sufficient length to allow for a sufficiently long lifetime. Even if this is done, the key will have a finite lifetime. Thus, any token signed by the TSA SHOULD be time-stamped again (if authentic copies of old CRLs are available) or notarized (if they aren't) at a later date to renew the trust that exists in the TSA's signature. time-stamp tokens could also be kept with an Evidence Recording Authority to maintain this trust.
3. TSA署名鍵は、十分に長い寿命を可能にするのに十分な長さでなければなりません。これを行っても、キーの有効期間は有限です。したがって、TSAによって署名されたトークンは、TSAの署名に存在する信頼を更新するために、後日再度タイムスタンプ（古いCRLの本物のコピーが利用可能な場合）または公証（利用できない場合）する必要があります（SHOULD）。タイムスタンプトークンは、この信頼を維持するためにEvidence Recording Authorityで保持することもできます。
4. A client application using only a nonce and no local clock SHOULD be concerned about the amount of time it is willing to wait for a response. A `man-in-the-middle' attack can introduce delays. Thus, any TimeStampResp that takes more than an acceptable period of time SHOULD be considered suspect. Since each transport method specified in this document has different delay characteristics, the period of time that is considered acceptable will depend upon the particular transport method used, as well as other environment factors.
4. nonceのみを使用し、ローカルクロックを使用しないクライアントアプリケーションは、応答を待つ用意があるかどうかを気にする必要があります。 「中間者」攻撃により遅延が発生する可能性があります。したがって、許容可能な期間を超えるTimeStampRespは疑わしいと見なされるべきです。このドキュメントで指定されている各転送方法には異なる遅延特性があるため、許容できると見なされる期間は、使用される特定の転送方法や他の環境要因によって異なります。
5. If different entities obtain time-stamp tokens on the same data object using the same hash algorithm, or a single entity obtains multiple time-stamp tokens on the same object, the generated time-stamp tokens will include identical message imprints; as a result, an observer with access to those time-stamp tokens could infer that the time-stamps may refer to the same underlying data.
5. 異なるエンティティが同じハッシュアルゴリズムを使用して同じデータオブジェクトのタイムスタンプトークンを取得する場合、または単一のエンティティが同じオブジェクトの複数のタイムスタンプトークンを取得する場合、生成されるタイムスタンプトークンには同一のメッセージインプリントが含まれます。その結果、これらのタイムスタンプトークンにアクセスできるオブザーバーは、タイムスタンプが同じ基礎データを参照していると推測できます。
6. Inadvertent or deliberate replays for requests incorporating the same hash algorithm and value may happen. Inadvertent replays occur when more than one copy of the same request message gets sent to the TSA because of problems in the intervening network elements. Deliberate replays occur when a middleman is replaying legitimate TS responses. In order to detect these situations, several techniques may be used. Using a nonce always allows to detect replays, and hence its use is RECOMMENDED. Another possibility is to use both a local clock and a moving time window during which the requester remembers all the hashes sent during that time window. When receiving a response, the requester ensures both that the time of the response is within the time window and that there is only one occurrence of the hash value in that time window. If the same hash value is present more than once within a time window, the requester may either use a nonce, or wait until the time window has moved to come back to the case where the same hash value appears only once during that time window.
6. 同じハッシュアルゴリズムと値を組み込んだリクエストに対して、不注意または意図的なリプレイが発生する可能性があります。介在するネットワーク要素の問題が原因で、同じ要求メッセージの複数のコピーがTSAに送信されると、不注意による再生が発生します。意図的なリプレイは、仲介者が正当なTS応答をリプレイしているときに発生します。これらの状況を検出するために、いくつかの手法を使用できます。 nonceを使用すると、常にリプレイを検出できるため、その使用をお勧めします。別の可能性は、ローカルクロックと移動時間ウィンドウの両方を使用することです。その間、リクエスタはその時間ウィンドウの間に送信されたすべてのハッシュを記憶しています。応答を受信すると、リクエスタは、応答の時間が時間枠内にあることと、その時間枠内にハッシュ値が1つだけ存在することの両方を確認します。同じハッシュ値が時間枠内に2回以上存在する場合、リクエスタはノンスを使用するか、時間枠が移動するまで待機して、同じハッシュ値がその時間枠内に1回だけ出現する場合に戻ることができます。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to per-tain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性のある知的財産またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスの範囲について、いかなる立場も取らない。利用できません。また、そのような権利を特定するために何らかの努力をしたことも表していません。標準化過程および標準化関連文書の権利に関するIETFの手順に関する情報は、BCP-11にあります。公開のために利用可能にされた権利の主張および利用可能にされるライセンスの保証のコピー、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用の許可を得ようとした試みの結果を入手できます。 IETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、この規格を実践するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IETF Executive Directorに情報を送信してください。
The following eight (8) United States Patents related to time stamping, listed in chronological order, are known by the authors to exist at this time. This may not be an exhaustive list. Other patents MAY exist or be issued at any time. This list is provided for informational purposes; to date, the IETF has not been notified of intellectual property rights claimed in regard to any of the specification contained in this document. Should this situation change, the current status may be found at the online list of claimed rights (IETF Page of Intellectual Property Rights Notices).
タイムスタンプに関連する次の8つの米国特許は、年代順にリストされており、現時点では著者によって知られています。これは完全なリストではない場合があります。他の特許が存在するか、いつでも発行される場合があります。このリストは情報提供を目的として提供されています。これまでに、IETFは、このドキュメントに含まれている仕様に関して主張されている知的所有権について通知されていません。この状況が変化した場合、現在のステータスは、主張されている権利のオンラインリスト（知的財産権通知のIETFページ）で確認できます。
Implementers of this protocol SHOULD perform their own patent search and determine whether or not any encumbrances exist on their implementation.
このプロトコルの実装者は、独自の特許検索を実行して、実装に制約が存在するかどうかを判断する必要があります（SHOULD）。
Users of this protocol SHOULD perform their own patent search and determine whether or not any encumbrances exist on the use of this standard.
このプロトコルのユーザーは、独自の特許検索を実行して、この標準の使用に制約が存在するかどうかを判断する必要があります（SHOULD）。
# 5,001,752 Public/Key Date-Time Notary Facility Filing date: October 13, 1989 Issued: March 19, 1991 Inventor: Addison M. Fischer
＃5,001,752 Public / Key Date-Time Notary Facility提出日：1989年10月13日発行：1991年3月19日発明者：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,022,080電子公証書提出日：1989年4月16日発行：1991年6月4日発明者：ロバートT.ダースト、ケビンD.ハンター
# 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,643 Public / Key Date-Time Notary Facility提出日：1990年12月20日発行：1992年8月4日発明者：Addison M. Fischer注：これは特許番号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,646 Catenate証明書を使用したデジタルドキュメントのタイムスタンプ提出日：1990年8月2日発行：1992年8月4日発明者：スチュアートA.ハーバー、ウェイクフィールドS.ストーネットジュニア（譲受人）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,136,647デジタルドキュメントの安全なタイムスタンプの方法提出日：1990年8月2日発行：1992年8月4日発明者：スチュアートA.ハーバー、ウェイクフィールドS.ストーネットジュニア（譲受人）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,373,561暗号証明書の有効期間を延長する方法提出日：1992年12月21日発行：1994年12月13日発明者：スチュアートA.ハーバー、ウェイクフィールドS.ストーネットジュニア（譲受人）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,422,953個人の日付/時刻公証デバイスファイリング日付：1993年5月5日発行：1995年6月6日発明者：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.,
＃5,781,629デジタルドキュメント認証システム提出日：1997年2月21日発行：1998年7月14日発明者：スチュアートA.ハーバー、ウェイクフィールドS.ストーネットジュニア（譲受人）Surety Technologies、Inc.、
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T。およびC. Allen、「The TLS Protocol、Version 1.0」、RFC 2246、1999年1月。
[RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key Infrastructure, Certificate Management Protocols", RFC 2510, March 1999.
[RFC2510] Adams、C。およびS. Farrell、「Internet X.509 Public Key Infrastructure、Certificate Management Protocols」、RFC 2510、1999年3月。
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure, Certificate and CRL Profile", RFC 2459, January 1999.
[RFC2459] Housley、R.、Ford、W.、Polk、W. and D. Solo、 "Internet X.509 Public Key Infrastructure、Certificate and CRL Profile"、RFC 2459、January 1999。
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[CMS] Housley、R。、「Cryptographic Message Syntax」、RFC 2630、1999年6月。
[DSS] Digital Signature Standard. FIPS Pub 186. National Institute of Standards and Technology. 19 May 1994.
[DSS]デジタル署名標準。 FIPS Pub 186.米国国立標準技術研究所。 1994年5月19日。
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS] Hoffman、P。、「Enhanced Security Services for S / MIME」、RFC 2634、1999年6月。
[ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems. Non-Repudiation Framework. April 1997.
[ISONR] ISO / IEC 10181-5：オープンシステムのセキュリティフレームワーク。非否認防止フレームワーク。 1997年4月。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[MD5] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
[SHA1] Secure Hash Standard. FIPS Pub 180-1. National Institute of Standards and Technology. 17 April 1995.
[SHA1] Secure Hash Standard。 FIPS Pub 180-1。国立標準技術研究所。 1995年4月17日。
Carlisle Adams Entrust, Inc. 1000 Innovation Drive Ottawa, Ontario K2K 3E7 CANADA
Carlisle Adams Entrust、Inc. 1000 Innovation Driveオタワ、オンタリオK2K 3E7カナダ
EMail: cadams@entrust.com
Pat Cain BBN 70 Fawcett Street Cambridge, MA 02138 U.S.A.
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
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
Robert Zuccherato Entrust、Inc. 1000イノベーションドライブオタワ、オンタリオK2K 3E7カナダ
EMail: robert.zuccherato@entrust.com
APPENDIX A - Signature Time-stamp attribute using CMS
付録A-CMSを使用した署名タイムスタンプ属性
One of the major uses of time-stamping is to time-stamp a digital signature to prove that the digital signature was created before a given time. Should the corresponding public key certificate be revoked this allows a verifier to know whether the signature was created before or after the revocation date.
タイムスタンプの主な用途の1つは、デジタル署名にタイムスタンプを付けて、デジタル署名が特定の時間より前に作成されたことを証明することです。対応する公開鍵証明書が取り消された場合、これにより検証者は署名が取り消し日の前または後に作成されたかどうかを知ることができます。
A sensible place to store a time-stamp is in a [CMS] structure as an unsigned attribute.
タイムスタンプを格納するための適切な場所は、署名されていない属性として[CMS]構造内にあります。
This appendix defines a Signature Time-stamp attribute that may be used to time-stamp a digital signature.
この付録では、デジタル署名にタイムスタンプを付けるために使用できる署名のタイムスタンプ属性を定義します。
The following object identifier identifies the Signature Time-stamp attribute:
次のオブジェクト識別子は、署名のタイムスタンプ属性を識別します。
id-aa-timeStampToken OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 14 }
The Signature time-stamp attribute value has ASN.1 type SignatureTimeStampToken:
Signature time-stamp属性値には、ASN.1タイプSignatureTimeStampTokenがあります。
SignatureTimeStampToken ::= TimeStampToken
The value of messageImprint field within TimeStampToken shall be a hash of the value of signature field within SignerInfo for the signedData being time-stamped.
TimeStampToken内のmessageImprintフィールドの値は、タイムスタンプされているsignedDataのSignerInfo内の署名フィールドの値のハッシュになります。
APPENDIX B - Placing a Signature At a Particular Point in Time
付録B-特定の時点での署名の配置
We present an example of a possible use of this general time-stamping service. It places a signature at a particular point in time, from which the appropriate certificate status information (e.g., CRLs) MUST be checked. This application is intended to be used in conjunction with evidence generated using a digital signature mechanism.
この一般的なタイムスタンプサービスの可能な使用例を示します。特定の時点で署名を配置し、そこから適切な証明書ステータス情報（CRLなど）を確認する必要があります。このアプリケーションは、デジタル署名メカニズムを使用して生成された証拠と組み合わせて使用することを目的としています。
Signatures can only be verified according to a non-repudiation policy. This policy MAY be implicit or explicit (i.e., indicated in the evidence provided by the signer). The non-repudiation policy can specify, among other things, the time period allowed by a signer to declare the compromise of a signature key used for the generation of digital signatures. Thus a signature may not be guaranteed to be valid until the termination of this time period.
署名は、否認防止ポリシーに従ってのみ検証できます。このポリシーは、暗黙的または明示的である場合があります（つまり、署名者によって提供された証拠に示されています）。非否認防止ポリシーは、とりわけ、デジタル署名の生成に使用される署名鍵の侵害を署名者が宣言することを許可する期間を指定できます。したがって、この期間が終了するまで、署名の有効性は保証されない場合があります。
To verify a digital signature, the following basic technique may be used: A) Time-stamping information needs to be obtained soon after the signature has been produced (e.g., within a few minutes or hours).
デジタル署名を検証するには、次の基本的な手法を使用できます。A）タイムスタンプ情報は、署名が作成された直後（たとえば、数分または数時間以内）に取得する必要があります。
1) The signature is presented to the Time Stamping Authority (TSA). The TSA then returns a TimeStampToken (TST) upon that signature.
1）署名はTime Stamping Authority（TSA）に提示されます。次に、TSAはその署名時にTimeStampToken（TST）を返します。
2) The invoker of the service MUST then verify that the TimeStampToken is correct.
2）サービスの呼び出し側は、TimeStampTokenが正しいことを確認する必要があります。
B) The validity of the digital signature may then be verified in the following way:
B）デジタル署名の有効性は、次の方法で検証できます。
1) The time-stamp token itself MUST be verified and it MUST be verified that it applies to the signature of the signer.
1）タイムスタンプトークン自体を検証する必要があり、署名者の署名に適用されることを検証する必要があります。
2) The date/time indicated by the TSA in the TimeStampToken MUST be retrieved.
2）TimeStampTokenのTSAによって示される日付/時刻を取得する必要があります。
3) The certificate used by the signer MUST be identified and retrieved.
3）署名者が使用する証明書を識別して取得する必要があります。
4) The date/time indicated by the TSA MUST be within the validity period of the signer's certificate.
4）TSAが示す日付/時刻は、署名者の証明書の有効期間内でなければなりません。
5) The revocation information about that certificate, at the date/time of the Time-Stamping operation, MUST be retrieved.
5）タイムスタンプ操作の日付/時刻に、その証明書に関する失効情報を取得する必要があります。
6) Should the certificate be revoked, then the date/time of revocation shall be later than the date/time indicated by the TSA.
6）証明書が失効した場合、失効の日付/時刻はTSAによって示された日付/時刻より遅くなります。
If all these conditions are successful, then the digital signature shall be declared as valid.
これらの条件がすべて成功した場合、デジタル署名は有効であると宣言されます。
APPENDIX C: ASN.1 Module using 1988 Syntax
付録C：1988構文を使用したASN.1モジュール
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 --
-ローカルに定義されたOID-
-- eContentType for a time-stamp token
-タイムスタンプトークンの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,
--a hash algorithm OID and the hash value of the data to be
--time-stamped
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 }
-- The status is based on the definition of status -- in section 3.2.3 of [RFC2510]
-ステータスはステータスの定義に基づいています-[RFC2510]のセクション3.2.3にあります
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL }
PKIStatus ::= INTEGER {
granted (0),
-- when the PKIStatus contains the value zero a TimeStampToken, as
requested, is present.
grantedWithMods (1),
-- when the PKIStatus contains the value one a TimeStampToken,
with modifications, is present.
rejection (2),
waiting (3),
revocationWarning (4),
-- this message contains a warning that a revocation is
-- imminent
revocationNotification (5)
-- notification that a revocation has occurred }
-- When the TimeStampToken is not present -- failInfo indicates the reason why the -- time-stamp request was rejected and -- may be one of the following values.
-TimeStampTokenが存在しない場合-failInfoが理由を示します-タイムスタンプ要求が拒否されました-以下の値のいずれかである可能性があります。
PKIFailureInfo ::= BIT STRING {
badAlg (0),
-- unrecognized or unsupported Algorithm Identifier
badRequest (2),
-- transaction not permitted or supported
badDataFormat (5),
-- the data submitted has the wrong format
timeNotAvailable (14),
-- the TSA's time source is not available
unacceptedPolicy (15),
-- the requested TSA policy is not supported by the TSA.
unacceptedExtension (16),
-- the requested extension is not supported by the TSA.
addInfoNotAvailable (17)
-- the additional information requested could not be understood
-- or is not available
systemFailure (25)
-- the request cannot be handled due to system failure }
TimeStampToken ::= ContentInfo
-- contentType is id-signedData as defined in [CMS] -- content is SignedData as defined in([CMS]) -- eContentType within SignedData is id-ct-TSTInfo -- eContent within SignedData is TSTInfo
-contentTypeは[CMS]で定義されているid-signedDataです-コンテンツは（[CMS]）で定義されているSignedDataです-SignedData内のeContentTypeはid-ct-TSTInfoです-SignedData内のeContentはTSTInfoです
TSTInfo ::= SEQUENCE {
version INTEGER { v1(1) },
policy TSAPolicyId,
messageImprint MessageImprint,
-- MUST have the same value as the similar field in
-- TimeStampReq
serialNumber INTEGER,
-- Time-Stamping users MUST be ready to accommodate integers
-- up to 160 bits.
genTime GeneralizedTime,
accuracy Accuracy OPTIONAL,
ordering BOOLEAN DEFAULT FALSE,
nonce INTEGER OPTIONAL,
-- MUST be present if the similar field was present
-- in TimeStampReq. In that case it MUST have the same value.
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
終わり
APPENDIX D: Access descriptors for Time-Stamping.
付録D：タイムスタンプ用のアクセス記述子。
[This annex describes an extension based on the SIA extension that will be defined in the "son-of-RFC2459". Since at the time of publication of this document, "son-of-RFC2459" is not yet available, its description is placed in an informative annex. The contents of this annex will eventually become incorporated into the son-of-RFC2459 document, at which time this annex will no longer be needed. A future version of this document will likely omit this annex and refer to son-of-RFC2459 directly.]
[この附属書は、「son-of-RFC2459」で定義されるSIA拡張に基づく拡張について説明しています。このドキュメントの公開時点では、「son-of-RFC2459」はまだ使用できないため、その説明は参考資料の付録に記載されています。この附属書の内容は、最終的にはRFC2459の息子の文書に組み込まれる予定であり、その時点でこの附属書は不要になります。このドキュメントの将来のバージョンでは、この附属書は省略され、son-of-RFC2459を直接参照する可能性があります。]
A TSA's certificate MAY contain a Subject Information Access (SIA) extension (son of RFC2459) in order to convey the method of contacting the TSA. The accessMethod field in this extension MUST contain the OID id-ad-timestamping:
TSAに連絡する方法を伝えるために、TSAの証明書には、サブジェクト情報アクセス（SIA）拡張（RFC2459の息子）が含まれている場合があります。この拡張機能のaccessMethodフィールドには、OID id-ad-timestampingが含まれている必要があります。
The following object identifier identifies the access descriptors for time-Stamping.
次のオブジェクト識別子は、タイムスタンプ用のアクセス記述子を識別します。
id-ad-timeStamping OBJECT IDENTIFIER ::= {iso(1)
identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
ad (48) timestamping (3)}
The value of the accessLocation field defines the transport (e.g., HTTP) used to access the TSA and may contain other transport dependent information (e.g., a URL).
accessLocationフィールドの値は、TSAへのアクセスに使用されるトランスポート（HTTPなど）を定義し、トランスポートに依存する他の情報（URLなど）を含む場合があります。
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（C）The Internet Society（2001）。全著作権所有。
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 information 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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。