Network Working Group C. Wallace
Request for Comments: 5276 Cygnacom Solutions
Category: Standards Track August 2008
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响应者能够为证书和证书撤销列表（CRL）提供保存证据。
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
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存储、检索和删除数据；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响应来验证使用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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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服务器返回的特定类型信息的证据记录。本文件定义了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被定义为允许包含单个OID，表明通过WantBack机制请求的所有信息都需要证据记录。
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 客户端使用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工件相对应的证据记录的WANTBACK。
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服务器的CVP请求的wantBack字段中包含以下OID之一，从SCVP服务器请求长期存档证据记录：
o id-swb-ers-best-cert-path
o id swb ers最佳证书路径
o id-swb-ers-partial-cert-path
o id swb ers部分证书路径
o id-swb-ers-pkc-cert
o id swb ers pkc证书
o id-swb-ers-revocation-info
o id swb ers吊销信息
o id-swb-ers-all
o 我喜欢游泳
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部分证书路径被定义为允许客户端请求部分证书路径，该路径由通过信任锚颁发最终实体证书的证书颁发机构（CA）组成。这与SCVP中定义的id swb best cert path WantBack类似，不同之处在于生成的replyWantBack将包含一个CertBundle，其中包含证书路径减去最终实体证书。
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 OID（id swb ers all除外），覆盖响应中相应信息的证据记录（如[RFC4998]中所定义）将作为ReplyHandback返回。例如，如果客户端希望获得认证路径和吊销信息以及每个路径的证据记录，则SCVP请求将包括以下四个replyWantBack OID：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，将返回一个证据记录WantBacks结构，其中包含replyWantBacks字段中包含的每个信息项的证据记录。例如，如果客户端希望获得证书路径和吊销信息以及每个路径的证据记录，则SCVP请求可以包括以下三个replyWantBack OID：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请求时，生成的响应必须包括包含请求的信息的ReplyHandback加上包含与该信息对应的证据记录的ReplyHandback。对于每个id swb ers OID（id swb ers pkc cert和id swb ers吊销信息除外），必须根据相应replyWantBack中的值字段的值计算证据记录；标记和长度字节不包含在证据记录中。id swb ers pkc证书和id swb ers吊销信息回复函的目标如下所述。例如，如果客户端请求包含id swb pkc best cert path和id swb ers best cert path，则生成的响应将包含每种类型的replyWantBack，其中证据记录涵盖id swb pkc best cert path replyWantBack中返回的DER编码证书束。对于id swb ers pkc cert，必须根据CertReply对象中的cert字段值计算证据记录。对于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.
如果服务器无法为请求的信息项返回证据记录，则必须返回具有空值字段的适当类型的ReplyHandback。例如，如果客户端请求id swb ers pkc cert，而服务器无法完成该请求，则生成的响应将包含一个replyWantBack，其中wb字段设置为id swb ers pkc cert，值字段为空，即零长度。
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
以下各节描述了本文档中定义的每个WantBack。证据记录的每个WantBack要求证据记录所涵盖的对象在请求中存在相应的WantBack。在收到请求时，缺少
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，服务器必须在ReplyStatus中指示WantBack未满足。当相应对象的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最佳证书路径OID用于请求完整证书路径的证据记录。它与id swb最佳证书路径OID一起使用。包含id swb ers best cert path作为WantBack的请求还必须包含id swb best cert path。包含id swb ers最佳证书路径的响应也必须包含id swb最佳证书路径。
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返回的最终实体证书来验证存档数据对象中的签名。可以使用包含id swb ers最佳证书路径、id swb最佳证书路径、id swb pkc吊销信息和id swb ers吊销信息的请求，使用SCVP验证最终实体证书。
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部分证书路径OID用于请求部分证书路径的证据记录。它与id swb部分证书路径OID一起使用。包含id swb ers部分证书路径作为WantBack的请求也必须包含id swb部分证书路径。包含id swb ers部分证书路径的响应也必须包含id swb部分证书路径。
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部分证书路径、id swb ers部分证书路径、id swb pkc吊销信息和id swb ers吊销信息的请求，使用SCVP验证最终实体证书。与部分证书路径不同，吊销信息包含可用于确定最终实体证书状态的材料。
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证书OID用于请求单个公钥证书的证据记录。它与id swb pkc证书OID一起使用。包含id swb ers pkc证书作为WantBack的请求还必须包含id-swb-pkc-cert。包含id swb ers pkc证书的响应还必须包含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证书、id swb ers pkc证书、id swb部分证书路径、id swb ers部分证书路径、id swb pkc吊销信息和id swb ers吊销信息的请求，使用SCVP验证最终实体证书。
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一起使用。包含id swb ers吊销信息作为WantBack的请求还必须包含id swb吊销信息。包含id swb ers吊销信息的响应还必须包含id swb吊销信息。返回一系列证据记录，为id swb吊销信息中的每个元素提供一条证据记录。
EvidenceRecords ::= SEQUENCE SIZE (1..MAX) OF EvidenceRecord
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
SCVP服务器可以维护可使用wantBack机制返回的其他类型信息的证据记录，例如属性证书信息。id swb ers all OID为客户提供了一种速记方式，以请求证据记录通过replyWantBacks字段返回的所有信息。由于id swb ers都可能导致在数据库中返回多个证据记录
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.
因此，需要一种机制将证据记录与证据记录所涵盖的信息类型相关联。EvidenceRecordWantBacks结构提供了一种灵活的方法，用于传输不同类型信息的证据记录。
EvidenceRecordWantBack ::= SEQUENCE
{
targetWantBack OBJECT IDENTIFIER,
evidenceRecord EvidenceRecord OPTIONAL
}
EvidenceRecordWantBack ::= SEQUENCE
{
targetWantBack OBJECT IDENTIFIER,
evidenceRecord EvidenceRecord OPTIONAL
}
EvidenceRecordWantBacks ::=
SEQUENCE SIZE (1..MAX) OF EvidenceRecordWantBack
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字段表示相关证据记录覆盖的replyWantBack类型。如果存在证据记录字段，则该字段包含一个根据TargetHandback字段指示的ReplyHandback计算的证据记录结构。如果使用了EvidenceRecordWantBacks，则其他replyWantBack对象与EvidenceRecordWantBacks集合中的对象之间必须存在一对一的对应关系。如果服务器没有特定replyWantBack对象的证据记录，则应将不存在证据记录字段的证据记录WantBack包含在证据记录WantBacks集合中。
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部分证书路径是id swb最佳证书路径的替代路径。这是本文档中定义的唯一一个未在响应中返回证据记录的OID。为了提高效率，为认证路径维护证据记录的SCVP服务器可能只为部分路径维护证据记录，而不是为每个终端实体证书维护一个或多个路径。
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部分证书路径。这通常与id swb ers部分证书路径一起包含，以说明某些SCVP服务器出于存储和计算效率原因仅为部分路径生成证据记录的事实。在这种情况下，可通过在请求中包含id swb pkc证书和id swb ers pkc证书，为最终实体证书提供单独的证据记录。
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]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 49982007年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 50552007年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和三种新结构的对象标识符。证据记录WantBack和证据记录WantBack与id swb ers all WantBack一起使用，以将证据记录与WantBack关联起来。证据记录与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-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
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 }
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) };
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-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 }
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
}
EvidenceRecordWantBack ::= SEQUENCE
{
targetWantBack OBJECT IDENTIFIER,
evidenceRecord EvidenceRecord OPTIONAL
}
EvidenceRecordWantBacks ::=
SEQUENCE SIZE (1..MAX) OF EvidenceRecordWantBack
EvidenceRecordWantBacks ::=
SEQUENCE SIZE (1..MAX) OF EvidenceRecordWantBack
EvidenceRecords ::= SEQUENCE SIZE (1..MAX) OF EvidenceRecord
EvidenceRecords ::= SEQUENCE SIZE (1..MAX) OF EvidenceRecord
END
终止
Author's Address
作者地址
Carl Wallace Cygnacom Solutions Suite 5200 7925 Jones Branch Drive McLean, VA 22102
卡尔·华莱士·辛尼亚康解决方案套房5200 7925弗吉尼亚州麦克莱恩琼斯支路22102
EMail: cwallace@cygnacom.com
EMail: 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.