Using SCVP to Convey Long-term Evidence Records

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 acquisition of different types of information generated by multiple PKIs. When verifying 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. SCVP [I-D.ietf-pkix-scvp] 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 [I-D.ietf-ltans-ers] 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 [I-D.ietf-ltans-ltap] defines a protocol for communicating with a long-term archive (LTA) server for the purposes of preserving evidence records and data. Clients store, retrieve and delete data using LTAP; LTAs maintain evidence records covering data submitted by clients. 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 object 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.

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 permits clients to request as much or as little information as desired from the SCVP server. Clients include zero or more 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: - end entity certificates - certification paths containing end entity certificates through trust anchors - certification paths containing intermediate certificates through trust anchors - revocation information. 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. 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 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. The transactions used to verify an archived data object using LTAP and the SCVP WantBacks described in this document are as follows: - Client retrieves a signed archived data object from an LTA using LTAP - 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 - SCVP server returns a response with status as of time of interest and including requested evidence records - Client processes the SCVP request, determines the status and verifies the evidence records - Client verifies signatures in the archived data object using the validated signer's certificate

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: - id-swb-ers-best-cert-path - id-swb-ers-partial-cert-path - id-swb-ers-pkc-cert - id-swb-ers-revocation-info - id-swb-ers-all Additionally, id-swb-partial-cert-path is defined to permit clients to request a partial certification path consisting of the CA who 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. For each id-swb-ers OID except id-swb-ers-all, an EvidenceRecord (as defined in [I-D.ietf-ltans-ers]) 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. 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 would include the following four replyWantBack OIDs: id-swb-best-cert-path, id-swb-pkc-revocation-info and id-swb-ers-all. [NOTE: id-swb-partial-cert-path and id-swb-ers-partial-cert-path may not be necessary. A client could achieve the same end by building a path to the issuer of an end entity certificate.] [NOTE: id-swb-pkc-cert is probably not applicable since the cert is returned in the response in a location other than the replyWantBack field. An alternative OID could be defined that results in the certificate being returned as a replyWantBack that is the target of a corresponding ERS entry in the replyWantBack.]

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. The evidence record is calculated over the value of the value field in the corresponding replyWantBack; the tag and length bytes are not covered by the evidence record. For example, if a client request contains id-swb-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 CertificateBundle returned in the id-swb-best-cert-path replyWantBack. If the server can not return an EvidenceRecord for the requested information, 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.

The following sections describe each WantBack defined in this document.

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. 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 is 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

The id-swb-ers-pkc-cert 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. 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-pkc-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. By maintaining an evidence record for a partial certification path, SCVP servers can achieve greater storage efficiency.

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. 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-pkc-partial-cert-path, id-swb-ers-partial-cert-path, id-swb-pkc-revocation-info and id-swb-ers-revocation-info.

The id-swb-ers-revocation-info OID is used to request an evidence record 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. An SCVP server may maintain evidence records for revocation information. Revocation information may be provided in the form of CRLs or OCSP responses. Cumulative CRLs may be generated for archiving to simplify evidence record maintenance.

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 in 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.

EvidenceRecordWantBacks is a SEQUENCE OF EvidenceRecordWantBack structures. The targetWantBack field indicates the type of replyWantBack is covered by the associated EvidenceRecord. The evidenceRecord field, if present, contains an EvidenceRecord structure calculated over the replyWantBack indicated by the targetWantBack field. 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 particular replyWantBack object, an EvidenceRecordWantBack with the evidenceRecord field absent should be included in the EvidenceRecordWantBacks collection.

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. SCVP clients can include id-swb-pkc-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.

For security considerations specific to SCVP, see [I-D.ietf-pkix-scvp]. For security considerations specific to ERS, see [I-D.ietf-ltans-ers]. 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. Usage of cumulative CRLs may require additional extensions to existing standards. Cumulative CRLs must contain revocation information for all certificates within the scope of the CRL, including expired certificates, must provide indications of when a certificate was placed on hold and removed from hold and must provide an indication of when a CRL entry first appeared on a CRL. One approach tailored for long-term archiving purposes, which may be described in a subsequent draft, is to generate CRLs with a fixed thisUpdate value and containing a new CRL entry extension identifying the thisUpdate of the CRL on which the entry first appeared. An LTA only needs to maintain the latest cumulative CRL in order to provide revocation status for all certificates within the scope and period of the CRL. In some cases, the original CRLs may be required. The mechanism described in this document focuses on preserving PKI artifacts and uses SCVP to convey the preservation evidence. A simpler alternative, or additional means, would be to define a directory entry to contain EvidenceRecords for the desired artifacts, e.g., certificates and cumulative CRLs.