Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records
Extracted elements (24)
By maintaining evidence records for partial certification paths (CA to trust anchor, excluding end entity) rather than complete paths, SCVP servers achieve greater storage and computational efficiency since the same partial path is shared by multiple end entity certificates.
Separating preservation of certification path information from preservation of data enables long-term archive (LTA) servers to store archived data objects more efficiently; complete verification information need not be stored with each archived data object, and verifiers can reuse the same certification path to verify multiple archived data objects of similar vintage.
The id-swb-ers-all OID provides a shorthand mechanism for clients to request evidence records for all information returned via replyWantBacks in a single OID, reducing request verbosity when evidence records are needed for every WantBack in a response.
The SCVP server's signature over an SCVP response can secure the transmission of trust anchors included in evidence records, allowing clients to avoid establishing additional trust relationships with long-term archive (LTA) servers.
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 when multiple CRL increments would otherwise require separate evidence records.
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 field of the corresponding replyWantBack; the tag and length bytes are not covered by the evidence record.
For id-swb-ers-pkc-cert, the evidence record MUST be calculated over the value of the cert field in the CertReply object, not the entire replyWantBack value field.
If the server cannot return an EvidenceRecord for the requested information item, a replyWantBack of the appropriate type MUST be returned with an empty (zero-length) value field.
Requests containing id-swb-ers-best-cert-path MUST also contain id-swb-best-cert-path; responses containing id-swb-ers-best-cert-path MUST also contain id-swb-best-cert-path.
Requests containing id-swb-ers-partial-cert-path MUST also contain id-swb-partial-cert-path; responses containing id-swb-ers-partial-cert-path MUST also contain id-swb-partial-cert-path.
Requests containing id-swb-ers-pkc-cert MUST also contain id-swb-pkc-cert; responses containing id-swb-ers-pkc-cert MUST also contain id-swb-pkc-cert.
Requests containing id-swb-ers-revocation-info MUST also contain id-swb-revocation-info; responses containing id-swb-ers-revocation-info MUST also contain id-swb-revocation-info.
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.
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 corresponding evidence record.
Where EvidenceRecordWantBacks is used, there MUST be a one-to-one correspondence between other replyWantBack objects and objects in the EvidenceRecordWantBacks collection.
For id-swb-ers-revocation-info, the correct evidence record covering a specific revocation information object can be identified by locating the hash of that revocation information object in the first initial timestamp of the evidence record.
id-swb-partial-cert-path requests a partial certification path consisting of CA certificates from the issuing CA through a trust anchor, explicitly excluding the end entity certificate. This is the only newly defined OID for which no EvidenceRecord is returned.
Six new SCVP WantBack OIDs are defined: id-swb-partial-cert-path (id-swb 15), id-swb-ers-pkc-cert (id-swb 16), id-swb-ers-best-cert-path (id-swb 17), id-swb-ers-partial-cert-path (id-swb 18), id-swb-ers-revocation-info (id-swb 19), and id-swb-ers-all (id-swb 20). Each id-swb-ers OID requests an EvidenceRecord for the corresponding PKI artifact.
This document registers six new SCVP WantBack OIDs under the id-swb arc: id-swb-partial-cert-path (15), id-swb-ers-pkc-cert (16), id-swb-ers-best-cert-path (17), id-swb-ers-partial-cert-path (18), id-swb-ers-revocation-info (19), and id-swb-ers-all (20), defined in the LTANS-SCVP-EXTENSION ASN.1 module.
Relying parties SHOULD ignore trust anchors contained in unsigned SCVP responses, since unsigned responses provide no cryptographic assurance that the conveyed trust anchors are authentic.
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 SCVP server's signature protects trust anchors conveyed in the response that are used to verify interior layers of an ERS structure.
EvidenceRecords is defined as SEQUENCE SIZE (1..MAX) OF EvidenceRecord. It is returned for id-swb-ers-revocation-info, with one EvidenceRecord per revocation information object in id-swb-pkc-revocation-info; a single record may cover multiple revocation objects.
EvidenceRecordWantBack is a SEQUENCE with two fields: targetWantBack (OBJECT IDENTIFIER indicating the type of replyWantBack covered) and evidenceRecord (EvidenceRecord, OPTIONAL). Used in id-swb-ers-all responses to associate each evidence record with the WantBack it covers.
EvidenceRecordWantBacks is defined as SEQUENCE SIZE (1..MAX) OF EvidenceRecordWantBack. It is returned in the replyWantBack when id-swb-ers-all is requested, providing a flexible container for multiple evidence records keyed by WantBack OID.