Server-Based Certificate Validation Protocol (SCVP)
Extracted elements (29)
SCVP defines two service classes: Delegated Path Validation (DPV), where clients fully delegate certification path construction and validation to a trusted server, and Delegated Path Discovery (DPD), where clients delegate only path construction and perform validation themselves. This split accommodates clients that lack path validation software or wish to centralize policy enforcement versus clients that merely cannot efficiently locate intermediate certificates.
The requestNonce and cachedResponse flag work together to give clients control over replay protection and freshness. When cachedResponse is FALSE, the client will not accept a cached response and MUST also include a requestNonce; a server that cannot produce a fresh response MUST reply with an error rather than returning a cached result.
The validation policy reference mechanism (OID plus optional parameters) allows SCVP to be deployed without requiring each deployment to register a new OID: the default policy (id-svp-defaultValPolicy) covers standard PKIX path processing with server-chosen defaults, and clients override individual parameters inline rather than defining a new policy OID.
SCVP DPD responses do not differentiate between 'some revocation information returned' and 'no revocation information returned' (states 2 and 3 of RFC 3379's required DPD status alternatives). This was discussed on the PKIX working group list and determined to be conformant with the intent of the requirements document.
All SCVP clients and servers MUST support SignedData for signed requests and responses. SCVP clients and servers SHOULD support AuthenticatedData for MAC-protected requests and responses.
Conforming clients MUST DER-encode the CVRequest in both protected and unprotected messages to facilitate unambiguous hash-based referencing in the corresponding response message.
For each check specified in the request, the SCVP server MUST perform the requested check or return an error. A server may perform additional checks but cannot indicate in the response that additional checks have been performed (except in an error response).
If a trustAnchors item is present, the server MUST NOT consider any certification paths ending in other trust anchors as valid. Additionally, the trust anchor itself MUST NOT be included in any certification path returned by the server.
SCVP clients that support DPV and do not use a protected transport mechanism (such as TLS) MUST always set protectResponse to TRUE or omit the responseFlags item entirely, requiring the server to return an authenticated response.
SCVP servers MUST apply a clock skew to the validation time to allow for minor time synchronization errors; the default clock skew value is 10 minutes. If a server uses a non-default value, it MUST include the clock skew in the validation policy response.
The subsequent response MUST use the same version number as the request. The value of cvRequestVersion MUST be 1 for clients implementing this specification.
The validationTime provided by the client MUST be a retrospective time; the server MUST perform validation using its current time if validationTime is absent. GeneralizedTime values MUST be expressed in UTC as YYYYMMDDHHMMSSZ and MUST NOT include fractional seconds.
Eight error OIDs under id-bvae (aliased to id-svp-basicValAlg) signal specific basic validation failures in the response: id-bvae-expired, id-bvae-not-yet-valid, id-bvae-wrongTrustAnchor, id-bvae-noValidCertPath, id-bvae-revoked, id-bvae-invalidKeyPurpose, id-bvae-invalidKeyUsage, and id-bvae-invalidCertPolicy. These may be used by any validation algorithm since all must implement basic validation.
Fourteen wantBack OIDs under id-swb (pkix arc 18) specify objects the client wants returned: including id-swb-pkc-best-cert-path, id-swb-pkc-revocation-info, id-swb-pkc-public-key-info, id-swb-pkc-all-cert-paths, id-swb-pkc-ee-revocation-info, id-swb-pkc-CAs-revocation-info, attribute certificate equivalents, and id-swb-relayed-responses. All servers MUST support id-swb-pkc-cert and id-swb-pkc-public-key-info.
ResponseFlags is a SEQUENCE of four BOOLEANs: fullRequestInResponse [0] DEFAULT FALSE (include full request in response for archival), responseValidationPolByRef [1] DEFAULT TRUE (policy by reference vs. by value), protectResponse [2] DEFAULT TRUE (require digital signature or MAC on response), and cachedResponse [3] DEFAULT TRUE (accept cached responses). If all defaults apply, the item MUST be omitted.
RevocationInfos is a SEQUENCE of RevocationInfo CHOICE elements supporting: crl [0] CertificateList, delta-crl [1] CertificateList, ocsp [2] OCSPResponse, and other [3] OtherRevInfo (OID plus ANY). Certificates in revInfos MUST NOT be considered valid solely because they appear there; the server may ignore revocation info that does not apply to its constructed path.
SCVPCertID provides a certificate reference by hash: certHash (OCTET STRING computed over the entire DER-encoded certificate including signature), issuerSerial (SCVPIssuerSerial), and hashAlgorithm (AlgorithmIdentifier DEFAULT sha-1). For public key certificates, issuer MUST contain only the issuer name encoded as directoryName in GeneralNames.
Seven check OIDs under id-stc (pkix arc 17) define what the server should perform: id-stc-build-pkc-path (DPD), id-stc-build-valid-pkc-path (DPV without revocation), id-stc-build-status-checked-pkc-path (DPV with revocation), and four analogous checks for attribute certificates. Servers supporting DPD MUST support id-stc-build-pkc-path; servers supporting DPV MUST support id-stc-build-valid-pkc-path and id-stc-build-status-checked-pkc-path.
The basic validation algorithm (id-svp-basicValAlg, pkix arc 19.3) MUST implement RFC 5280 Section 6 path validation for public key certificates and RFC 3281 Section 5 for attribute certificates. All other validation algorithms MUST generate results compliant with the basic algorithm; none of its requirements may be omitted, though algorithms MAY reject paths that the basic algorithm would accept.
The default validation policy (id-svp-defaultValPolicy, pkix arc 19.1) corresponds to standard PKIX path processing with server-chosen defaults. It MUST use the basic validation algorithm and has no policy parameters. Conforming servers MUST support it, though a server may be configured to reject all requests using it for security reasons.
The name validation algorithm (id-svp-nameValAlg, pkix arc 19.2) extends the basic algorithm by requiring one or more subject names to appear in the end certificate. Its parameters (NameValidationAlgParms) carry a nameCompAlgId OID and validationNames GeneralNames. Servers MUST support matching rules for id-nva-dnCompAlg (directory names), id-kp-serverAuth (DNS names with wildcard support), and id-kp-mailProtection (RFC 822 names).
The Query structure is the core of a CVRequest and MUST contain queriedCerts (CertReferences), checks (CertChecks), and validationPolicy (ValidationPolicy). Optional fields include wantBack [1], responseFlags, serverContextInfo [2], validationTime [3] GeneralizedTime, intermediateCerts [4] CertBundle, revInfos [5] RevocationInfos, producedAt [6] GeneralizedTime, and queryExtensions [7].
The serverContextInfo opaque OCTET STRING allows iterative path discovery: a client can resubmit the same query including the serverContextInfo from a prior response, prompting the server to return an alternative certification path. The subsequent query must be identical except for requestNonce, serverContextInfo, and the client's signature or MAC.
The ValidationPolicy SEQUENCE includes a required validationPolRef (OID plus optional params) and optional items: validationAlg [0], userPolicySet [1] (initial policy set), inhibitPolicyMapping [2] BOOLEAN, requireExplicitPolicy [3] BOOLEAN, inhibitAnyPolicy [4] BOOLEAN, trustAnchors [5], keyUsages [6], extendedKeyUsages [7], and specifiedKeyUsages [8]. These map directly to inputs defined in RFC 5280 Section 6.1.1.
Appendix A registers four MIME media types for SCVP: application/scvp-cv-request (certificate validation request), application/scvp-cv-response (certificate validation response), application/scvp-vp-request (validation policy request), and application/scvp-vp-response (validation policy response). When CVRequest is encapsulated in a MIME body part, application/scvp-cv-request MUST be used.
The document defines three OID arcs under the PKIX arc: id-stc (pkix 17) for server check type identifiers, id-swb (pkix 18) for server wantBack identifiers, and id-svp (pkix 19) for server validation policy identifiers including the default policy (id-svp 1), name validation algorithm (id-svp 2), and basic validation algorithm (id-svp 3).
A client that uses a trusted SCVP server for DPV inherently trusts the SCVP server as much as it would its own local certification path validation software. Clients relying on DPV responses for trust decisions MUST obtain authenticated responses (via digital signature or MAC, or a protected transport such as TLS) to prevent an attacker from substituting a false validation result.
The requestNonce mechanism protects against replay attacks by requiring the server to echo the nonce in a fresh (non-cached) response. Clients that require freshness guarantees MUST include a requestNonce and MUST set cachedResponse to FALSE; receiving a response without the matching respNonce indicates the response may be replayed.
CVRequest is an ASN.1 SEQUENCE containing cvRequestVersion (INTEGER DEFAULT 1), query (Query), and optional context-tagged fields: requestorRef [0], requestNonce [1] OCTET STRING, requestorName [2] GeneralName, responderName [3] GeneralName, requestExtensions [4] Extensions, signatureAlg [5] AlgorithmIdentifier, hashAlg [6] OBJECT IDENTIFIER, and requestorText [7] UTF8String (SIZE 1..256).