[要約] RFC 5276は、長期的な証拠記録を伝達するためにServer-Based Certificate Validation Protocol（SCVP）を使用する方法について説明しています。このRFCの目的は、証明書の検証と長期的な証拠の保持を効率的かつ信頼性の高い方法で行うことです。
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）は、データの存在の非和解をサポートするために、証拠記録と呼ばれる構造を定義します。証拠記録は、パス内の証明書の有効期限が切れた後、パス内の証明書に署名するために使用される暗号化アルゴリズムの後に証明書への信頼を確立できるように、認定パスを構成する資料を保存するために使用できます。このドキュメントでは、SCVP Wantback機能の使用に関する証拠記録を伝え、SCVPレスポンダーが証明書と証明書の取り消しリスト（CRLS）の保存証拠を提供できるようにします。
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）アーティファクトを使用して頻繁に検証されます。Verifiersは、信頼できる公開鍵の署名を検証するために使用される公開鍵を含む公開鍵証明書から認証パスを構築および検証します。認証パスの構築には、複数の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を使用してデータを保存、取得、削除します。LTAは、クライアントから提出されたデータをカバーする証拠記録を維持しています。
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サーバーが返した情報に対応する証拠記録の取得を許可します。次に、SCVP応答を使用して、LTAPを使用して取得したアーカイブデータオブジェクトを検証することができます。認証パス情報の保存をデータの保存から分離すると、LTAはアーカイブデータオブジェクトをより効率的に保存できます。つまり、アーカイブされた各データオブジェクトに完全な検証情報を保存する必要はありません。Verifiersは、同じ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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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 Trust AnchorまでのEnd Entity証明書を含む認証パス。
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は、単一の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応答をめぐる署名は、証拠記録に含まれる信頼アンカーの送信を保護することができ、クライアントはLTAとの追加の信頼関係の確立を控えることができます。
The transactions used to verify an archived data object using LTAP and the SCVP WantBacks described in this document are as follows:
このドキュメントで説明されているLTAPとSCVP Wantbackを使用してアーカイブされたデータオブジェクトを検証するために使用されるトランザクションは次のとおりです。
o Client retrieves a signed archived data object from an LTA using LTAP.
o クライアントは、LTAを使用して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.
o クライアントはSCVP要求を処理し、ステータスを決定し、証拠記録を検証します。
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-best-cert-path
o id-swb-ers-partial-cert-path
o ID-SWB-ers-partial-cert-path
o id-swb-ers-pkc-cert
o ID-SWB-ERS-PKC-CERT
o id-swb-ers-revocation-info
o ID-SWB-ers-revocation-info
o id-swb-ers-all
o id-swb-ers-all
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-Partial-Cert-Pathは、クライアントが信頼アンカーを介して最終エンティティ証明書を発行した認証機関（CA）からなる部分認定パスを要求できるようにするために定義されています。これは、SCVPで定義されたID-SWB-BEST-CERT-PATH WANTBACKに似ています。
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-allを除く各ID-SWB-ers OIDについて、応答の対応する情報をカバーする証拠（[RFC4998]で定義されている）は、ReplyWantBackとして返されます。たとえば、クライアントが認定パスと取り消し情報とそれぞれの証拠記録を取得したい場合、SCVPリクエストには次の4つのReplyWantBack oids：id-swb-best-cert-path、id-swb-pkc-revocationが含まれます-info、ID-SWB-ers-best-cert-path、およびID-SWB-ers-revocation-info。
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-allの場合、ReplyWantBacksフィールドに含まれる各情報項目のevidencerecordを含むEvidencerecordwantbacks構造が返されます。たとえば、クライアントが認定パスと取り消し情報とそれぞれの証拠記録を取得したい場合、SCVPリクエストには、次の3つのReplyWantBack oids：id-swb-best-cert-path、id-swb-pkc-revocationを含めることができます-info、およびid-swb-ers-all。
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-ers-pkc-certおよびid-swb-ers-revocation-infoを除く各id-swb-ers oidについて、エビデンス記録は、対応するReplywantbackの値フィールドの値に対して計算する必要があります。タグと長さのバイトは、証拠記録ではカバーされていません。ID-SWB-ERS-PKC-CERTおよびID-SWB-ers-revocation-info ReplyWantWantBacksのターゲットを以下に説明します。たとえば、クライアント要求にID-SWB-PKC-BEST-CERT-PATHとID-SWB-ers-best-cert-pathが含まれている場合、結果の応答には、証拠が記録されている各タイプのReplyWantbackが含まれます。エンコードされたCertBundleは、ID-SWB-PKC-BEST-CERT-PATH REPLYWANTWANTBACKに戻りました。ID-SWB-ERS-PKC-CERTの場合、証拠記録は、CertreplyオブジェクトのCERTフィールドの値に対して計算する必要があります。ID-SWB-ers-revocation-infoの場合、一連の証拠記録が返されます。ID-SWB-PKC-Revocation-INFO ReplyWantBackに含まれる各撤回情報オブジェクトは、ID-SWB-ers-revocation-info 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を必要とします。クライアントは、対応するオブジェクトの希望バックが存在しない場合、証拠を記録した不正バックを無視する場合があります。
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-BEST-CERT-PATH OIDを使用して、完全な認証パスの証拠記録を要求します。ID-SWB-BEST-CERT-PATH OIDと組み合わせて使用されます。WantbackとしてのID-SWB-ers-Best-Cert-Pathを含むリクエストには、ID-SWB-Best-Cert-Pathも含まれている必要があります。ID-SWB-ers-best-cert-pathを含む応答には、ID-SWB-Best-Cert-Pathも含まれている必要があります。
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サーバーは、完全な認証パス、つまりエンディティからのすべての証明書を含む認証パスの証拠レコードを維持する場合があります。証拠記録は、ID-SWB-Best-Cert-Path ReplyWantBackを介して返されたCertBundleを介して計算する必要があります。そのような場合、アーカイブされたデータオブジェクト内の署名は、SCVPを介して返されたENDエンティティ証明書を使用して検証できます。End Entity証明書は、ID-SWB-ers-ers-best-cert-path、id-swb-best-cert-path、id-swb-pkc-revocation-info、およびid-swb-を含むリクエストを使用してSCVPを使用して検証できます。ers-revocation-info。
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-partial-cert-path oidを使用して、部分認定パスの証拠記録を要求します。ID-SWB-partial-cert-path oidと組み合わせて使用されます。WantbackとしてのID-SWB-ers-Partial-Cert-Pathを含むリクエストには、ID-SWB-Partial-Cert-Pathも含まれている必要があります。ID-SWB-ers-partial-cert-pathを含む応答には、ID-SWB-partial-cert-pathも含まれている必要があります。
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.
End Entity証明書の証拠記録を取得するためにSCVPに依存する代わりに、証明書は、LTAに提出されたアーカイブデータオブジェクトに含めることができます。そのような場合、アーカイブされたデータオブジェクト内の署名は、類似したENDエンティティ証明書を使用して検証できます。これは、証明書を含むアーカイブされたデータオブジェクトをカバーする証拠記録によって保護されています。End Entity証明書は、ID-SWB-Partial-Cert-Path、ID-SWB-ers-Partial-Cert-Path、ID-SWB-PKC-Revocation-INFO、およびID-SWB-を含むリクエストを使用してSCVPを使用して検証できます。ers-revocation-info。部分認証パスとは異なり、取り消し情報には、End Entity証明書のステータスを決定するために使用できる資料が含まれています。
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を介して返されたENDエンティティ証明書を使用して検証できます。ID-SWB-PKC-CERT、ID-SWB-ERS-PKC-CERT、ID-SWB-Partial-Cert-Path、ID-SWB-ERS-PARTIAL-CERTを含むリクエストを使用して、SCVPを使用してEnd Entity証明書を使用して検証できます-path、id-swb-pkc-revocation-info、およびid-swb-ers-revocation-info。
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-revocation-info oidは、取り消し情報のセットの証拠記録を要求するために使用されます。ID-SWB-revocation-info oidと組み合わせて使用されます。WantBackとしてのID-SWB-ers-revocation-infoを含むリクエストには、ID-SWB-Revocation-INFOも含まれている必要があります。ID-SWB-ers-revocation-infoを含む応答には、ID-SWB-revocation-infoも含まれている必要があります。一連の証拠記録が返され、ID-SWB-Revocation-INFOの各要素に1つの証拠記録が提供されます。
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サーバーは、取り消し情報の証拠記録を維持する場合があります。取り消し情報は、CRLSまたはオンライン証明書ステータスプロトコル（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-all oidは、ReplyWantbacksフィールドから返されたすべての情報のエビデンスレコードをクライアントが要求する速記の手段を提供します。ID-SWB-ers-allは、応答に複数の証拠記録が返される可能性があるため、証拠記録を証拠記録でカバーされている情報の種類に関連付けるメカニズムが必要です。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フィールドは、存在する場合、ターゲットワントバックフィールドで示された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-Partial-Cert-Pathは、ID-SWB-Best-Cert-Pathの代替品です。これは、このドキュメントで定義されている唯一のOIDであり、そのためにevidencerecordが応答で返されません。効率のために、認証パスの証拠記録を維持する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-Partial-Cert-Pathをリクエストに含めることができます。これは通常、ID-SWB-ers-partial-cert-pathとともに含まれ、一部のSCVPサーバーがストレージおよび計算効率の理由のための部分的なパスの証拠記録のみを作成するという事実を説明します。このような場合、リクエストにID-SWB-PKC-CERTおよびID-SWB-ers-PKC-CERTを含めることにより、End Entity証明書に別の証拠記録が利用可能になる場合があります。
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.
1つまたは複数の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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Freeman、T.、Housley、R.、Malpani、A.、Cooper、D。、およびW. Polk、「サーバーベースの証明書検証プロトコル（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.、Sylvester、P。、およびC. Wallace、「長期アーカイブプロトコル（LTAP）」、2008年2月、作業進行中。
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 Wantbackの6つの新しいフォームと3つの新しい構造を識別するために使用されるオブジェクト識別子を定義します。EvidencerecordwantbackとEvidencerecordwantbacksは、証拠記録をWantbacksと相関させるために、ID-SWB-ers-All Wantbackと併せて使用されます。EvidenCereCordsは、ID-SWB-ers-revocation-info 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) }
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 }
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) };
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
Carl Wallace Cygnacom Solutions Suite 5200 7925 Jones Branch Drive McLean、VA 22102
EMail: cwallace@cygnacom.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。