Network Working Group C. Wallace
Request for Comments: 5276 Cygnacom Solutions
Category: Standards Track August 2008
Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records
長期証拠レコードを伝えるために、サーバーベースの証明書の検証プロトコル（SCVP）を使用して、
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）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
The Server-based Certificate Validation Protocol (SCVP) defines an extensible means of delegating the development and validation of certification paths to a server. It can be used to support the development and validation of certification paths well after the expiration of the certificates in the path by specifying a time of interest in the past. The Evidence Record Syntax (ERS) defines structures, called evidence records, to support the non-repudiation of the existence of data. Evidence records can be used to preserve materials that comprise a certification path such that trust in the certificates can be established after the expiration of the certificates in the path and after the cryptographic algorithms used to sign the certificates in the path are no longer secure. This document describes usage of the SCVP WantBack feature to convey evidence records, enabling SCVP responders to provide preservation evidence for certificates and certificate revocation lists (CRLs).
サーバーベースの証明書の検証プロトコル（SCVP）はサーバに証明経路の開発と検証を委任の拡張可能手段を規定します。それも過去の関心の時間を指定して、パス内の証明書の失効後の証明書パスの開発と検証をサポートするために使用することができます。証拠のレコード構文（ERS）は、データの存在を否認防止をサポートするために、証拠レコードと呼ばれる構造を定義します。証拠の記録は、証明書の信頼は、パス内の証明書の有効期限後に、パス内の証明書に署名するために使用される暗号化アルゴリズムは、もはや安全である後に確立することができるような証明書パスを構成する材料を保持するために使用することができます。このドキュメントでは、証明書および証明書失効リスト（CRL）の保存証拠を提供するためにSCVPレスポンダを有効にする、証拠の記録を伝えるためにSCVP WantBack機能の使用方法について説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. Concept of Operations . . . . . . . . . . . . . . . . . . . . 4
3. Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. WantBacks . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Evidence Record for a Complete Certification Path . . . . 7
5.2. Evidence Record for a Partial Certification Path . . . . . 7
5.3. Evidence Record for a Public Key Certificate . . . . . . . 8
5.4. Evidence Record for Revocation Information . . . . . . . . 8
5.5. Evidence Record for Any replyWantBack . . . . . . . . . . 8
5.6. Partial Certification Path . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 11
Digital signatures are frequently verified using public key infrastructure (PKI) artifacts, including public key certificates and certificate revocation information. Verifiers construct and validate certification paths from a public key certificate containing the public key used to verify the signature to a trusted public key. Construction of a certification path may require the acquisition of different types of information generated by multiple PKIs. To verify digital signatures many years after signature generation, additional considerations must be addressed. For example, some necessary PKI artifacts may no longer be available, some may have expired, and the cryptographic algorithms or keys used in generating digital signatures may no longer provide the desired degree of security.
デジタル署名は、頻繁に公開鍵証明書および証明書失効情報を含む公開鍵基盤（PKI）の成果物を、使用して検証されています。検証は、信頼された公開鍵に署名を検証するために使用される公開鍵を含む公開鍵証明書の認証パスを構築し検証します。認証パスの構築は、複数のPKIによって生成された異なるタイプの情報の取得を必要とするかもしれません。デジタル署名に署名生成後に長年を確認するには、追加の考慮事項に対処しなければなりません。例えば、いくつかの必要なPKIアーチファクトがもはや利用可能でないかもしれない、いくつかの有効期限が切れている可能性があり、およびデジタル署名を生成する際に使用される暗号アルゴリズムや鍵はもはやセキュリティの所望の程度を提供しなくてもよいです。
SCVP [RFC5055] provides a means of delegating certification path construction and/or validation to a server, including the ability to request the status of a certificate relative to a time in the past. SCVP does not define a means of providing or validating long-term non-repudiation information. ERS [RFC4998] defines a syntax for preserving materials over long periods of time through a regimen that includes periodic re-signing of relevant materials using newer keys and stronger cryptographic algorithms. LTAP [LTANS-LTAP] defines a protocol for communicating with a long-term archive (LTA) server for the purpose of preserving evidence records and data. Clients store, retrieve, and delete data using LTAP; LTAs maintain evidence records covering data submitted by clients.
SCVP [RFC5055]は、過去の時間に証明書の相対的な状態を要求する能力を含む、サーバへの認証パス構築及び/又は検証を委譲する手段を提供します。 SCVPは、長期的な否認防止情報を提供するか、検証する手段を定義していません。 ERS [RFC4998]は、新しいキーと強力な暗号化アルゴリズムを使用して、関連する材料の定期的な再署名を含むレジメンを通して長期間にわたって材料を保存するための構文を定義します。 LTAP [LTANS-LTAP]は証拠レコードとデータを保存する目的で長期アーカイブ（LTA）サーバと通信するためのプロトコルを定義します。クライアントストア、取得、およびLTAPを使用してデータを削除します。 LTAsは、クライアントによって送信されたデータをカバーする証拠の記録を維持します。
This document defines an application of SCVP to permit retrieval of an evidence record corresponding to information returned by the SCVP server by creating an association between an evidence record and information contained in an SCVP response. The SCVP response can then in turn be used to verify archived data objects retrieved using LTAP. Separating the preservation of the certification path information from the preservation of data enables the LTA to store archived data objects more efficiently, i.e., complete verification information need not be stored with each archived data object. Verifiers can more efficiently process archived data objects by reusing the same certification path information to verify multiple archived data objects of similar vintage without retrieving and/or validating the same PKI artifacts multiple times.
この文書では、SCVP応答に含ま証拠記録と情報の間の関連付けを作成することにより、SCVPサーバによって返された情報に対応する証拠レコードの検索を可能にするSCVPのアプリケーションを定義します。 SCVP応答は、その後順番にLTAPを使用して取得アーカイブされたデータ・オブジェクトを検証するために使用することができます。データの保存から認証パス情報の保存を分離してアーカイブされたデータを格納するためにLTAを可能にし、より効率的に目的、すなわち、完全な検証情報は、各アーカイブされたデータオブジェクトに格納される必要はありません。検証者は、より効率的に複数回の取得及び/又は同一のPKIアーチファクトを検証することなく、同様のヴィンテージの複数のアーカイブ・データ・オブジェクトを検証するために、同じ認証パス情報を再利用することにより、アーカイブされたデータオブジェクトを処理することができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
During certification path processing, active SCVP servers may encounter a large portion of the PKI artifacts generated by a particular PKI. By storing and preserving these artifacts, an SCVP server can respond to queries for certificate status over very long periods of time. Optionally, SCVP servers may actively seek PKI information for storage and preservation, even when no query is made, that requires the information during its period of validity in order to service future queries relative to any point in time.
認証パス処理の間、アクティブSCVPサーバは、特定のPKIによって生成されたPKIアーティファクトの大部分が発生することができます。これらの成果物を保存し、保存することで、SCVPサーバは、時間の非常に長い期間にわたって、証明書のステータスのクエリに応答することができます。必要に応じて、SCVPサーバは、積極的にクエリが行われていない場合でも、それは任意の時点に比べて将来のクエリにサービスを提供するために、その有効期間中に情報を必要とし、保管・保存のためのPKI情報を求めることができます。
SCVP permits clients to request as much or as little information as desired from the SCVP server. Clients include zero or more Object Identifiers (OIDs) indicating the type(s) of information the server should include in the response. By defining additional OID values, clients can request an evidence record for specific types of information returned by the SCVP server. This document defines OIDs to permit the retrieval of evidence records for the following four types of information:
SCVPはSCVPサーバから必要なだけか、わずかな情報を要求するクライアントを許可します。クライアントは、サーバが応答に含めるべき情報の種類を示すゼロ以上のオブジェクト識別子（OID）を含みます。追加のOID値を定義することにより、クライアントはSCVPサーバから返された特定の種類の情報のための証拠の記録を要求することができます。この文書は情報の次の4つのタイプの証拠レコードの検索を可能にするためにOIDを定義します。
o end entity certificates.
Oエンドエンティティ証明書。
o certification paths containing an end entity certificate up to a trust anchor.
トラストアンカーへのエンドエンティティ証明書を含む証明書パスO。
o certification paths containing an intermediate certificate up to a trust anchor.
トラストアンカーに中間証明書を含む証明書パスO。
o revocation information.
Oの失効情報。
Additionally, an OID is defined to permit inclusion of a single OID indicating an evidence record is desired for all information requested via the WantBack mechanism.
また、OIDはWantBack機構を介して要求されたすべての情報のために所望される証拠レコードを示す単一のOIDを含めることを可能にするように定義されています。
By associating evidence records with information maintained by an SCVP server, clients are able to determine the status of certificates over very long periods of time using SCVP without consulting additional resources. The nature of SCVP servers is well suited to the preservation of infrastructure materials. Additionally, the SCVP server's signature over an SCVP response can secure the transmission of trust anchors included in evidence records, allowing clients to refrain from establishing additional trust relationships with LTAs.
SCVPサーバによって保持されている情報と証拠レコードを関連付けることにより、クライアントが追加のリソースを相談することなくSCVPを使用して、時間の非常に長い期間にわたって証明書のステータスを決定することができます。 SCVPサーバの性質は、インフラ資材の保存に適しています。また、SCVP応答を超えるSCVPサーバの署名は、クライアントがLTAsと、追加の信頼関係の確立を控えるできるように、証拠レコードに含ま信頼アンカーの伝送を確保することができます。
The transactions used to verify an archived data object using LTAP and the SCVP WantBacks described in this document are as follows:
次のようにトランザクションLTAPを使用してアーカイブされたデータ・オブジェクトを検証するために使用され、SCVP WantBacksは本書では説明は以下のとおりです。
o Client retrieves a signed archived data object from an LTA using LTAP.
OクライアントはLTAPを用いてLTAから署名されたアーカイブされたデータ・オブジェクトを検索します。
o Client prepares an SCVP request to validate the signer's certificate at the time of interest and includes WantBacks for evidence records corresponding to the PKI artifacts required to validate the signer's certificate.
Oクライアントは、関心のある時に署名者の証明書を検証するSCVP要求を作成し、署名者の証明書を検証するために必要なPKIアーティファクトに対応する証拠レコードのWantBacksが含まれています。
o SCVP server returns a response with status as of the time of interest and includes requested evidence records.
O SCVPサーバは、関心のある時点での状態で応答を返し、要求された証拠の記録を含みます。
o Client processes the SCVP request, determines the status, and verifies the evidence records.
クライアントはSCVP要求を処理O、状態を決定し、証拠の記録を検証します。
o Client verifies signatures in the archived data object using the validated signer's certificate.
Oクライアントが検証され、署名者の証明書を使用してアーカイブされたデータオブジェクト内の署名を検証します。
Clients request long-term archive evidence records from an SCVP server by including one of the following OIDs in the wantBack field of a CVRequest sent to an SCVP server:
クライアントはSCVPサーバに送信されCVRequestのwantBackフィールドに次のOIDのいずれかを含むことにより、SCVPサーバから長期アーカイブ証拠レコードを要求します。
o id-swb-ers-best-cert-path
O ID-SWB-ERS-最高-CERT-パス
o id-swb-ers-partial-cert-path
O ID-SWB-ERS-部分CERTパス
o id-swb-ers-pkc-cert
O ID-SWB-ERS-PKC-CERT
o id-swb-ers-revocation-info
O ID-スライド-ERS-失効-情報
o id-swb-ers-all
O ID-SWB-ERS-すべて
Additionally, id-swb-partial-cert-path is defined to permit clients to request a partial certification path consisting of the certification authority (CA) that issued the end entity certificate through a trust anchor. This is similar to the id-swb-best-cert-path WantBack defined in SCVP except the resulting replyWantBack will contain a CertBundle containing the certification path minus the end entity certificate.
さらに、ID-SWB-部分-CERT-パスは、トラストアンカーを通じてエンドエンティティ証明書を発行した認証局（CA）からなる部分証明書パスを要求するクライアントを許可するように定義されています。これは、ID-SWB-最良-CERT-パスWantBack認証パスマイナスエンドエンティティ証明書を含むCertBundleを含有する得られたreplyWantBack以外SCVPに定義されたと同様です。
For each id-swb-ers OID except id-swb-ers-all, an EvidenceRecord (as defined in [RFC4998]) covering the corresponding information in the response will be returned as a replyWantBack. For example, if a client wishes to obtain a certification path and revocation information plus an evidence record for each, the SCVP request would include the following four replyWantBack OIDs: id-swb-best-cert-path, id-swb-pkc-revocation-info, id-swb-ers-best-cert-path, and id-swb-ers-revocation-info.
ID-SWB-ERS-全て除く各ID-SWB-ERS OIDため、応答に対応する情報を覆うEvidenceRecordは（[RFC4998]で定義されるように）replyWantBackとして返されます。 ID-SWB-最高-CERT-パス、ID-SWB-PKC-失効：クライアント証明書パスと失効情報に加えてそれぞれの証拠のレコードを取得したい場合たとえば、SCVP要求は、次の4つのreplyWantBackのOIDが含まれます-info、ID-SWB-ERS-最高-CERT-パス、ID-SWB-ERS-失効-情報。
Alternatively, for id-swb-ers-all, an EvidenceRecordWantBacks structure will be returned containing an EvidenceRecord for each information item contained in the replyWantBacks field. For example, if a client wishes to obtain a certification path and revocation information plus an evidence record for each, the SCVP request could include the following three replyWantBack OIDs: id-swb-best-cert-path, id-swb-pkc-revocation-info, and id-swb-ers-all.
あるいは、ID-SWB-ERS-全てについて、EvidenceRecordWantBacks構造はreplyWantBacksフィールドに含まれる各情報項目のEvidenceRecordを含む返されます。 ID-SWB-最高-CERT-パス、ID-SWB-PKC-失効：クライアント証明書パスと失効情報に加えてそれぞれの証拠のレコードを取得したい場合たとえば、SCVP要求は、次の3つのreplyWantBack OIDを含めることができます-info、とid-SWB-ERS-すべて。
When a client request contains a WantBack request for an evidence record, the response generated MUST include the replyWantBack containing the requested information plus a replyWantBack containing the evidence record corresponding to that information. For each id-swb-ers OID except id-swb-ers-pkc-cert and id-swb-ers-revocation-info, the evidence record MUST be calculated over the value of the value field in the corresponding replyWantBack; the tag and length bytes are not covered by the evidence record. The targets for the id-swb-ers-pkc-cert and id-swb-ers-revocation-info replyWantBacks are described below. For example, if a client request contains id-swb-pkc-best-cert-path and id-swb-ers-best-cert-path, the resulting response will contain a replyWantBack of each type where the evidence record covers the DER-encoded CertBundle returned in the id-swb-pkc-best-cert-path replyWantBack. For id-swb-ers-pkc-cert, the evidence record MUST be calculated over the value of the cert field in the CertReply object. For id-swb-ers-revocation-info, a sequence of evidence records is returned. Each revocation information object contained in the id-swb-pkc-revocation-info replyWantBack is covered by an evidence record in the id-swb-ers-revocation-info replyWantBack. A single evidence record may cover multiple revocation information objects. The correct evidence record can be identified by locating the hash of the revocation information object in the first initial timestamp of the evidence record.
クライアント要求が証拠レコードのWantBack要求が含まれている場合、生成された応答は、要求された情報に加え、その情報に対応する証拠レコードを含むreplyWantBackを含むreplyWantBackを含まなければなりません。各ID-SWB-ERS ID-SWB-ERS-PKC-CERT及びID-SWB-ERS-失効情報以外OIDため、証拠レコードは、対応replyWantBackの値フィールドの値にわたって計算されなければなりません。タグと長さバイトが証拠レコードによってカバーされていません。 ID-SWB-ERS-PKC-CERTとid-SWB-ERS-失効インフォreplyWantBacksの目標は、以下に記載されています。例えば、クライアントの要求は、ID-SWB-PKC-最高-CERT-パスとID-SWB-ERS-最高-CERT-pathは、結果の応答は、証拠の記録がDER-をカバーし、各タイプのreplyWantBackが含まれています含まれている場合エンコードされたCertBundleは、ID-SWB-PKC-最高-CERT-パスreplyWantBackに戻りました。 ID-SWB-ERS-PKC-CERTのために、証拠レコードはCertReplyオブジェクト内の証明書フィールドの値にわたって計算しなければなりません。 ID-SWB-ERS-失効-情報については、証拠レコードのシーケンスが返されます。 ID-SWB-PKC-失効-情報に含まれる各失効情報オブジェクトはreplyWantBackは、ID-SWB-ERS-失効-情報replyWantBackにおける証拠レコードで覆われています。単一証拠レコードは、複数の失効情報オブジェクトをカバーすることができます。正しい証拠記録証拠レコードの最初の初期のタイムスタンプに失効情報オブジェクトのハッシュを配置することによって同定することができます。
If the server cannot return an EvidenceRecord for the requested information item, a replyWantBack of the appropriate type MUST be returned with an empty value field. For example, if a client requests id-swb-ers-pkc-cert and the server cannot fulfill the request, the resulting response will contain a replyWantBack with the wb field set to id-swb-ers-pkc-cert and the value field empty, i.e., zero length.
サーバは要求された情報項目のEvidenceRecordを返すことができない場合は、適切なタイプのreplyWantBackは、空の値フィールドで返さなければなりません。例えば、クライアントは、ID-SWB-ERS-PKC-CERTを要求した場合、サーバが要求を満たすことができない、結果の応答は、ID-SWB-ERS-PKC-CERTと値フィールドに設定WBフィールドでreplyWantBackが含まれています空、すなわち、ゼロの長さ。
The following sections describe each WantBack defined in this document. Each WantBack for an evidence record requires a corresponding WantBack for the object covered by the evidence record to be present in the request. Upon receipt of a request missing the corresponding WantBack for the object covered by a requested evidence record, the server MUST indicate wantBackUnsatisfied in the ReplyStatus. Clients MAY ignore evidence record WantBacks when the WantBack for the corresponding object is not present.
次のセクションでは、この文書で定義された各WantBackを説明します。証拠レコードの各WantBackリクエスト中に存在することが証拠レコードによってカバーされるオブジェクトの対応WantBackを必要とします。要求された証拠レコードで扱われるオブジェクトのための対応WantBackを逃す要求を受信すると、サーバはReplyStatusでwantBackUnsatisfiedを示さなければなりません。対応するオブジェクトのためのWantBackが存在しない場合、クライアントは証拠レコードWantBacksを無視するかもしれません。
The id-swb-ers-best-cert-path OID is used to request an evidence record for a complete certification path. It is used in conjunction with the id-swb-best-cert-path OID. Requests containing id-swb-ers-best-cert-path as a WantBack MUST also contain id-swb-best-cert-path. Responses containing id-swb-ers-best-cert-path MUST also contain id-swb-best-cert-path.
ID-SWB-ERS-最高-CERT-パスOIDは、完全な証明書パスの証拠記録を要求するために使用されます。これは、ID-SWB-最高-CERT-パスOIDに関連して使用されます。 WantBackとしてID-SWB-ERS-最高-CERT-パスを含む要求はまた、ID-SWB-最高-CERT-パスを含まなければなりません。 ID-SWB-ERS-最高-CERT-パスを含む応答はまた、ID-SWB-最高-CERT-パスを含まなければなりません。
An SCVP server may maintain evidence records for complete certification paths, i.e., certification paths containing all certificates from end entity to trust anchor. The evidence record MUST be calculated over the CertBundle returned via the id-swb-best-cert-path replyWantBack. In such cases, a signature within the archived data object may be verified using an end entity certificate returned via SCVP. The end entity certificate can be verified using SCVP using a request containing id-swb-ers-best-cert-path, id-swb-best-cert-path, id-swb-pkc-revocation-info, and id-swb-ers-revocation-info.
SCVPサーバは、完全な証明書パス、すなわち、エンドエンティティからのすべての証明書を含む証明書パスは、アンカーを信頼するための証拠の記録を維持することができます。証拠の記録はCertBundle上で計算しなければならないのid-SWB-最高-CERT-パスreplyWantBackを介して返さ。このような場合には、アーカイブされたデータオブジェクト内の署名は、エンドエンティティ証明書はSCVPを介して戻さ使用して検証することができます。エンドエンティティ証明書は、ID-SWB-ERS-最良-CERT-パス、ID-SWB-最良-CERT-パス、ID-SWB-PKC-失効情報を含む要求を使用してSCVPを使用して確認し、ID-swb-することができますERS-失効-情報。
The id-swb-ers-partial-cert-path OID is used to request an evidence record for a partial certification path. It is used in conjunction with the id-swb-partial-cert-path OID. Requests containing id-swb-ers-partial-cert-path as a WantBack MUST also contain id-swb-partial-cert-path. Responses containing id-swb-ers-partial-cert-path MUST also contain id-swb-partial-cert-path.
ID-SWB-ERS-部分CERTパスOIDは、部分認証パスの証拠記録を要求するために使用されます。これは、ID-SWB-部分-CERT-パスOIDと組み合わせて使用されます。 WantBackとしてID-SWB-ERS-部分-CERT-パスを含むリクエストはまた、ID-SWB-部分-CERT-パスを含まなければなりません。 ID-SWB-ERS-部分-CERT-パスを含む応答はまた、ID-SWB-部分-CERT-パスを含まなければなりません。
As an alternative to relying on SCVP to obtain evidence records for end entity certificates, the certificate could be included in the archived data object(s) submitted to an LTA. In such cases, a signature within the archived data object may be verified using the included end entity certificate, which is protected by the evidence record covering the archived data object, including the certificate. The end entity certificate can be verified using SCVP using a request containing id-swb-partial-cert-path, id-swb-ers-partial-cert-path, id-swb-pkc-revocation-info, and id-swb-ers-revocation-info. Unlike the partial certification path, the revocation information includes material that can be used to determine the status of the end entity certificate.
エンドエンティティ証明書の証拠レコードを取得するためにSCVPに頼る代わりに、証明書がLTAに提出されたアーカイブデータオブジェクト（複数可）に含めることができます。このような場合には、アーカイブされたデータオブジェクト内の署名は、証明書を含むアーカイブされたデータオブジェクトを、被覆証拠レコードによって保護されて含まれるエンドエンティティ証明書を用いて検証することができます。エンドエンティティ証明書は、ID-SWB-部分-CERT-パス、ID-SWB-ERS-部分-CERT-パス、ID-SWB-PKC-失効情報、及びID-swb-を含む要求を使用してSCVPを用いて検証することができますERS-失効-情報。部分認証パスとは異なり、失効情報は、エンドエンティティ証明書のステータスを決定するために用いることができる材料を含みます。
By maintaining an evidence record for a partial certification path, SCVP servers can achieve greater storage efficiency.
部分的証明書パスのための証拠の記録を維持することにより、SCVPサーバは、より大きなストレージ効率を達成することができます。
The id-swb-ers-pkc-cert OID is used to request an evidence record for an individual public key certificate. It is used in conjunction with the id-swb-pkc-cert OID. Requests containing id-swb-ers-pkc-cert as a WantBack MUST also contain id-swb-pkc-cert. Responses containing id-swb-ers-pkc-cert MUST also contain id-swb-pkc-cert.
ID-SWB-ERS-PKC-CERTのOIDは、個々の公開鍵証明書の証拠記録を要求するために使用されます。これは、ID-SWB-PKC-CERTのOIDに関連して使用されます。 WantBackとしてID-SWB-ERS-PKC-CERTを含む要求もID-SWB-PKC-CERTを含まなければなりません。 ID-SWB-ERS-PKC-CERTを含む応答はまた、ID-SWB-PKC-CERTを含まなければなりません。
SCVP servers may maintain evidence records for individual certificates. This enables clients to omit the signer's certificate from archived data object(s) submitted to an LTA. In such cases, a signature within the archived data object may be verified using an end entity certificate returned via SCVP. The end entity certificate can be verified using SCVP using a request containing id-swb-pkc-cert, id-swb-ers-pkc-cert, id-swb-partial-cert-path, id-swb-ers-partial-cert-path, id-swb-pkc-revocation-info, and id-swb-ers-revocation-info.
SCVPサーバは、個々の証明書の証拠記録を維持することができます。これは、LTAに提出アーカイブされたデータオブジェクト（複数可）から署名者の証明書を省略するためにクライアントを可能にします。このような場合には、アーカイブされたデータオブジェクト内の署名は、エンドエンティティ証明書はSCVPを介して戻さ使用して検証することができます。エンドエンティティ証明書は、ID-SWB-PKC-CERT、ID-SWB-ERS-PKC-CERT、ID-SWB-部分-CERT-パス、ID-SWB-ERS-部分証明書を含む要求を使用してSCVPを用いて検証することができます-path、ID-SWB-PKC-失効-情報、およびID-SWB-ERS-失効-情報。
The id-swb-ers-revocation-info OID is used to request evidence records for a set of revocation information. It is used in conjunction with the id-swb-revocation-info OID. Requests containing id-swb-ers-revocation-info as a WantBack MUST also contain id-swb-revocation-info. Responses containing id-swb-ers-revocation-info MUST also contain id-swb-revocation-info. A sequence of evidence records is returned, with one evidence record provided for each element in id-swb-revocation-info.
ID-SWB-ERS-失効インフォOIDは失効情報のセットのための証拠の記録を要求するために使用されます。これは、ID-SWB-失効-情報OIDに関連して使用されます。 WantBackとしてID-SWB-ERS-失効-情報を含む要求はまた、ID-SWB-失効-情報を含まなければなりません。 ID-SWB-ERS-失効-情報を含む応答はまた、ID-SWB-失効-情報を含まなければなりません。証拠レコードの順序は、ID-SWB-失効・情報の各要素のために提供される一つの証拠記録と、返されます。
EvidenceRecords ::= SEQUENCE SIZE (1..MAX) OF EvidenceRecord
An SCVP server may maintain evidence records for revocation information. Revocation information may be provided in the form of CRLs or Online Certificate Status Protocol (OCSP) responses. Cumulative CRLs may be generated for archiving to simplify evidence record maintenance.
SCVPサーバは、失効情報の証拠記録を維持することができます。失効情報は、CRLのか、オンライン証明書状態プロトコル（OCSP）応答の形で提供することができます。累積CRLは証拠レコードのメンテナンスを簡素化するためにアーカイブするために生成することができます。
An SCVP server may maintain evidence records for additional types of information that can be returned using the wantBack mechanism, e.g., attribute certificate information. The id-swb-ers-all OID provides a shorthand means for clients to request evidence records for all information returned via the replyWantBacks field. Since id-swb-ers-all can result in the return of multiple evidence records in the response, a mechanism is needed to associate an evidence record with the type of information covered by the evidence record. The EvidenceRecordWantBacks structure provides a flexible means of conveying an evidence record for different types of information.
SCVPサーバは、例えば、証明書の属性情報を、wantBackメカニズムを使用して返すことができる情報の追加タイプのための証拠の記録を維持することができます。 ID-SWB-ERS-すべてのOIDは、クライアントがreplyWantBacksフィールドを経由して返されたすべての情報については、証拠の記録を要求するための速記は手段を提供します。 ID-SWB-ERS-全てが応答内の複数の証拠レコードのリターンをもたらすことができるので、機構が証拠レコードによってカバーされる情報の種類に証拠記録を関連付けるために必要とされます。 EvidenceRecordWantBacks構造は、情報の異なる種類の証拠記録を伝える柔軟な手段を提供します。
EvidenceRecordWantBack ::= SEQUENCE
{
targetWantBack OBJECT IDENTIFIER,
evidenceRecord EvidenceRecord OPTIONAL
}
EvidenceRecordWantBacks ::=
SEQUENCE SIZE (1..MAX) OF EvidenceRecordWantBack
EvidenceRecordWantBacks is a SEQUENCE OF EvidenceRecordWantBack structures. The targetWantBack field indicates the type of replyWantBack covered by the associated EvidenceRecord. The evidenceRecord field, if present, contains an EvidenceRecord structure calculated over the replyWantBack indicated by the targetWantBack field. Where EvidenceRecordWantBacks is used, there MUST be a one-to-one correspondence between other replyWantBack objects and objects in the EvidenceRecordWantBacks collection. If a server does not have an EvidenceRecord for a particular replyWantBack object, an EvidenceRecordWantBack with the evidenceRecord field absent should be included in the EvidenceRecordWantBacks collection.
EvidenceRecordWantBacksはEvidenceRecordWantBack構造体のシーケンスです。 targetWantBackフィールドは、関連するEvidenceRecordでカバーreplyWantBackの種類を示します。 evidenceRecordフィールドは、存在する場合、targetWantBackフィールドによって示さreplyWantBackにわたって計算EvidenceRecord構造を含んでいます。 EvidenceRecordWantBacksが使用される場合、EvidenceRecordWantBacksコレクション内の他のreplyWantBackオブジェクトとオブジェクトの間に1対1の対応が存在していなければなりません。サーバは特定のreplyWantBackオブジェクトのEvidenceRecordを持っていない場合は、evidenceRecordフィールド不在でEvidenceRecordWantBackはEvidenceRecordWantBacksコレクションに含まれるべきです。
The id-swb-partial-cert-path is an alternative to id-swb-best-cert-path. This is the only OID defined in this document for which an EvidenceRecord is not returned in the response. For efficiency, SCVP servers that maintain evidence records for certification paths may only do so for partial paths instead of maintaining one or more paths for each end entity certificate.
ID-SWB-部分-CERT-パスは、ID-SWB-最高-CERT-パスに代わるものです。これはEvidenceRecordは応答で返さされていないため、この文書で定義された唯一のOIDです。効率化のために、証明書パスのための証拠の記録を維持するSCVPサーバーのみの代わりに、各エンドエンティティ証明書の1つ以上のパスを維持する部分経路のためにそうすることができます。
SCVP clients can include id-swb-partial-cert-path in a request when a partial certification path is required. This would typically be included along with id-swb-ers-partial-cert-path to account for the fact that some SCVP servers only produce evidence records for partial paths for storage and computational efficiency reasons. In such cases, a separate evidence record may be available for the end entity certificate by including id-swb-pkc-cert and id-swb-ers-pkc-cert in the request.
SCVPクライアントは、部分認証パスが必要とされる要求にID-SWB-部分-CERT-パスを含むことができます。これは典型的には、幾つかのSCVPサーバが唯一のストレージと計算効率の理由のための部分的なパスの証拠レコードを生成するという事実を考慮するために、ID-SWB-ERS-部分-CERT-パスと一緒に含まれることになります。このような場合には、別個の証拠レコードは、要求にID-SWB-PKC-CERT及びID-SWB-ERS-PKC-CERTを含むことにより、エンドエンティティ証明書のために利用可能であってもよいです。
For security considerations specific to SCVP, see [RFC5055]. For security considerations specific to ERS, see [RFC4998].
SCVPに特定のセキュリティの考慮事項については、[RFC5055]を参照してください。 ERSに特定のセキュリティの考慮事項については、[RFC4998]を参照してください。
The signature on the SCVP response containing one or more ERS structures must be verified using a public key trusted by the relying party. The response may contain trust anchors used to verify interior layers of an ERS structure. The trust anchors are protected by the SCVP server's signature covering the response. The relying party may elect to use the trust anchors conveyed in the response or ignore the trust anchors in favor of trust anchors retrieved out of band. Relying parties SHOULD ignore trust anchors contained in unsigned SCVP responses.
一つ以上のERS構造を含むSCVP応答の署名は、依拠当事者が信頼する公開鍵を使用して検証する必要があります。応答は、ERS構造の内部層を検証するために使用されるトラストアンカーを含んでいてもよいです。信頼アンカーは、応答をカバーするSCVPサーバの署名によって保護されています。証明書利用者は、応答に搬送信頼アンカーを使用するか、帯域外取り出さトラストアンカーの賛成で信頼アンカーを無視することを選択するかもしれません。依拠当事者は、符号なしSCVP応答に含まれる信頼アンカーを無視すべきです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence Record Syntax (ERS)", RFC 4998, August 2007.
[RFC4998] Gondrom、T.、Brandner、R.、およびU. Pordesch、 "証拠のレコード構文（ERS）"、RFC 4998、2007年8月。
[RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, "Server-Based Certificate Validation Protocol (SCVP)", RFC 5055, December 2007.
[RFC5055]フリーマン、T.、Housley氏、R.、Malpani、A.、クーパー、D.、およびW.ポーク、 "サーバーベースの証明書の検証プロトコル（SCVP）"、RFC 5055、2007年12月。
[LTANS-LTAP] Jerman-Blazic, A., Sylvester, P., and C. Wallace, "Long-term Archive Protocol (LTAP)", Work in Progress, February 2008.
[LTANS-LTAP] Jerman-Blazic、A.、シルベスター、P.、およびC.ウォレス、 "長期アーカイブプロトコル（LTAP）"、進歩、2008年2月に作業。
Appendix A. ASN.1 Module
付録A. ASN.1モジュール
The following ASN.1 module defines object identifiers used to identify six new forms of SCVP WantBacks and three new structures. EvidenceRecordWantBack and EvidenceRecordWantBacks are used in conjunction with the id-swb-ers-all WantBack to correlate evidence records with WantBacks. EvidenceRecords is used in conjunction with the id-swb-ers-revocation-info WantBack to return evidence records for individual revocation information objects.
以下のASN.1モジュールはSCVP WantBacks三の新しい構造の6つの新しい形を識別するために使用されるオブジェクト識別子を定義します。 EvidenceRecordWantBackとEvidenceRecordWantBacksはWantBacksで証拠レコードを相関させるために、ID-SWB-ERS-すべてWantBackと組み合わせて使用されています。 EvidenceRecordsは、個々の失効情報オブジェクトのための証拠のレコードを返すために、ID-SWB-ERS-失効-情報WantBackと組み合わせて使用されます。
LTANS-SCVP-EXTENSION { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) id-mod(0) id-mod-ers-scvp(5) id-mod-ers-scvp-v1(1) }
LTANS-SCVP延長{ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）ltans（11）ID-MOD（0）ID-MOD-ERS-SCVP（ 5）ID-MOD-ERS-SCVP-V1（1）}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
輸入
id-swb FROM SCVP { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 21 }
SCVPからID-SWB {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）21}
EvidenceRecord FROM ERS {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) id-mod(0) id-mod-ers88(2) id-mod-ers88-v1(1) };
ERS FROM EvidenceRecord {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）ltans（11）ID-MOD（0）ID-MOD-ers88（2）ID- MOD-ers88-V1（1）}。
id-swb-partial-cert-path OBJECT IDENTIFIER ::= {id-swb 15 }
id-swb-ers-pkc-cert OBJECT IDENTIFIER ::= {id-swb 16 }
id-swb-ers-best-cert-path OBJECT IDENTIFIER ::= {id-swb 17 }
id-swb-ers-partial-cert-path OBJECT IDENTIFIER ::= {id-swb 18 }
id-swb-ers-revocation-info OBJECT IDENTIFIER ::= {id-swb 19 }
id-swb-ers-all OBJECT IDENTIFIER ::= {id-swb 20 }
EvidenceRecordWantBack ::= SEQUENCE
{
targetWantBack OBJECT IDENTIFIER,
evidenceRecord EvidenceRecord OPTIONAL
}
EvidenceRecordWantBacks ::=
SEQUENCE SIZE (1..MAX) OF EvidenceRecordWantBack
EvidenceRecords ::= SEQUENCE SIZE (1..MAX) OF EvidenceRecord
END
終わり
Author's Address
著者のアドレス
Carl Wallace Cygnacom Solutions Suite 5200 7925 Jones Branch Drive McLean, VA 22102
カール・ウォレスCygnacomソリューションスイート5200 7925ジョーンズ支店ドライブマクリーン、VA 22102
EMail: cwallace@cygnacom.com
メールアドレス：cwallace@cygnacom.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。