RFC 5055
Server-Based Certificate Validation Protocol (SCVP)
RFC 5055: Server-Based Certificate Validation Protocol (SCVP) 🎀
Okay bestie, this is RFC 5055 and it's giving main character energy 💅 Here's the title block, so you know who wrote it and how it's classified:
- Network Working Group 🌸
- Request for Comments: 5055
- Category: Standards Track ✨
- Date: December 2007
- Authors: T. Freeman (Microsoft Corp), R. Housley (Vigil Security), A. Malpani (Malpani Consulting Services), D. Cooper (NIST), and W. Polk (NIST) 🫶
The excerpt I was given doesn't list anything this document obsoletes or updates, so there's nothing to add there 🙈
Status of This Memo ✨
Okay so, this document is an Internet standards track protocol for the Internet community, and it's basically asking everyone to talk about it and send in ideas for making it better 💖 For the official standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🧚 And the best part? Distribution of this memo is unlimited 🦋
Abstract 🦋
Okay this one is so iconic. The Server-Based Certificate Validation Protocol (SCVP) lets a client hand off certification path construction and certification path validation to a server 🫶 That's the delegation part, and it's giving "not me doing all the heavy lifting" 💅
The path construction or validation (for example, making sure none of the certificates in the path have been revoked) runs according to a validation policy 🌈 That policy holds one or more trust anchors, so it's always got a foundation 👑
Why is this a whole vibe? Because it means client implementations can get way simpler, and clients can use a set of predefined validation policies instead of writing their own from scratch ✨ Simplicity is the moodboard 🍓
Table of Contents 🌸
Here's the full map of the document, so you can see everything that's coming (I'm not trimming a single entry, promise 💜):
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. SCVP Overview ..............................................5
1.3. SCVP Requirements ..........................................5
1.4. Validation Policies ........................................6
1.5. Validation Algorithm .......................................7
1.6. Validation Requirements ....................................8
2. Protocol Overview ...............................................9
3. Validation Request ..............................................9
3.1. cvRequestVersion ..........................................12
3.2. query .....................................................12
3.2.1. queriedCerts .......................................13
3.2.2. checks .............................................15
3.2.3. wantBack ...........................................16
3.2.4. validationPolicy ...................................19
3.2.4.1. validationPolRef ..........................20
3.2.4.1.1. Default Validation Policy ......21
3.2.4.2. validationAlg .............................22
3.2.4.2.1. Basic Validation Algorithm .....22
3.2.4.2.2. Basic Validation
Algorithm Errors ...............23
3.2.4.2.3. Name Validation Algorithm ......24
3.2.4.2.4. Name Validation
Algorithm Errors ...............25
3.2.4.3. userPolicySet .............................26
3.2.4.4. inhibitPolicyMapping ......................26
3.2.4.5. requireExplicitPolicy .....................27
3.2.4.6. inhibitAnyPolicy ..........................27
3.2.4.7. trustAnchors ..............................27
3.2.4.8. keyUsages .................................28
3.2.4.9. extendedKeyUsages .........................28
3.2.4.10. specifiedKeyUsages .......................29
3.2.5. responseFlags ......................................30
3.2.5.1. fullRequestInResponse .....................30
3.2.5.2. responseValidationPolByRef ................30
3.2.5.3. protectResponse ...........................31
3.2.5.4. cachedResponse ............................31
3.2.6. serverContextInfo ..................................32
3.2.7. validationTime .....................................32
3.2.8. intermediateCerts ..................................33
3.2.9. revInfos ...........................................34
3.2.10. producedAt ........................................35
3.2.11. queryExtensions ...................................35
3.2.11.1. extnID ...................................35
3.2.11.2. critical .................................35
3.2.11.3. extnValue ................................36
3.3. requestorRef ..............................................36
3.4. requestNonce ..............................................36
3.5. requestorName .............................................37
3.6. responderName .............................................37
3.7. requestExtensions .........................................38
3.7.1. extnID .............................................38
3.7.2. critical ...........................................38
3.7.3. extnValue ..........................................38
3.8. signatureAlg ..............................................38
3.9. hashAlg ...................................................39
3.10. requestorText ............................................39
3.11. SCVP Request Authentication ..............................40
4. Validation Response.............................................40
4.1. cvResponseVersion...........................................43
4.2. serverConfigurationID.......................................43
4.3. producedAt..................................................44
4.4. responseStatus..............................................44
4.5. respValidationPolicy........................................46
4.6. requestRef..................................................47
4.6.1. requestHash ........................................47
4.6.2. fullRequest ........................................48
4.7. requestorRef................................................48
4.8. requestorName...............................................48
4.9. replyObjects................................................49
4.9.1. cert................................................50
4.9.2. replyStatus.........................................50
4.9.3. replyValTime .......................................51
4.9.4. replyChecks ........................................51
4.9.5. replyWantBacks .....................................53
4.9.6. validationErrors ...................................56
4.9.7. nextUpdate .........................................56
4.9.8. certReplyExtensions ................................56
4.10. respNonce..................................................57
4.11. serverContextInfo..........................................57
4.12. cvResponseExtensions ......................................58
4.13. requestorText .............................................58
4.14. SCVP Response Validation ..................................59
4.14.1. Simple Key Validation .............................59
4.14.2. SCVP Server Certificate Validation ................59
5. Server Policy Request...........................................60
5.1. vpRequestVersion...........................................60
5.2. requestNonce...............................................60
6. Validation Policy Response......................................61
6.1. vpResponseVersion..........................................62
6.2. maxCVRequestVersion........................................62
6.3. maxVPRequestVersion........................................62
6.4. serverConfigurationID......................................62
6.5. thisUpdate.................................................63
6.6. nextUpdate and requestNonce................................63
6.7. supportedChecks............................................63
6.8. supportedWantBacks.........................................64
6.9. validationPolicies.........................................64
6.10. validationAlgs............................................64
6.11. authPolicies..............................................64
6.12. responseTypes.............................................64
6.13. revocationInfoTypes.......................................64
6.14. defaultPolicyValues.......................................65
6.15. signatureGeneration ......................................65
6.16. signatureVerification ....................................65
6.17. hashAlgorithms ...........................................66
6.18. serverPublicKeys .........................................66
6.19. clockSkew ................................................66
7. SCVP Server Relay...............................................67
8. SCVP ASN.1 Module...............................................68
9. Security Considerations.........................................76
10.IANA Considerations.............................................78
11. References.....................................................78
11.1. Normative References.....................................78
11.2. Informative References...................................79
12. Acknowledgments................................................80
Appendix A. MIME Media Type Registrations..........................81
A.1. application/scvp-cv-request..............................81
A.2. application/scvp-cv-response.............................82
A.3. application/scvp-vp-request..............................83
A.4. application/scvp-vp-response.............................84
Appendix B. SCVP over HTTP.........................................85
B.1. SCVP Request.............................................85
B.2. SCVP Response............................................85
B.3. SCVP Policy Request......................................86
B.4. SCVP Policy Response.....................................86Next up in Part 2: Section 1, Introduction 💖🦋✨
1. Introduction ✨
okay so certificate validation is literally SO complicated 😭 like if certificate handling is ever gonna be everywhere across all kinds of apps and environments, apps need to do way less work before they can accept a certificate 🫶 right now a bunch of apps are stuck doing all the overhead of building and validating certification paths themselves, which is exhausting bestie. SCVP lowkey fixes this for two types of apps 💅
the first type of app just wants two things: confirmation that the public key actually belongs to the identity named in the certificate, and confirmation that the key can be used for what it's meant for 🦋 these clients can completely hand off path construction and validation to the SCVP server. this is often called delegated path validation (DPV) 🎀
the second type can validate paths itself, but it doesn't have a reliable or efficient way to build a valid path 🥺 so these clients hand off path construction to the SCVP server, but they still do the validation of the returned path themselves. this is often called delegated path discovery (DPD) 🌸
1.1. Terminology
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 [STDWORDS]. ✨
1.2. SCVP Overview
okay the main goals of SCVP are making PKI-enabled apps way easier to deploy by delegating path discovery and/or validation processing to a server 🧚 and letting an organization centrally manage its validation policies 👑 SCVP can be used by clients that already do a lot of certificate processing themselves but just want an untrusted server to gather info for them 💜 but when the client fully trusts the SCVP server, SCVP can handle the whole path construction and validation thing, and it can make sure policies are consistently enforced across an entire organization 🔥
untrusted SCVP servers can give clients the certification paths 🍓 they can also provide revocation info, like Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) responses, that the clients need in order to validate the paths the server built 💖 this is super helpful for clients that don't implement the protocols needed to find and download intermediate certificates, CRLs, and OCSP responses 🙈
trusted SCVP servers can do path construction and validation for the client 🫶 a client using these services basically trusts the SCVP server as much as it would trust its own path validation software (if it had any) 💅 there are two main reasons a client might want to trust an SCVP server like this:
- the client doesn't want the overhead of including path validation software and running it for every certificate it gets 😭
- the client is in an organization or community that wants to centralize management of validation policies 👑 these policies might dictate which trust anchors get used and what kinds of policy checking happen during certification path validation 🎀
1.3. SCVP Requirements
SCVP meets the mandatory requirements documented in [RQMTS] for DPV and DPD ✨
note that RFC 3379 states this requirement:
The DPD response MUST indicate one of the following status alternatives: 1) one or more certification paths was found according to the path discovery policy, with all of the requested revocation information present. 2) one or more certification paths was found according to the path discovery policy, with a subset of the requested revocation information present. 3) one or more certification paths was found according to the path discovery policy, with none of the requested revocation information present. 4) no certification path was found according to the path discovery policy. 5) path construction could not be performed due to an error.
DPD responses from SCVP servers do not differentiate between states 2) and 3) 🙈 this got discussed on the PKIX working group list and was determined to be conformant with the intent of [RQMTS] 💅
1.4. Validation Policies
a validation policy (as defined in RFC 3379 [RQMTS]) specifies the rules and parameters the SCVP server uses when validating a certificate 🧚 in SCVP, the validation policy the server uses can either be fully referenced in the request by the client (so no extra parameters are needed) or be referenced by the client with additional parameters 🦋
policy definitions can get super long and complex, and some policies only let you set a few parameters 😭 so the request can be really simple if an object identifier (OID) is used to specify both the algorithm and all the associated parameters of the validation policy 💖 the request can get more complicated if the validation policy fixes lots of parameters but lets the client set some of them 🌈 when the validation policy defines every parameter, an SCVP request only needs to contain the certificate to be validated, the referenced validation policy, and any run-time parameters for the request 🔥
a server publishes the references of the validation policies it supports 👑 when these policies have parameters that can be overridden, the server also communicates the default values for them 🍓 the client can simplify the request by leaving out a parameter if the default value the server published for that policy reference is acceptable ✨ however, if someone else needs proof that a specific validation policy with all its parameters was used, the client will need to ask the server to include the full validation policy with all the parameters in the response 🫶
the inputs to the basic certification path processing algorithm used by SCVP are defined in [PKIX-1] Section 6.1.1 and include:
- certificate to be validated (by value or by reference);
- validation time;
- the initial policy set;
- initial inhibit policy mapping setting;
- initial inhibit anyPolicy setting; and
- initial require explicit policy setting.
the basic certification path processing algorithm also supports specifying one or more trust anchors (by value or by reference) as an input 🧚 if the client demands a certification path starting from one specific Certification Authority (CA), a single trust anchor is specified 💜 if the client will accept paths starting from any of several CAs, a set of trust anchors is specified 🌸
the basic certification path processing algorithm also supports the following parameters, which are defined in [PKIX-1], Section 4:
- the usage of the key contained in the certificate (e.g., key encipherment, key agreement, signature); and
- other application-specific purposes for which the certified public key may be used.
1.5. Validation Algorithm
the validation algorithm is determined by agreement between the client and the server and is represented as an OID 🎀 the algorithm defines the checking the server will do to decide whether the certificate is valid 💅 a validation algorithm is one of the parameters to a validation policy ✨ SCVP defines a basic validation algorithm that implements the basic path validation algorithm as defined in [PKIX-1], and it lets the client request additional info about the certificate being validated 🦋 new validation algorithms can be specified that define additional checks if needed 🌈 these new ones may specify additional parameters, and the values for those can be defined by any validation policy that uses the algorithm or be included by the client in the request 🫶
application-specific validation algorithms, beyond the ones defined in this document, can also be defined to meet specific requirements the basic validation algorithm doesn't cover 💖 the algorithms documented here should serve as a guide for building further application-specific ones 🧚 for example, a new application-specific validation algorithm might require a particular name form to be present in the subject alternative name extension of the certificate 👑
1.6. Validation Requirements
for a certification path to be considered valid under a particular validation policy, it MUST be a valid certification path as defined in [PKIX-1], and all validation policy constraints that apply to the certification path MUST be verified 😭🔥
revocation checking is one aspect of certification path validation defined in [PKIX-1] 💀 however, revocation checking is an optional feature in [PKIX-1], and revocation information gets distributed in multiple formats 🙈 clients specify in requests whether revocation checking should be performed and whether revocation information should be returned in the response 💅
servers MUST be capable of indicating the sources of revocation information they are capable of processing 👑
- full CRLs (or full Authority Revocation Lists);
- OCSP responses, using [OCSP];
- delta CRLs; and
- indirect CRLs.
2. Protocol Overview 🦋
okay so SCVP uses a simple request-response model 💖 the SCVP client makes a request and sends it to the SCVP server, and then the server creates a single response and sends it back to the client 🫶 the typical use of SCVP is expected to be over HTTP [HTTP], but it can also be used with email or any other protocol that can transport digitally signed objects 🌸 Appendices A and B give the details needed to use SCVP with HTTP ✨
SCVP includes two request-response pairs 🧚 the primary pair handles certificate validation 👑 the secondary pair is used to find out the list of validation policies and default parameters a specific SCVP server supports 🍓
Section 3 defines the certificate validation request 🎀
Section 4 defines the corresponding certificate validation response 💅
Section 5 defines the validation policies request 🔥
Section 6 defines the corresponding validation policies response 💜
Appendix A registers MIME types for SCVP requests and responses, and Appendix B describes the use of these MIME types with HTTP 🌈
3. Validation Request ✨
Okay bestie, this is where the client actually asks the server for stuff 💌 An SCVP client request to the server MUST be a single CVRequest item. 🎀 When a CVRequest gets wrapped in a MIME body part, application/scvp-cv-request MUST be used.
There are two flavours of request 🦋: unprotected and protected. A protected request is what you use to authenticate the client to the server, or to give anonymous client integrity over the whole request-response pair 🫶. The protection comes from a digital signature or a message authentication code (MAC). For a MAC, the key gets derived through a key agreement algorithm, like Diffie-Hellman. If the client's public key sits inside a certificate, it can be used to authenticate the client. But honestly the more common move is an ephemeral key agreement public key, which is what gives you anonymous client integrity 🌸.
A server MAY require all requests to be protected, and a server MAY discard all unprotected requests. Alternatively, a server MAY choose to process unprotected requests. 👑 Servers get options, babes.
The unprotected request is a CVRequest wrapped in a Cryptographic Message Syntax (CMS) ContentInfo [CMS]. Here's a sneak peek at that structure. It's only illustrative, and the real ASN.1 lives in [CMS]. Lots of details are hidden, but you can still see how SCVP plugs into CMS 🧚
ContentInfo {
contentType id-ct-scvp-certValRequest,
-- (1.2.840.113549.1.9.16.1.10)
content CVRequest }The protected request is a CVRequest wrapped in either a SignedData or an AuthenticatedData, and that whole thing gets wrapped in a ContentInfo 🎁. Basically, the EncapsulatedContentInfo field of either one has an eContentType of id-ct-scvp-certValRequest, and an eContent field that holds a Distinguished Encoding Rules (DER)-encoded CVRequest. SignedData is for requests that are digitally signed. AuthenticatedData is for requests using a message authentication code (MAC).
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. ✨
If the client uses SignedData, it MUST have a public key that's bound to a subject identity by a certificate conforming to the PKIX profile [PKIX-1], and that certificate MUST be suitable for signing the SCVP request. That means:
- If the key usage extension is present, either the digital signature or the non-repudiation bit MUST be asserted.
- If the extended key usage extension is present, it MUST contain either the SCVP client OID (see Section 3.11), the anyExtendedKeyUsage OID, or another OID acceptable to the SCVP server.
The client MUST put an unambiguous reference to its certificate in the SignedData that wraps the request. The client SHOULD include its certificate in the request, but MAY leave it out to shrink the request 🙈. The client MAY include other certificates in the request to help the SCVP server validate its certificates. The signerInfos field of SignedData MUST include exactly one SignerInfo. The SignedData MUST NOT include the unsignedAttrs field. 💅
The client MUST put its key agreement public key, or an unambiguous reference to a certificate containing that key, in the AuthenticatedData that wraps the request. If an ephemeral key agreement key pair is used, the ephemeral public key rides along in the originatorKey field of KeyAgreeRecipientInfo. That means the client needs the server's key agreement public key before it can compute the MAC 🔐. The server's key agreement key is included in its validation policy response message (see Section 6). The recipientInfos field of AuthenticatedData MUST include exactly one RecipientInfo, which holds the information for the SCVP server. The AuthenticatedData MUST NOT include the unauthAttrs field.
The syntax and semantics for SignedData, AuthenticatedData, and ContentInfo are defined in [CMS]. The CVRequest's syntax and semantics are below. The CVRequest item is the client's actual request 🦋. It contains cvRequestVersion and query items, and it MAY also contain requestorRef, requestNonce, requestorName, responderName, requestExtensions, signatureAlg, and hashAlg items.
The CVRequest MUST have the following syntax:
CVRequest ::= SEQUENCE {
cvRequestVersion INTEGER DEFAULT 1,
query Query,
requestorRef [0] GeneralNames OPTIONAL,
requestNonce [1] OCTET STRING OPTIONAL,
requestorName [2] GeneralName OPTIONAL,
responderName [3] GeneralName OPTIONAL,
requestExtensions [4] Extensions OPTIONAL,
signatureAlg [5] AlgorithmIdentifier OPTIONAL,
hashAlg [6] OBJECT IDENTIFIER OPTIONAL,
requestorText [7] UTF8String (SIZE (1..256)) OPTIONAL }Conforming clients MUST be able to construct requests with cvRequestVersion and query. Conforming clients MUST DER encode the CVRequest in both protected and unprotected messages, so the response can be unambiguously referenced by hash 🧾. SCVP clients that insist on a fresh response (for example, to protect against a replay attack or to make sure the info is up to date) MUST support requestNonce. Support for the remaining items is optional in client implementations.
Conforming servers MUST be able to parse CVRequests that contain any or all of the optional items. 🌈
Each of the items within the CVRequest gets its own section below 👀.
3.1. cvRequestVersion
The cvRequestVersion item says which version of the SCVP CVRequest a request is using. The response MUST use the same version number. The value MUST be one (1) for a client implementing this specification. Future updates will have to specify other values if the syntax or semantics ever change. New extensions can still be defined without bumping the version number ✨.
SCVP clients MUST support asserting this value and SCVP servers MUST be capable of processing this value.
3.2. query
The query item names one or more certificates that the request is about. Those can be public key certificates [PKIX-1] or attribute certificates [PKIX-AC] 📜. A query MUST contain a queriedCerts item as well as one checks item, and one validationPolicy item. A query MAY also contain wantBack, responseFlags, serverContextInfo, validationTime, intermediateCerts, revInfos, producedAt, and queryExtensions items.
A Query MUST have the following syntax:
Query ::= SEQUENCE {
queriedCerts CertReferences,
checks CertChecks,
-- Note: tag [0] not used --
wantBack [1] WantBack OPTIONAL,
validationPolicy ValidationPolicy,
responseFlags ResponseFlags OPTIONAL,
serverContextInfo [2] OCTET STRING OPTIONAL,
validationTime [3] GeneralizedTime OPTIONAL,
intermediateCerts [4] CertBundle OPTIONAL,
revInfos [5] RevocationInfos OPTIONAL,
producedAt [6] GeneralizedTime OPTIONAL,
queryExtensions [7] Extensions OPTIONAL }The queriedCerts list tells the server which certificate(s) the client wants info about 🔍. checks specifies the checking the client wants done. wantBack specifies the objects the client wants returned in the response. validationPolicy specifies the validation policy the client wants the server to use. responseFlags lets the client ask for optional features in the response. serverContextInfo says the client wants extra info from a previous request-response. validationTime is the date and time the client wants the checks to be relative to ⏰. intermediateCerts and revInfos provide context for the request. queryExtensions is there for future expansion of the query syntax. Each of these items is covered in the sections that follow.
Conforming clients MUST be able to construct a Query with a queriedCerts item that specifies at least one certificate, checks, and validationPolicy. Conforming SCVP clients MAY support specifying multiple certificates and MAY support the optional items in the Query structure.
SCVP clients that support delegated path discovery (DPD) as defined in [RQMTS] MUST support wantBack and responseFlags. SCVP clients that insist on creating a fresh response (for example, to protect against a replay attack or to ensure information is up to date) MUST support responseFlags. 💖
Conforming servers MUST be able to process a Query that contains any of the optional items, and MUST be able to process a Query that specifies multiple certificates. 🫶
3.2.1. queriedCerts 🎀
okay so queriedCerts is a SEQUENCE of one or more certificates, and every one of them is a subject of the request 💅 The certs can be public key certificates or attribute certificates. If you list more than one, they all have to be the same type, no mixing 🙅♀️ Each cert is either included directly or referenced. If it's referenced, you also send a hash of the item so the SCVP client and the SCVP server both end up with the same certificate when they go fetch it 🔐 That's the whole point of the hash, and it's giving reliability ✨ References use the SCVPCertID type, which we'll get to in a sec. And a single request MAY contain both directly included and referenced certificates 🌈
CertReferences has the following syntax:
CertReferences ::= CHOICE {
pkcRefs [0] SEQUENCE SIZE (1..MAX) OF PKCReference,
acRefs [1] SEQUENCE SIZE (1..MAX) OF ACReference }
PKCReference ::= CHOICE {
cert [0] Certificate,
pkcRef [1] SCVPCertID }
ACReference ::= CHOICE {
attrCert [2] AttributeCertificate,
acRef [3] SCVPCertID }
SCVPCertID ::= SEQUENCE {
certHash OCTET STRING,
issuerSerial SCVPIssuerSerial,
hashAlgorithm AlgorithmIdentifier DEFAULT { algorithm sha-1 } }The ASN.1 definition of Certificate gets imported from [PKIX-1], and the AttributeCertificate definition gets imported from [PKIX-AC] 📚
Now, when you're making a SCVPCertID, the certHash is computed over the entire DER-encoded certificate, signature included 🫶 The hash algorithm you used goes in hashAlgorithm. For certHash, the hash algorithm SHOULD be one of the ones listed in the hashAlgorithms item of the server's validation policy response message. Ngl this is one of those "read it twice" bits 🤓
For SCVPIssuerSerial: serialNumber is the serial number that uniquely identifies the certificate 🔢 If it's a public key certificate, the issuer MUST contain only the issuer name from the certificate, encoded in the directoryName choice of GeneralNames. If it's an attribute certificate, the issuer MUST contain the issuer name field from the attribute certificate 💜
Conforming clients MUST be able to reference a certificate by direct inclusion. That's the non-negotiable baseline 👑 Clients SHOULD be able to specify a certificate using the SCVPCertID too. Conforming clients MAY be able to reference multiple certificates, and they MAY be able to reference both public key and attribute certificates. Optional but iconic 🦋
Conforming SCVP Server implementations MUST be able to process CertReferences with multiple certificates. They MUST also be able to parse CertReferences that contain either public key or attribute certificates. Servers MUST be able to parse both the cert and pkcRef choices in PKCReference. And conforming SCVP server implementations that process attribute certificates MUST be able to parse both the attrCert and acRef choices in ACReference. Servers really have to keep up here, bestie 💅🍓
3.2.2. checks 🦋
The checks item is basically the client's wishlist: it tells the SCVP server what checking the client wants done on the certificate(s) in the queriedCerts item 🧚 It's a sequence of object identifiers (OIDs), and each OID names one specific check the client expects. For every check in the request, the SCVP server MUST perform the requested check, or return an error. No ghosting ❌ A server may choose to do extra checks, too. Like, a server that was only asked to build a validated certification path might also decide to do revocation status checks. The catch is that it can't say in the response that it did those extra checks, except if there's an error response 🙈
The checks item uses the CertChecks type, with this syntax:
CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIERFor public key certificates, this document defines the following checks:
- id-stc-build-pkc-path: Build a prospective certification path to a trust anchor (as defined in Section 6.1 of [PKIX-1]);
- id-stc-build-valid-pkc-path: Build a validated certification path to a trust anchor (revocation checking not required);
- id-stc-build-status-checked-pkc-path: Build a validated certification path to a trust anchor and perform revocation status checks on the certification path.
Conforming SCVP server implementations that support delegated path discovery (DPD) as defined in [RQMTS] MUST support the id-stc-build-pkc-path check. Conforming SCVP server implementations that support delegated path validation (DPV) as defined in [RQMTS] MUST support the id-stc-build-valid-pkc-path and id-stc-build-status-checked-pkc-path checks. So DPD means you get the path-building one, and DPV means you get both validation ones 🫶
For attribute certificates, this document defines the following checks:
- id-stc-build-aa-path: Build a prospective certification path to a trust anchor for the Attribute Certificate (AC) issuer;
- id-stc-build-valid-aa-path: Build a validated certification path to a trust anchor for the AC issuer;
- id-stc-build-status-checked-aa-path: Build a validated certification path to a trust anchor for the AC issuer and perform revocation status checks on the certification path for the AC issuer;
- id-stc-status-check-ac-and-build-status-checked-aa-path: Build a validated certification path to a trust anchor for the AC issuer and perform revocation status checks on the AC as well as the certification path for the AC issuer.
Conforming SCVP server implementations MAY support the attribute certificates checks. Optional, so no pressure 🌸
For these purposes, the following OIDs are defined:
id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 }
id-stc-build-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 }
id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 2 }
id-stc-build-status-checked-pkc-path
OBJECT IDENTIFIER ::= { id-stc 3 }
id-stc-build-aa-path OBJECT IDENTIFIER ::= { id-stc 4 }
id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 5 }
id-stc-build-status-checked-aa-path
OBJECT IDENTIFIER ::= { id-stc 6 }
id-stc-status-check-ac-and-build-status-checked-aa-path
OBJECT IDENTIFIER ::= { id-stc 7 }Other specifications may define additional checks too ✨
And finally, conforming client implementations MUST support assertion of at least one of the standard checks. Clients MAY support asserting multiple checks, and they don't need to support every check defined in this section. Pick your favourites and serve them 💖
3.2.3. wantBack 🎀
okay so the optional wantBack item is the client's little wishlist 🧚. It tells the SCVP server what extra info the client wants about the certificate(s) in the queriedCerts item, on top of the results from the checks item. If it's there, it MUST contain a sequence of object identifiers (OIDs). Each OID tells the server what the client wants to know about queriedCerts. For every type of info the request asks for, the server MUST send back what it found (in a successful response) 💅
let's look at a couple of examples because they're so iconic 🦋 a request could have a checks item that only asks for certification path building, and a wantBack item that asks for the path the server built. in that case the response has no validation status, but it does include a prospective certification path. a client that wants to do its own path validation would send something like this 🧠
or a request could have a checks item that asks the server to build a path, validate it, AND do revocation checking, with no wantBack item at all. then the response only has a status for the path validation. a client that totally hands off path validation would send this kind of request 🫶
the wantBack item uses the WantBack type, and the syntax is:
WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIERfor public key certificates, these wantBacks are defined in this document:
id-swb-pkc-cert: The certificate that was the subject of the request;id-swb-pkc-best-cert-path: The certification path built for the certificate including the certificate that was validated;id-swb-pkc-revocation-info: Proof of revocation status for each certificate in the certification path;id-swb-pkc-public-key-info: The public key from the certificate that was the subject of the request;id-swb-pkc-all-cert-paths: A set of certification paths for the certificate that was the subject of the request;id-swb-pkc-ee-revocation-info: Proof of revocation status for the end entity certificate in the certification path; andid-swb-pkc-CAs-revocation-info: Proof of revocation status for each CA certificate in the certification path.
all conforming SCVP server implementations MUST support the id-swb-pkc-cert and id-swb-pkc-public-key-info wantBacks 🌸 and conforming SCVP server implementations that support delegated path discovery (DPD) as defined in [RQMTS] MUST support the id-swb-pkc-best-cert-path and id-swb-pkc-revocation-info wantBacks 💖
there are two ways a client can grab multiple certification paths for one certificate 🛤️ the first is to use serverContextInfo to get one path at a time (see Section 3.2.6). after each path, the client can send the serverContextInfo from the previous request to get another, until it finds a path it likes or the server stops sending a serverContextInfo (which means no more paths are available). the second way is to send one request with an id-swb-pkc-all-cert-paths wantBack, and the server returns every available path in one go ✨
the server may, at its discretion, limit how many paths it returns for id-swb-pkc-all-cert-paths. when the request includes an id-swb-pkc-all-cert-paths wantBack, the response SHOULD NOT include a serverContextInfo 🙈
for attribute certificates, these wantBacks are defined in this document:
id-swb-ac-cert: The attribute certificate that was the subject of the request;id-swb-aa-cert-path: The certification path built for the AC issuer certificate;id-swb-ac-revocation-info: Proof of revocation status for each certificate in the AC issuer certification path; andid-swb-aa-revocation-info: Proof of revocation status for the attribute certificate.
conforming SCVP server implementations MAY support the attribute certificate wantBacks 🌈
this next one works for either public key or attribute certificates:
id-swb-relayed-responses: Any SCVP responses received by the server that were used to generate the response to this query.
conforming SCVP servers MAY support the id-swb-relayed-responses wantBack 🦋
for all of this, these OIDs are defined:
id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 }
id-swb-pkc-best-cert-path OBJECT IDENTIFIER ::= { id-swb 1 }
id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 }
id-swb-pkc-public-key-info OBJECT IDENTIFIER ::= { id-swb 4 }
id-swb-aa-cert-path OBJECT IDENTIFIER ::= { id-swb 5 }
id-swb-aa-revocation-info OBJECT IDENTIFIER ::= { id-swb 6 }
id-swb-ac-revocation-info OBJECT IDENTIFIER ::= { id-swb 7 }
id-swb-relayed-responses OBJECT IDENTIFIER ::= { id-swb 9 }
id-swb-pkc-cert OBJECT IDENTIFIER ::= { id-swb 10}
id-swb-ac-cert OBJECT IDENTIFIER ::= { id-swb 11}
id-swb-pkc-all-cert-paths OBJECT IDENTIFIER ::= { id-swb 12}
id-swb-pkc-ee-revocation-info OBJECT IDENTIFIER ::= { id-swb 13}
id-swb-pkc-CAs-revocation-info OBJECT IDENTIFIER ::= { id-swb 14}other specifications can define extra wantBacks too 🧁
conforming client implementations that support delegated path validation (DPV) as defined in [RQMTS] SHOULD support assertion of at least one wantBack. conforming client implementations that support delegated path discovery (DPD) as defined in [RQMTS] MUST support assertion of at least one wantBack. conforming clients MAY support assertion of multiple wantBacks. conforming clients need not support all of the wantBacks defined in this section 🫶
3.2.4. validationPolicy 📜
the validationPolicy item is where the client picks the validation policy it wants the SCVP server to use when validating certificates 👑 if the server can't use that policy for any reason, the server MUST return an error response 💀
a validation policy MUST define default values for every parameter needed to process an SCVP request. for each parameter, a validation policy can either let the client set a non-default value or forbid non-default values entirely 🍓 if the client is happy with all the defaults, it only needs to supply a reference to the policy in this item. if it wants non-default values for one or more parameters, it supplies the reference to the policy plus whatever parameters are needed to complete the request, all in this item. if the policy referenced in the request conflicts with any parameter values supplied in the request, the server MUST return an error response 🙅♀️
the syntax of the validationPolicy item is:
ValidationPolicy ::= SEQUENCE {
validationPolRef ValidationPolRef,
validationAlg [0] ValidationAlg OPTIONAL,
userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT
IDENTIFIER OPTIONAL,
inhibitPolicyMapping [2] BOOLEAN OPTIONAL,
requireExplicitPolicy [3] BOOLEAN OPTIONAL,
inhibitAnyPolicy [4] BOOLEAN OPTIONAL,
trustAnchors [5] TrustAnchors OPTIONAL,
keyUsages [6] SEQUENCE OF KeyUsage OPTIONAL,
extendedKeyUsages [7] SEQUENCE OF KeyPurposeId OPTIONAL,
specifiedKeyUsages [8] SEQUENCE OF KeyPurposeId OPTIONAL }the validationPolRef item is required, but everything else is optional 🎀 the optional items are there to provide validation policy parameters. when the client uses the policy's default values for everything, all of the optional items are absent ✨
at a minimum, conforming SCVP client implementations MUST support the validationPolRef item. conforming client implementations MAY support any or all of the optional items in ValidationPolicy 🌸
conforming SCVP servers MUST support processing a ValidationPolicy that contains any or all of the optional items 💪
the validationAlg item specifies the validation algorithm. the userPolicySet item gives an acceptable set of certificate policies. the inhibitPolicyMapping item inhibits certificate policy mapping during certification path validation. the requireExplicitPolicy item requires at least one valid certificate policy in the certificate policies extension. the inhibitAnyPolicy item says whether the anyPolicy certificate policy OID is processed or ignored when evaluating certificate policy. the trustAnchors item indicates which trust anchors are acceptable to the client. the keyUsages item indicates the technical usage of the public key that the server must confirm as acceptable. the extendedKeyUsages item indicates the application-specific usage of the public key that the server must confirm as acceptable. the syntax and semantics of each of these items are covered in the following sections 🧚
3.2.4.1. validationPolRef 🔑
the reference to the validation policy is an OID that the client and server have agreed represents a particular validation policy 🤝
the syntax of the validationPolRef item is:
ValidationPolRef::= SEQUENCE {
valPolId OBJECT IDENTIFIER,
valPolParams ANY DEFINED BY valPolId OPTIONAL }when a validation policy supports extra policy-specific parameter settings, those values go in the valPolParams item. the syntax and semantics of the parameters structure are defined by the object identifier encoded as the valPolId. when a validation policy has no parameters, like the default validation policy (see Section 3.2.4.1.1), this item MUST be omitted 🫧
parameters in this item are independent of the validation algorithm and the validation algorithm's parameters (see Section 3.2.4.2). for example, a server might support a validation policy that validates a certificate using the name validation algorithm and also makes a call on the creditworthiness of the subject. in that case, the validation policy parameters could be used to specify the value of the transaction. the validation algorithm parameters are used to specify the application identifier and name for the name validation algorithm 💅
conforming SCVP client implementations MUST support specification of a validation policy. conforming SCVP client implementations MAY be able to specify parameters for a validation policy. conforming SCVP server implementations MUST be able to process valPolId and MAY be able to process valPolParams 🥰
3.2.4.1.1. Default Validation Policy 💖
Okay so the client can ask the SCVP server for its default validation policy or for some other one 🎀 The default one lines up with standard certification path processing as defined in [PKIX-1], using server-chosen defaults (like a server-determined policy set and trust anchors) 🧚 Those defaults can be shared out of band or through the policy request mechanism (see Section 5). This is the iconic part: you can deploy an SCVP server without getting a brand new object identifier 🦋
The OID that identifies the default validation policy is:
id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 }
id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 }The default validation policy MUST use the basic validation algorithm as its default validation algorithm (see Section 3.2.4.2.1), and it has no validation policy parameters (see Section 3.2.4.1). 💅
When the client uses the default validation policy, it can override any of the default parameter values by sending a specific value in the request. The SCVP server MUST make use of the provided parameter values or return an error response. No ghosting the client, periodt 😭
Conforming implementations of SCVP servers MUST support the default policy. However, an SCVP server may be configured to send an error response to all requests using the default policy to meet local security requirements. 🔥
3.2.4.2. validationAlg ✨
The optional validationAlg item defines the validation algorithm the SCVP server uses during certificate validation. The value of this item can be decided by agreement between the client and the server. The validation algorithm is represented by an object identifier. 🌸
The syntax of the validationAlg item is:
ValidationAlg ::= SEQUENCE {
valAlgId OBJECT IDENTIFIER,
parameters ANY DEFINED BY valAlgId OPTIONAL }This section specifies the basic validation algorithm and the name validation algorithm. Both of them are the main characters here 👑
SCVP servers MUST recognize and support both validation algorithms defined in this section. SCVP clients that support explicit assertion of the validation algorithm MUST support the basic validation algorithm and SHOULD support the name validation algorithm. Other validation algorithms can be specified in other documents for use with specific applications. SCVP clients and servers MAY support any such validation algorithms. 🧚
3.2.4.2.1. Basic Validation Algorithm 🎀
The client can request the SCVP basic validation algorithm or some other algorithm. For identity certificates, the basic validation algorithm MUST implement the certification path validation algorithm as defined in Section 6 of [PKIX-1]. For attribute certificates, the basic validation algorithm MUST implement certification path validation as defined in Section 5 of [PKIX-AC]. Other validation algorithms MAY implement functions over and above those in the basic algorithm, but validation algorithms MUST generate results compliant with the basic validation algorithm. That is, none of the validation requirements in the basic algorithm may be omitted from any newly defined validation algorithms. However, other validation algorithms MAY reject paths that are valid using the basic validation algorithm. 🫶
The object identifier to identify the basic validation algorithm is:
id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 }When id-svp-basicValAlg appears in valAlgId, the parameters item MUST be absent. 🙈
3.2.4.2.2. Basic Validation Algorithm Errors 💀
These are the errors defined for the basic validation algorithm. They go in the validationErrors item in the response (see Section 4.9.6). Any other validation algorithm can use them too, since all validation algorithms MUST implement the functionality of the basic validation algorithm. Iykyk 🌈
id-bvae OBJECT IDENTIFIER ::= id-svp-basicValAlg
id-bvae-expired OBJECT IDENTIFIER ::= { id-bvae 1 }
id-bvae-not-yet-valid OBJECT IDENTIFIER ::= { id-bvae 2 }
id-bvae-wrongTrustAnchor OBJECT IDENTIFIER ::= { id-bvae 3 }
id-bvae-noValidCertPath OBJECT IDENTIFIER ::= { id-bvae 4 }
id-bvae-revoked OBJECT IDENTIFIER ::= { id-bvae 5 }
id-bvae-invalidKeyPurpose OBJECT IDENTIFIER ::= { id-bvae 9 }
id-bvae-invalidKeyUsage OBJECT IDENTIFIER ::= { id-bvae 10 }
id-bvae-invalidCertPolicy OBJECT IDENTIFIER ::= { id-bvae 11 }The id-bvae-expired value means the validation time used for the request was later than the notAfter time in the end certificate (the certificate specified in the queriedCerts item). ⏰
The id-bvae-not-yet-valid value means the validation time used for the request was before the notBefore time in the end certificate. 🍓
The id-bvae-wrongTrustAnchor value means a certification path could not be constructed for the client-specified trust anchor(s), but a path exists for one of the trust anchors specified in the server's default validation policy. 🦋
The id-bvae-noValidCertPath value means the server could not construct a sequence of intermediate certificates between the trust anchor and the target certificate that satisfied the request. 😭
The id-bvae-revoked value means the end certificate has been revoked. Rip 💀
The id-bvae-invalidKeyPurpose value means the extended key usage extension ([PKIX-1], Section 4.2.1.13) in the end certificate does not satisfy the validation policy. 🔥
The id-bvae-invalidKeyUsage value means the keyUsage extension ([PKIX-1], Section 4.2.1.3) in the end certificate does not satisfy the validation policy. For example, the keyUsage extension in the certificate may assert only the keyEncipherment bit, but the validation policy specifies in the keyUsages item that digitalSignature is required. 🙈
The id-bvae-invalidCertPolicy value means the path is not valid under any of the policies specified in the user policy set, and explicit policies are required. That is, the valid_policy_tree is NULL and the explicit_policy variable is zero ([PKIX-1], Section 6.1.5). 💅
3.2.4.2.3. Name Validation Algorithm 🌸
The name validation algorithm lets the client specify one or more subject names that MUST appear in the end certificate, on top of the requirements for the basic validation algorithm. The client supplies an application identifier and a name to the server. The application identifier defines the name matching rules used to compare the name in the request with the names in the certificate. 👑
id-svp-nameValAlg OBJECT IDENTIFIER ::= { id-svp 2 }When the id-svp-nameValAlg appears as a valAlgId, the parameters MUST use the NameValidationAlgParms syntax:
NameValidationAlgParms ::= SEQUENCE {
nameCompAlgId OBJECT IDENTIFIER,
validationNames GeneralNames }GeneralNames is defined in [PKIX-1]. 🧚
If more than one name is supplied in the validationNames value, all names MUST be of the same type. The certificate must contain a matching name for each of the names supplied in validationNames according to the name matching rules associated with the nameCompAlgId. This specification defines three sets of name matching rules. 🎀
If the nameCompAlgId supplied in the request is id-nva-dnCompAlg, then GeneralNames supplied in the request MUST be a directoryName, and the matching rules to be used are defined in [PKIX-1]. The certificate must contain a matching name in either the subject field or a directoryName in the subjectAltName extension. This specification defines the OID for id-nva-dnCompAlg as follows: 🫶
id-nva-dnCompAlg OBJECT IDENTIFIER ::= { id-svp 4 }If the nameCompAlgId supplied in the request is id-kp-serverAuth [PKIX-1], then GeneralNames supplied in the request MUST be a dNSName, and the matching rules to be used are defined in [PKIX-1]. 🌈
If a subjectAltName extension is present and includes one or more names of type dNSName, a match in any one of the set is considered acceptable. If the subjectAltName extension is omitted, or does not include any names of type dNSName, the (most specific) Common Name field in the subject field of the certificate MUST be used. ✨
Names may contain the wildcard character *, which is considered to match any single domain name component. That is, *.a.com matches foo.a.com but not bar.foo.a.com. 🍓
If the nameCompAlgId supplied in the request is id-kp-mailProtection [PKIX-1], then GeneralNames supplied in the request MUST be an rfc822Name, and the matching rules are defined in [SMIME-CERT]. 💜
Conforming SCVP servers MUST support the name validation algorithm and the matching rules associated with id-nva-dnCompAlg, id-kp-serverAuth, and id-kp-mailProtection. SCVP servers MAY support other name matching rules. 🔥
3.2.4.2.4. Name Validation Algorithm Errors 🙈
These are the errors defined for the name validation algorithm:
id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg
id-nvae-name-mismatch OBJECT IDENTIFIER ::= { id-nvae 1 }
id-nvae-no-name OBJECT IDENTIFIER ::= { id-nvae 2 }
id-nvae-unknown-alg OBJECT IDENTIFIER ::= { id-nvae 3 }
id-nvae-bad-name OBJECT IDENTIFIER ::= { id-nvae 4 }
id-nvae-bad-name-type OBJECT IDENTIFIER ::= { id-nvae 5 }
id-nvae-mixed-names OBJECT IDENTIFIER ::= { id-nvae 6 }The id-nvae-name-mismatch value means the client supplied a name with the request, which the server recognized, and the server found a corresponding name type in the certificate, but was unable to find a match for the name supplied. For example, the client supplied a DNS name of example1.com, and the certificate contained a DNS name of example.com. 😭
The id-nvae-no-name value means the client supplied a name with the request, which the server recognized, but the server could not find the corresponding name type in the certificate. For example, the client supplied a DNS name of example1.com, and the certificate only contained a rfc822Name of user@example.com. 💀
The id-nvae-unknown-alg value means the client supplied a nameCompAlgId that the server does not recognize. 🌸
The id-nvae-bad-name value means the client supplied either an empty or malformed name in the request. 🧚
The id-nvae-bad-name-type value means the client supplied an inappropriate name type for the application identifier. For example, the client specified a nameCompAlgId of id-kp-serverAuth, and an rfc822Name of user@example.com. 🎀
The id-nvae-mixed-names value means the client supplied multiple names in the request of different types. 🫶
3.2.4.3. userPolicySet 👑
The userPolicySet item specifies a list of certificate policy identifiers that the SCVP server MUST use when constructing and validating a certification path. The userPolicySet item specifies the user-initial-policy-set as defined in Section 6 of [PKIX-1]. A userPolicySet containing the anyPolicy OID indicates a user-initial-policy-set of any-policy. 🌈
SCVP clients SHOULD support the userPolicySet item in requests, and SCVP servers MUST support the userPolicySet item in requests. ✨
3.2.4.4. inhibitPolicyMapping ✨
okay so inhibitPolicyMapping is the knob that controls whether policy mapping is allowed during certification path validation 🦋 (see [PKIX-1], Section 6.1.1). if the client wants the server to inhibit policy mapping, it sets TRUE in the request 💅. SCVP clients MAY support inhibiting policy mapping. SCVP servers SHOULD support inhibiting policy mapping 🫶.
3.2.4.5. requireExplicitPolicy 🌸
requireExplicitPolicy is the one that decides whether there has to be at least one valid policy in the certificate policies extension (see [PKIX-1], Section 6.1.1) 🎀. if the client wants the server to require at least one policy, it sets TRUE in the request ✨.
SCVP clients MAY support requiring explicit policies. SCVP servers SHOULD support requiring explicit policies 💜.
3.2.4.6. inhibitAnyPolicy 👑
inhibitAnyPolicy is an input to the certification path validation algorithm (see [PKIX-1], Section 6.1.1), and it's giving "should the anyPolicy OID get processed or ignored when evaluating certificate policy?" 🙈. if the client wants the server to ignore the anyPolicy OID, inhibitAnyPolicy MUST be set to TRUE in the request.
SCVP clients MAY support ignoring the anyPolicy OID. SCVP servers SHOULD support ignoring the anyPolicy OID 🧚.
3.2.4.7. trustAnchors 🦋
trustAnchors lists the trust anchors where the certification path has to end if the server is going to call the path valid for this request 🌈. if a trustAnchors item is there, the server MUST NOT consider any certification paths ending in other trust anchors as valid. no exceptions, bestie 💀.
the TrustAnchors type holds one or more trust anchor specifications. you can point to a trust anchor with a certificate reference (certificate hash plus distinguished name with serial number), or you can just hand over the trust anchors directly 🍓. the order inside the sequence doesn't matter ✨. any CA certificate that meets the requirements of [PKIX-1] for signing certificates can be a trust anchor. if you give a trust anchor that doesn't meet those requirements, the server MUST return an error response 😭. and the trust anchor itself, however you provided it, MUST NOT be included in any certification path the SCVP server returns 🙅♀️.
TrustAnchors has this syntax:
TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF PKCReferenceSCVP servers MUST support trustAnchors. SCVP clients SHOULD support trustAnchors 💅.
3.2.4.8. keyUsages 🎀
the key usage extension ([PKIX-1], Section 4.2.1.3) tells you the technical purpose of the key in the certificate, like encipherment, signature, or CRL signing 🌸. if the client wants to confirm the technical usage, it can send the usage it wants to validate using the same structure and the same semantics as [PKIX-1] ✨. for example, if the client got the certificate for a digital signature, it can confirm that by including a keyUsage structure with the digital signature bit set 🫶.
if the keyUsages item is present and holds an empty sequence, that means the client doesn't require any particular key usage 🌈.
if the keyUsages item has one or more keyUsage definitions, the certificate MUST satisfy at least one of the specified keyUsage definitions 👑. if the client is cool with a few possibilities, it passes in a sequence of possible patterns 🧚. each keyUsage can hold a set of one or more bits, and all bits MUST be set in the certificate to match against an instance of the keyUsage in the SCVP request 💜. the certificate's key usage extension is allowed to have more usages than requested 🦋. for example, if a client wants to check for either digital signature or non-repudiation, it provides two keyUsage values: one with digital signature set and one with non-repudiation set 🍓. and if the key usage extension is missing from the certificate, the certificate MUST be considered good for all usages, so any pattern in the SCVP request will match 🌈.
SCVP clients SHOULD support keyUsages, and SCVP servers MUST support keyUsages ✨.
3.2.4.9. extendedKeyUsages 💅
the extended key usage extension ([PKIX-1], Section 4.2.1.13) defines more specific technical purposes, either on top of or instead of what the key usage extension says, for which the certified public key may be used 🌸. if the client will accept certificates that match a particular value (or values) in that extension, it can say so using the same semantics as [PKIX-1] 🎀.
for example, if the client got the certificate for a Transport Layer Security (TLS) server, it can check that the certificate fits that usage by including the extended key usage structure with the id-kp-serverAuth object identifier 🫶.
if the extension is absent, or it's present and asserts the anyExtendedKeyUsage OID, then all usages specified in the request count as a match 🙌. if the extension is present and does NOT assert the anyExtendedKeyUsage OID, then all usages in the request MUST be present in the certificate 😭. the certificate extension can have more usages than requested 🦋.
if the client doesn't need any particular extended key usage, it can send an empty SEQUENCE. this can be used to override extended key usage requirements set in the validation policy specified by valPolId 💜.
SCVP clients SHOULD support extendedKeyUsages, and SCVP servers MUST support extendedKeyUsages 👑.
3.2.4.10. specifiedKeyUsages 🧚
same vibe as the extended key usage one, but this time the client is the one being picky 💅. if the client requires that a particular value (or values) shows up in the extended key usage extension, it can specify those usages with the same semantics as [PKIX-1] 🌈. for example, if the client got the certificate for a TLS server, it might require the server certificate to include the extended key usage structure with the id-kp-serverAuth object identifier. in that case, the client includes a specifiedKeyUsages item in the request and asserts the id-kp-serverAuth object identifier 🍓.
if one or more specified usages are in the request, the certificate MUST contain the extended key usage extension, and all usages specified in the request MUST be present in that extension 🙈. the certificate extension can have more usages than the request asks for ✨. and specified key usages are NOT satisfied just because the anyExtendedKeyUsage OID is there 💀.
if the client doesn't require any particular extended key usage, it can send an empty SEQUENCE. this can be used to override specified key usage requirements set in the validation policy specified by valPolId 🫶.
SCVP clients SHOULD support specifiedKeyUsages, and SCVP servers MUST support specifiedKeyUsages 🔥.
3.2.5. responseFlags 🌸
the optional responseFlags item lets the client say which optional features in the CVResponse it wants the server to include 🎀. if the default values for all of the flags are used, then the responseFlags item MUST NOT be included in the request 🙅♀️.
the syntax of the responseFlags item looks like this:
ResponseFlags ::= SEQUENCE {
fullRequestInResponse [0] BOOLEAN DEFAULT FALSE,
responseValidationPolByRef [1] BOOLEAN DEFAULT TRUE,
protectResponse [2] BOOLEAN DEFAULT TRUE,
cachedResponse [3] BOOLEAN DEFAULT TRUE }each of the response flags gets its own section below 🦋.
3.2.5.1. fullRequestInResponse 💖
by default, the server includes a hash of the request in non-cached responses so the client can match up the response 🧚. if the client wants the full request in the non-cached response, it sets fullRequestInResponse to TRUE ✨. the main reason a client would want that is to archive the whole request-response exchange as a single object 📦. so one object holds both the request and the response, periodt 💅.
SCVP clients and servers MUST support the default behavior. SCVP clients MAY support requesting and processing the full request. SCVP servers SHOULD support returning the full request 👑.
3.2.5.2. responseValidationPolByRef 🌈
the responseValidationPolByRef item controls whether the response just has a reference to the policy, or a reference plus all the parameters of the policy used to process the request, by value 🎀. the response MUST contain a reference to the validation policy 🫶. if the client wants the validation policy parameters included by value too, responseValidationPolByRef is set to FALSE 🌸. the main reason a client would want the policy by value is again archiving, so the CVResponse has every single aspect of the validation policy inside it 💜.
SCVP clients MUST support requesting and processing the validation policy by reference, and SCVP servers MUST support returning the validation policy by reference 🔥. SCVP clients MAY support requesting and processing the validation policy by values. SCVP servers SHOULD support returning the validation policy by values ✨.
3.2.5.3. protectResponse 🛡️
the protectResponse item says whether the client requires the server to protect the response 🌈. if the client is doing full certification path validation on the response and doesn't care where the response came from, then it gets no benefit from a digital signature or MAC on the response 🙈. in that case, the client can tell the server that protecting the message is unnecessary 🍓. the server is always allowed to return a protected response anyway 💅.
SCVP clients that support delegated path discovery (DPD) as defined in [RQMTS] MUST support setting this value to FALSE 🧚.
SCVP clients that support delegated path validation (DPV) as defined in [RQMTS] need an authenticated response 🔐. unless a protected transport mechanism (such as TLS) is used, these clients MUST always set this value to TRUE or omit the responseFlags item entirely, which requires the server to return a protected response 😭.
SCVP servers MUST support returning protected responses, and SCVP servers SHOULD support returning unprotected responses 🫶. based on local policy, the server can be set up to return protected or unprotected responses when this value is FALSE ✨. but if, based on local policy, the server can't return protected responses, then it MUST return an error when this value is TRUE 💀.
3.2.5.4. cachedResponse 💖
okay so cachedResponse is the flag that says whether the client is cool getting a response that was saved from earlier 💅. An SCVP service can be built to cache responses until new revocation info is expected, which is lowkey genius because it boosts performance AND limits how much the signing keys get used 🔥. Where cachedResponse is set to TRUE, the client will accept a previously cached response.
Clients can totally insist on a brand new response to protect against a replay attack and make sure the info is up to date 🙈. Where cachedResponse is FALSE, the client will not accept a cached response. And to make sure a response is actually fresh, the client MUST also include the requestNonce as defined in Section 3.4 🫶.
Servers MUST process the cachedResponse flag 👑. Where cachedResponse is FALSE, servers that cannot produce fresh responses MUST reply with an error message. Servers MAY choose to provide fresh responses even where cachedResponse is set to TRUE ✨.
3.2.6. serverContextInfo 🧚
The optional serverContextInfo item, if present, holds context from a previous request-response exchange with the same SCVP server 🎀. It lets the server return more than one certification path for the same certificate. For example, if a server builds a certification path for a certificate but the client finds it unacceptable, the client can send the same query back with the serverContextInfo from the first response, and the server can provide a different certification path (if another one can be found) 🦋.
The contents of serverContextInfo are opaque to the SCVP client 🙈. The client only knows that it needs to return the value the server gave it with the next request to get a different certification path. Note that the subsequent query needs to be identical to the previous query with the exception of the following:
requestNonce,serverContextInfo, and- the client's digital signature or MAC on the request.
SCVP clients MAY support serverContextInfo, and SCVP servers SHOULD support serverContextInfo 💜.
3.2.7. validationTime ⏰
The optional validationTime item, if present, tells the date and time the SCVP client wants the server to perform the checks relative to 🌸. If the validationTime is not present, the server MUST perform the validation using the date and time at which the server processes the request. If the validationTime is present, it MUST be encoded as GeneralizedTime. The validationTime provided MUST be a retrospective time, since the server can only perform a validity check using the current time (default) or a previous time 💅. A server can ignore the validationTime provided in the request if the time is within the clock skew of the server's current time 😭.
The revocation status information is obtained with respect to the validation time 🔥. When specifying a validation time other than the current time, the validation time should not necessarily be identical to the time when the private key was used. The validation time specified by the client may be adjusted to compensate for:
- time for the end-entity to realize that its private key has been, or could possibly be, compromised, and/or
- time for the end-entity to report the key compromise, and/or
- time for the revocation authority to process the revocation request from the end-entity, and/or
- time for the revocation authority to update and distribute the revocation status information.
GeneralizedTime values MUST be expressed in Universal Coordinated Time (UTC) (which is also known as Greenwich Mean Time and Zulu time) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even when the number of seconds is zero. GeneralizedTime values MUST NOT include fractional seconds 🙅♀️.
The information in the corresponding CertReply item in the response MUST be formatted as if the server created the response at the time indicated in the validationTime. However, if the server does not have appropriate historical information, the server MUST return an error response 💀.
SCVP servers MUST apply a clock skew to the validation time to allow for minor time synchronization errors. The default value is 10 minutes. If the server uses a value other than the default, it MUST include the clock skew value in the validation policy response 🕰️.
SCVP clients MAY support validationTime other than the current time. SCVP servers MUST support using their current time, and SHOULD support the client setting the validationTime in the request 🌈.
3.2.8. intermediateCerts 🎀
The optional intermediateCerts item may help the SCVP server create valid certification paths 🧩. When present, it provides certificates that the server MAY use when forming a certification path. When building certification paths, the server MAY use the certificates in the intermediateCerts item in addition to any other certificates the server can access. When present, the intermediateCerts item MUST contain at least one certificate, and it MUST be structured as a CertBundle. The certificates in the intermediateCerts item MUST NOT be considered valid by the server just because they are present in this item 🙅♀️.
The CertBundle type contains one or more certificates. The order of the entries in the bundle is not important 🍓. CertBundle has the following syntax:
CertBundle ::= SEQUENCE SIZE (1..MAX) OF CertificateSCVP clients SHOULD support intermediateCerts, and SCVP servers MUST support intermediateCerts 🫶.
3.2.9. revInfos 🔍
The optional revInfos item specifies revocation information such as CRLs, delta CRLs [PKIX-1], and OCSP responses [OCSP] that the SCVP server MAY use when validating certification paths 🦋. The whole point of revInfos is to hand the server revocation information it might not otherwise have access to, like an OCSP response the client received along with the certificate. Note that the information in the revInfos item might not be used by the server. For example, the revocation information might be tied to certificates the server does not use in the certification path it constructs 🤷♀️.
Clients SHOULD be courteous to the SCVP server by separating CRLs and delta CRLs 🌸. However, since the two share a common syntax, SCVP servers SHOULD accept delta CRLs even if the SCVP client identifies them as regular CRLs 💅.
CRLs, delta CRLs, and OCSP responses can be provided as revocation information. If needed, additional object identifiers can be assigned for additional revocation information types in the future 🧚.
The revInfos item uses the RevocationInfos type, which has the following syntax:
RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo
RevocationInfo ::= CHOICE {
crl [0] CertificateList,
delta-crl [1] CertificateList,
ocsp [2] OCSPResponse,
other [3] OtherRevInfo }
OtherRevInfo ::= SEQUENCE {
riType OBJECT IDENTIFIER,
riValue ANY DEFINED BY riType }3.2.10. producedAt ⏳
The client MAY allow the server to use a cached SCVP response 🍓. When doing so, the client MAY use the producedAt item to express requirements on the freshness of the cached response. The producedAt item tells the earliest date and time at which an acceptable cached response could have been produced. It represents that date and time in UTC, using the GeneralizedTime type. The value in the producedAt item is independent of the validation time 💜.
GeneralizedTime value MUST be expressed in UTC, as defined in Section 3.2.7.
SCVP clients MAY support using producedAt values in the request. SCVP servers MAY support the producedAt values in the request. SCVP servers that support cached responses SHOULD support the producedAt value in requests 🌈.
3.2.11. queryExtensions 🧩
The optional queryExtensions item contains extensions 🎀. If present, each extension in the sequence extends the query. This specification does not define any extensions; the facility is provided to allow future specifications to extend SCVP. The syntax for Extensions is imported from [PKIX-1]. The queryExtensions item, when present, MUST contain a sequence of Extension items, and each of the extensions MUST contain extnID, critical, and extnValue items. Each of these is described in the following sections 👑.
3.2.11.1. extnID 🪪
The extnID item is an identifier for the extension. It contains the object identifier that names the extension 🦋.
3.2.11.2. critical 🚨
The critical item is a BOOLEAN. Each extension is designated as either critical (with a value of TRUE) or non-critical (with a value of FALSE). By default, the extension is non-critical. An SCVP server MUST reject the query if it encounters a critical extension that it does not recognize; however, a non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized 😤.
3.2.11.3. extnValue 📦
The extnValue item contains an OCTET STRING. Within the OCTET STRING is the extension value. An ASN.1 type is specified for each extension, identified by the associated extnID object identifier 🧠.
3.3. requestorRef 🌸
The optional requestorRef item contains a list of names identifying SCVP servers, and it is intended for use in environments where SCVP relay is employed. Although requestorRef is encoded as a SEQUENCE, no order is implied. The requestorRef item is used to detect looping in some configurations. The value and use of requestorRef are described in Section 7 🔁.
Conforming SCVP clients MAY support specification of the requestorRef value. Conforming SCVP server implementations MUST process the requestorRef value if present. If the SCVP client includes a requestorRef value in the request, then the SCVP server MUST return the same value in a non-cached response. The SCVP server MAY omit the requestorRef value from cached SCVP responses 💖.
The requestorRef item MUST be a sequence of GeneralName. No provisions are made to ensure uniqueness of the requestorRef GeneralName values 🫠.
3.4. requestNonce 🎀
okay so the optional requestNonce item is basically a little request ID that the SCVP client makes up itself 🧚 if the client includes one, it's saying "pls give me something fresh," and the SCVP server SHOULD return a non-cached response 💅 if the server does give a non-cached response, it MUST copy the requestNonce from the request into the response as the respNonce item ✨ BUT the server MAY also send back a cached response, and a cached response MUST NOT have a respNonce 🙈
SCVP clients that need a brand-new response (like to block a replay attack or make sure the info is up to date 👀) MUST support requestNonce 💖 and conforming SCVP servers MUST process the requestNonce value if it's there 🫶
if the client sends a requestNonce AND sets the cachedResponse flag to FALSE (see Section 3.2.5.4), it's basically saying the SCVP server MUST send back either a non-cached response with the respNonce or an error response 🔥 the client SHOULD put a requestNonce in every single request so an attacker can't pull a man-in-the-middle move by replaying old responses from the server 😭 and the requestNonce value SHOULD change with every request the client sends 🌈
the client MUST NOT set cachedResponse to FALSE without also including a requestNonce 🚫 and a server that gets a request like that SHOULD return an invalidRequest error response 💀
last bit: the requestNonce item, if present, MUST be an OCTET STRING that was generated exclusively for this request 🦋
3.5. requestorName 🍓
the optional requestorName item is how the client slips an identifier into the request 💜 the client MAY include this so the DPV server can copy it into the response ✨
conforming SCVP clients MAY support specifying this item in requests 🌸 and SCVP servers MUST be able to process requests that include it, no excuses 💅
3.6. responderName 🦋
the optional responderName item is the client telling the server which SCVP server it expects to sign the response, IF the response gets digitally signed 🖊️ the responderName item SHOULD only show up if:
- the request is either unprotected or digitally signed (i.e., is not protected using a MAC), and
- the responseFlags item is either absent or present with the protectResponse set to TRUE.
conforming SCVP clients MAY support specifying this item in requests 💖 SCVP servers MUST be able to process requests that include it 🫶 and SCVP servers that keep a single private key for signing SCVP responses, or that just can't return digitally signed responses at all, MAY ignore the value in this item 🤷♀️ SCVP servers that keep more than one private key for signing SCVP responses SHOULD do one of two things: (a) digitally sign the response with a private key that matches a certificate which includes the name given in responderName, either in the subject field or the subjectAltName extension, or (b) return a error indicating that the server does not possess a certificate that asserts the specified name 👑
3.7. requestExtensions 🧚
the OPTIONAL requestExtensions item holds extensions 🎀 if it's there, each extension in the sequence extends the request ✨ this spec doesn't define any extensions itself, it just leaves the door open so future specs can extend SCVP 🚪 the syntax for Extensions is imported from [PKIX-1] 📜 when requestExtensions is present, it MUST contain a sequence of Extension items, and each extension MUST contain the extnID, critical, and extnValue items 🔥 we'll break each of those down in the next sections 👀
3.7.1. extnID 🔑
the extnID item is the identifier for the extension 🏷️ it holds the object identifier that names the extension 💜
3.7.2. critical ⚠️
the critical item is a BOOLEAN 💅 every extension is marked either critical (TRUE) or non-critical (FALSE), and by default it's non-critical 🌈 an SCVP server MUST reject the query if it runs into a critical extension it doesn't recognize 🚫 a non-critical extension MAY be ignored if it isn't recognized, but it MUST be processed if it IS recognized 🙌
3.7.3. extnValue 🍓
the extnValue item contains an OCTET STRING, and inside that OCTET STRING sits the extension value 📦 each extension gets an ASN.1 type specified for it, and you find that type through the associated extnID object identifier 🔍
3.8. signatureAlg 🖋️
the signatureAlg item holds an AlgorithmIdentifier that tells the server which algorithm to use when it signs the response message ✍️ the signatureAlg item SHOULD only be included if:
- the request is either unprotected or digitally signed (i.e., is not protected using a MAC), and
- the responseFlags item is either absent or present with the protectResponse set to TRUE.
if it IS included, the signatureAlg item SHOULD specify one of the signature algorithms listed in the signatureGeneration item of the server's validation policy response message 💖
SCVP servers MUST be able to process requests that include this item 🫶 and if the server is sending back a digitally signed response to this message, then:
- if the
signatureAlgitem is present and names an algorithm that's included in the signatureGeneration item of the server's validation policy response message, the server MUST sign the response with the algorithm named insignatureAlg✨ - otherwise, if the
signatureAlgitem is absent, or is present but names an algorithm the server doesn't support, the server MUST sign the response with its default signature algorithm, as specified in the signatureGeneration item of the server's validation policy response message 🌸
3.9. hashAlg 🧁
the hashAlg item contains an object identifier that tells the server which hash algorithm to use for computing the hash value in the requestHash item of the response 💜 SCVP clients SHOULD NOT include this item if fullRequestInResponse is set to TRUE 🙅♀️ if it IS included, the hashAlg item SHOULD specify one of the hash algorithms listed in the hashAlgorithms item of the server's validation policy response message 🌈
SCVP servers MUST be able to process requests that include this item 💅 and if the server is sending a response to this message that includes a requestHash, then:
- if the
hashAlgitem is present and names an algorithm that's included in the hashAlgorithms item of the server's validation policy response message, the server MUST use the algorithm named inhashAlgto compute therequestHash🔥 - otherwise, if the
hashAlgitem is absent, or is present but names an algorithm the server doesn't support, the server MUST compute therequestHashwith its default hash algorithm, as specified in the hashAlgorithms item of the server's validation policy response message 🦋
3.10. requestorText 💬
SCVP clients MAY use the requestorText item to provide text that gets included in the matching response 🎀 for example, this field may describe the nature or reason for the request 🫶
conforming SCVP client implementations MAY support including this item in requests 💖 conforming SCVP server implementations MUST accept requests that include this item ✨ and when they generate non-cached responses, they MUST copy the contents of this item into the requestorText item in the corresponding response (see Section 4.13) 👑
3.11. SCVP Request Authentication 🔐
it's a matter of local policy which validation policy the server uses when it authenticates requests 🏠 when authenticating protected SCVP requests, SCVP servers SHOULD use the validation algorithm defined in Section 6 of [PKIX-1] 📜
if the certificate used to validate a SignedData validation request includes the key usage extension ([PKIX-1], Section 4.2.1.3), it MUST have the digital signature bit set, the non-repudiation bit set, or both bits set 🖊️
if the certificate used to validate an AuthenticatedData validation request includes the key usage extension, it MUST have the key agreement bit set 🔑
if the certificate used on a validation request contains the extended key usage extension ([PKIX-1], Section 4.2.1.13), the server SHALL verify that it contains the SCVP client OID, the anyExtendedKeyUsage OID, or another OID acceptable to the server 🧚 the SCVP client OID is defined as follows:
id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 }
id-kp-scvpClient OBJECT IDENTIFIER ::= { id-kp 16 }if a protected request fails to meet the validation policy of the server, it MUST be treated as an unauthenticated request 🌈💀
4. Validation Response ✨
okay so the server's answer to the client MUST be a single CVResponse item 💖. And when that CVResponse gets wrapped up in a MIME body part, application/scvp-cv-response MUST be used 🎀.
there are a bunch of different forms an SCVP response can take, so let's lay them out 💅
- A success response to a request that has
protectResponseset toFALSE. These responses SHOULD NOT be protected by the server. 🌸 - The server MUST protect all other success responses. If the server is unable to return a protected success response due to local policy, then it MUST return an error response. 🔥
- An error response to a request made over a protected transport such as TLS. These responses SHOULD NOT be protected by the server.
- An error response to a request that has
protectResponseset toFALSE. These responses SHOULD NOT be protected by the server. - An error response to an authenticated request. The server SHOULD protect these responses.
- An error response to an
AuthenticatedDatarequest where MAC is valid. The server MUST protect these responses. 🛡️ - All other error responses MUST NOT be protected by the server. 🚫
successful responses are the ones where the server fully complied with the request ✨. like, it was able to attempt building a certification path using the referenced or supplied validation policy, AND it could comply with all the requested parameters. if the server can't run validations with the required validation policy, or the request has an unsupported option, then the server MUST return an error response 😭.
for protected requests and responses, SCVP servers MUST support SignedData and SHOULD support AuthenticatedData 🔐. which types get used is a matter of local policy, so it's the server's call 🤷. where a protected response is required, SCVP servers MUST use SignedData or AuthenticatedData, even if the whole thing is already happening over a protected transport (like TLS) 🙈.
if the server is making a protected response to a protected request, then the server MUST use the same protection mechanism (SignedData or AuthenticatedData) as in the request 🦋.
an overview of the structure for an unprotected response is below. lots of details get skipped, but it clearly shows how SCVP uses CMS 👑
ContentInfo {
contentType id-ct-scvp-certValResponse,
-- (1.2.840.113549.1.9.16.1.11)
content CVResponse }the protected response is a CVResponse wrapped up in either a SignedData or an AuthenticatedData, which then gets wrapped in a ContentInfo 🎁. so the EncapsulatedContentInfo field of either one has an eContentType of id-ct-scvp-certValResponse and an eContent field holding a DER-encoded CVResponse 💜.
the SCVP server MUST include its own certificate in the certificates field within SignedData 📜. other certificates MAY also be included 🌈.
the SCVP server MAY also provide one or more CRLs in the crls field within SignedData 🗂️. the signerInfos field of SignedData MUST include exactly one SignerInfo. The SignedData MUST NOT include the unsignedAttrs field 🚫.
the signedAttrs field within SignerInfo MUST include the content-type and message-digest attributes defined in [CMS], and it SHOULD include the signing-certificate attribute as defined in [ESS] ✨. within the signing-certificate attribute, the first certificate identified in the sequence of certificate identifiers MUST be the certificate of the SCVP server 🪪. including other certificate identifiers in the signing-certificate attribute is OPTIONAL 🫶. including policies in the signing-certificate is OPTIONAL too.
the recipientInfos field of AuthenticatedData MUST include exactly one RecipientInfo, which contains info for the client that sent the request 💌. the AuthenticatedData MUST NOT include the unauthAttrs field 🙅.
the CVResponse item holds the server's response 🎉. it MUST contain the cvResponseVersion, serverConfigurationID, producedAt, and responseStatus items. it MAY also contain the respValidationPolicy, requestRef, requestorRef, requestorName, replyObjects, respNonce, serverContextInfo, and cvResponseExtensions items. the replyObjects item MUST contain exactly one CertReply item for each certificate requested 📦. the requestorRef item MUST be included if the request included a requestorRef item and a non-cached response is provided. the respNonce item MUST be included if the request included a requestNonce item and a non-cached response is provided 🎀.
The CVResponse MUST have the following syntax:
CVResponse ::= SEQUENCE {
cvResponseVersion INTEGER,
serverConfigurationID INTEGER,
producedAt GeneralizedTime,
responseStatus ResponseStatus,
respValidationPolicy [0] RespValidationPolicy OPTIONAL,
requestRef [1] RequestReference OPTIONAL,
requestorRef [2] GeneralNames OPTIONAL,
requestorName [3] GeneralNames OPTIONAL,
replyObjects [4] ReplyObjects OPTIONAL,
respNonce [5] OCTET STRING OPTIONAL,
serverContextInfo [6] OCTET STRING OPTIONAL,
cvResponseExtensions [7] Extensions OPTIONAL,
requestorText [8] UTF8String (SIZE (1..256)) OPTIONAL }conforming SCVP servers MAY be capable of constructing a CVResponse that includes the serverContextInfo or cvResponseExtensions items 🤓. conforming SCVP servers MUST be capable of constructing a CVResponse with any of the remaining optional items. conforming SCVP clients MUST be capable of processing a CVResponse with the following optional items: respValidationPolicy, requestRef, requestorName, replyObjects, and respNonce 📬.
conforming SCVP clients that are capable of including requestorRef in a request MUST be capable of processing a CVResponse that includes the requestorRef item 🧩. conforming SCVP clients MUST be capable of processing a CVResponse that includes the serverContextInfo or cvResponseExtensions items. conforming clients MUST be able to determine if critical extensions are present in the cvResponseExtensions item 🔍.
4.1. cvResponseVersion
the syntax and semantics of cvResponseVersion are the same as cvRequestVersion, as described in Section 3.1 ✨. the cvResponseVersion MUST match the cvRequestVersion in the request. if the server can't generate a response with a matching version number, then the server MUST return an error response that indicates the highest version number that the server supports as the version number 🫠.
4.2. serverConfigurationID
the server configuration ID item represents the version of the SCVP server configuration when it processed the request 🧚. see Section 6.4 for details 💖.
4.3. producedAt
the producedAt item tells the date and time at which the SCVP server generated the response ⏰. the producedAt item MUST be expressed in UTC, and it MUST be interpreted as defined in Section 3.2.7 🌍. this value is independent of the validation time ✨.
4.4. responseStatus ✨
Okay so the responseStatus item is basically the server's way of telling the SCVP client how its request went 💅 It has a numeric status code and an optional string. That string is a sequence of characters from the ISO/IEC 10646-1 character set, encoded with the UTF-8 transformation format from [UTF8].
The string MAY be used to transmit status information. The client MAY choose to display it to a human user. ngl the string might not help much, because there's often no way to know which languages a human user actually understands 🙈
The responseStatus item uses the ResponseStatus type, which looks like this:
ResponseStatus ::= SEQUENCE {
statusCode CVStatusCode DEFAULT okay,
errorMessage UTF8String OPTIONAL }
CVStatusCode ::= ENUMERATED {
okay (0),
skipUnrecognizedItems (1),
tooBusy (10),
invalidRequest (11),
internalError (12),
badStructure (20),
unsupportedVersion (21),
abortUnrecognizedItems (22),
unrecognizedSigKey (23),
badSignatureOrMAC (24),
unableToDecode (25),
notAuthorized (26),
unsupportedChecks (27),
unsupportedWantBacks (28),
unsupportedSignatureOrMAC (29),
invalidSignatureOrMAC (30),
protectedResponseUnsupported (31),
unrecognizedResponderName (32),
relayingLoop (40),
unrecognizedValPol (50),
unrecognizedValAlg (51),
fullRequestInResponseUnsupported (52),
fullPolResponseUnsupported (53),
inhibitPolicyMappingUnsupported (54),
requireExplicitPolicyUnsupported (55),
inhibitAnyPolicyUnsupported (56),
validationTimeUnsupported (57),
unrecognizedCritQueryExt (63),
unrecognizedCritRequestExt (64) }Here's what each CVStatusCode value means, bestie 🎀
0✨ The request was fully processed.1🦋 The request included some unrecognized non-critical extensions; however, processing was able to continue ignoring them.10🥲 Too busy; try again later.11The server was able to decode the request, but there was some other problem with the request.12An internal server error occurred.20The structure of the request was wrong.21The version of request is not supported by this server.22The request included unrecognized items, and the server was not able to continue processing.23The server could not validate the key used to protect the request.24The signature or message authentication code did not match the body of the request.25The encoding was not understood.26The request was not authorized.27The request included unsupported checks items, and the server was not able to continue processing.28The request included unsupported wantBack items, and the server was not able to continue processing.29The server does not support the signature or message authentication code algorithm used by the client to protect the request.30The server could not validate the client's signature or message authentication code on the request.31The server could not generate a protected response as requested by the client.32The server does not have a certificate matching the requested responder name.40The request was previously relayed by the same server.50The request contained an unrecognized validation policy reference.51The request contained an unrecognized validation algorithm OID.52The server does not support returning the full request in the response.53The server does not support returning the full validation policy by value in the response.54The server does not support the requested value for inhibit policy mapping.55The server does not support the requested value for require explicit policy.56The server does not support the requested value for inhibit anyPolicy.57The server only validates requests using current time.63The query item in the request contains a critical extension whose OID is not recognized.64The request contains a critical request extension whose OID is not recognized.
Status codes 0-9 are reserved for codes that indicate the request was processed by the server, and therefore MUST be sent in a success response. Status codes 10 and above indicate an error, and MUST therefore be sent in an error response.
4.5. respValidationPolicy 🌸
The respValidationPolicy item contains either a reference to the full validation policy, or the full policy by value, which the server used to validate the request. It MUST be present in success responses and MUST NOT be present in error responses. Whether the policy comes back by reference or by value is controlled by the responseValidationPolByRef item in the request. The resultant validation policy is the union of the following:
- Values from the request.
- For values that are not explicitly included in the request, values from the validation policy specified by reference in the request.
The RespValidationPolicy syntax is:
RespValidationPolicy ::= ValidationPolicyThe validationPolicy item is defined in Section 3.2.4. When responseValidationPolByRef is set to FALSE in the request, all items in the validationPolicy item MUST be populated. When responseValidationPolByRef is set to TRUE, OPTIONAL items in the validationPolicy item only need to be populated for the items whose value in the request differs from the value in the referenced validation policy.
Conforming SCVP clients MUST be capable of processing the validation policy by reference. SCVP clients MAY be capable of processing the optional items in the validation policy.
Conforming SCVP server implementations MUST be capable of asserting the policy by reference, and MUST be capable of including the optional items.
4.6. requestRef 🧚
The requestRef item lets the SCVP client figure out which request this response belongs to 🦋 It links the response to a particular request using either a hash of the request or a copy of the CVRequest from the request.
The requestRef item does not provide authentication, but it does let the client check that the request was not maliciously modified.
Basically, the requestRef item lets the client match a response to a request. The requestNonce is a different way to match requests and responses. When the fullRequest alternative is used, the response gives you one single data structure that's perfect for archiving the whole transaction 📦
The requestRef item uses the RequestReference type, which has the following syntax:
RequestReference ::= CHOICE {
requestHash [0] HashValue, -- hash of CVRequest
fullRequest [1] CVRequest }SCVP clients MUST support requestHash, and they MAY support fullRequest. SCVP servers MUST support using requestHash, and they SHOULD support using fullRequest.
4.6.1. requestHash 🔐
The requestHash item is the hash of the CVRequest. The one-way hash function used to compute the hash of the CVRequest is the one specified in Section 3.9. The requestHash item serves two purposes. First, it lets a client determine that the request was not maliciously modified. Second, it lets the client associate a response with a request when using connectionless protocols. The requestNonce is a different way to match requests and responses.
The requestHash item uses the HashValue type, which has the following syntax:
HashValue ::= SEQUENCE {
algorithm AlgorithmIdentifier DEFAULT { algorithm sha-1 },
value OCTET STRING }
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }The algorithm identifier for SHA-1 is imported from [PKIX-ALG]. It is repeated here for convenience.
4.6.2. fullRequest 🎀
Like requestHash, the fullRequest alternative lets a client determine that the request was not maliciously modified. It also gives you a single data structure that's suitable for archiving the transaction.
The fullRequest item uses the CVRequest type. The syntax and semantics of the CVRequest type are described in Section 3.
4.7. requestorRef 💜
The optional requestorRef item is used by the client to identify the original requestor in cases where SCVP relay is used. The value only has local significance to the client. If the SCVP client includes a requestorRef value in the request, then the SCVP server MUST return the same value if the server is generating a non-cached response.
4.8. requestorName 👑
The optional requestorName item is used by the server to return one or more identities associated with the client in the response.
The SCVP server MAY choose to include any or all of the following:
(1) the identity asserted by the client in the requestorName item of the request,
(2) an authenticated identity for the client from a certificate or other credential used to authenticate the request, or
(3) a client identifier from an out-of-band mechanism.
Alternatively, the SCVP server MAY omit this item.
In the case of non-cached responses to authenticated requests, the SCVP server SHOULD return a requestor name.
SCVP servers that support authenticated requests SHOULD support this item.
SCVP clients MUST be able to process responses that include this item, although the item value might not impact the processing in any manner. ✨
4.9. replyObjects 🎀
okay bestie, replyObjects is the part of the response that hands the good stuff back to the SCVP client 💖 each CertReply tells the client about a single certificate from the request. The replyObjects item MUST be present in the response, unless the response is reporting an error. ✨ The CertReply item MUST contain cert, replyStatus, replyValTime, replyChecks, and replyWantBacks items, and the CertReply item MAY contain the validationErrors, nextUpdate, and certReplyExtensions items.
A success response MUST contain one CertReply for each certificate specified in the queriedCerts item in the request. The order is important 👑 The first CertReply in the sequence MUST correspond to the first certificate in the request, the second CertReply in the sequence MUST correspond to the second certificate in the request, and so on.
The checks item in the request determines the content of the replyChecks item in the response. The wantBack item in the request determines the content of the replyWantBacks item in the response. The queryExtensions items in the request controls the absence or the presence and content of the certReplyExtensions item in the response. 🧚
The replyObjects item uses the ReplyObjects type, which has the following syntax:
ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply
CertReply ::= SEQUENCE {
cert CertReference,
replyStatus ReplyStatus DEFAULT success,
replyValTime GeneralizedTime,
replyChecks ReplyChecks,
replyWantBacks ReplyWantBacks,
validationErrors [0] SEQUENCE SIZE (1..MAX) OF
OBJECT IDENTIFIER OPTIONAL,
nextUpdate [1] GeneralizedTime OPTIONAL,
certReplyExtensions [2] Extensions OPTIONAL }4.9.1. cert
the cert item holds either the certificate or a reference to the certificate the client asked about 🦋 If the certificate was specified by reference in the request, the request included either the id-swb-pkc-cert or id-swb-aa-cert wantBack, and the server was able to obtain the referenced certificate, then this item MUST include the certificate. Otherwise, this item MUST include the same value as was used in the queriedCerts item in the request.
CertReference has the following syntax:
CertReference ::= CHOICE {
pkc PKCReference,
ac ACReference }4.9.2. replyStatus
the replyStatus item gives status info to the client about the request for that specific certificate 🌸 Note that the responseStatus item is different from the replyStatus item. The responseStatus item is the status of the whole request, while the replyStatus item is the status for the individual query item.
The replyStatus item uses the ReplyStatus type, which has the following syntax:
ReplyStatus ::= ENUMERATED {
success (0),
malformedPKC (1),
malformedAC (2),
unavailableValidationTime (3),
referenceCertHashFail (4),
certPathConstructFail (5),
certPathNotValid (6),
certPathNotValidNow (7),
wantBackUnsatisfied (8) }The meanings of the various ReplyStatus values are:
0Success: all checks were performed successfully.1Failure: the public key certificate was malformed.2Failure: the attribute certificate was malformed.3Failure: historical data for the requested validation time is not available.4Failure: the server could not locate the reference certificate or the referenced certificate did not match the hash value provided.5Failure: no certification path could be constructed.6Failure: the constructed certification path is not valid with respect to the validation policy.7Failure: the constructed certification path is not valid with respect to the validation policy, but a query at a later time may be successful.8Failure: all checks were performed successfully; however, one or more of the wantBacks could not be satisfied.
Codes 1 and 2 are used to tell the client that the request was properly formed, but the certificate in question was not. This is especially useful to clients that do not parse certificates. 🙈
Code 7 is used to tell the client that a valid certification path was found with the exception that a certificate in the path is on hold, current revocation information is unavailable, or the validation time precedes the notBefore time in one or more certificates in the path. 💀
For codes 1, 2, 3, and 4, the replyChecks and replyWantBacks items are not populated (i.e., they MUST be an empty sequence). For codes 5, 6, 7, and 8, replyChecks MUST include an entry corresponding to each check in the request; the replyWantBacks item is not populated.
4.9.3. replyValTime
the replyValTime item tells the time at which the information in the CertReply was correct ⏰ It represents the date and time in UTC, using GeneralizedTime type. The encoding rules for GeneralizedTime in Section 3.2.7 MUST be used.
Within the request, the optional validationTime item tells the date and time relative to which the SCVP client wants the server to perform the checks. If the validationTime is not present, the server MUST respond as if the client provided the date and time at which the server processes the request. 🍓
The information in the CertReply item MUST be formatted as if the server created this portion of the response at the time indicated in the validationTime item of the query. However, if the server does not have appropriate historical information, the server MAY either return an error or return information for a later time. 🌈
4.9.4. replyChecks
the replyChecks item holds the responses to the checks item in the query 🔥 It includes the object identifier (OID) from the query and an integer. The value of the integer indicates whether the requested check was successful. The OIDs in the checks item of the query are used to identify the corresponding replyChecks values. Each OID specified in the checks item in the request MUST be matched by an OID in the replyChecks item of the response. In the case of an error response, the server MAY include additional checks in the response to further explain the error. Clients MUST ignore any unrecognized ReplyCheck included in the response. 🫶
The replyChecks item uses the ReplyChecks type, which has the following syntax:
ReplyChecks ::= SEQUENCE OF ReplyCheck
ReplyCheck ::= SEQUENCE {
check OBJECT IDENTIFIER,
status INTEGER DEFAULT 0 }The status value for public key certification path building to a trusted root, { id-stc 1 }, can be one of the following:
0: Built a path
1: Could not build a pathThe status value for public key certification path building to a trusted root along with simple validation processing, { id-stc 2 }, can be one of the following:
0: Valid
1: Not validThe status value for public key certification path building to a trusted root along with complete status checking, { id-stc 3 }, can be one of the following:
0: Valid
1: Not valid
2: Revocation off-line
3: Revocation unavailable
4: No known source for revocation informationRevocation off-line means that the server or distribution point for the revocation information was connected to successfully without a network error but either no data was returned or if data was returned it was stale. Revocation unavailable means that a network error was returned when an attempt was made to reach the server or distribution point. No known source for revocation information means that the server was able to build a valid certification path but was unable to locate a source for revocation information for one or more certificates in the path. 🦋
The status value for AC issuer certification path building to a trusted root, { id-stc 4 }, can be one of the following:
0: Built a path
1: Could not build a pathThe status value for AC issuer certification path building to a trusted root along with simple validation processing, { id-stc 5 }, can be one of the following:
0: Valid
1: Not validThe status value for AC issuer certification path building to a trusted root along with complete status checking, { id-stc 6 }, can be one of the following:
0: Valid
1: Not valid
2: Revocation off-line
3: Revocation unavailable
4: No known source for revocation informationThe status value for revocation status checking of an AC as well as AC issuer certification path building to a trusted root along with complete status checking, { id-stc 7 }, can be one of the following:
0: Valid
1: Not valid
2: Revocation off-line
3: Revocation unavailable
4: No known source for revocation information4.9.5. replyWantBacks 🎀
okay so the replyWantBacks item is where the server hands back answers to everything you asked for in the wantBack item 🦋 each reply comes with the OID from your request plus an OCTET STRING holding the actual value. the OIDs are how you match each answer to the question you asked. the OIDs in replyWantBacks MUST match the OIDs in the wantBack item in the request 💅 and for a non-error response, replyWantBacks MUST include exactly one ReplyWantBack for each wantBack in the request. the only exception is id-swb-pkc-cert and id-swb-ac-cert, because that info lives in the cert item instead ✨
the replyWantBacks item uses the ReplyWantBacks type, and it looks like this:
ReplyWantBacks ::= SEQUENCE OF ReplyWantBack
ReplyWantBack::= SEQUENCE {
wb OBJECT IDENTIFIER,
value OCTET STRING }the OCTET STRING for the certification path used to verify the certificate in the request, { id-swb 1 }, holds a CertBundle. the syntax and semantics of CertBundle are in Section 3.2.8 🌸 this CertBundle has every certificate in the path, starting with the end certificate and finishing with the one issued by the trust anchor. main character certificate chain energy 👑
the OCTET STRING for the proof of revocation status, { id-swb 2 }, holds a RevInfoWantBack. RevInfoWantBack is a SEQUENCE of a RevocationInfos plus an optional CertBundle. RevocationInfos is described in Section 3.2.9 🧚 the CertBundle MUST be included if any certificates needed to validate the revocation info were not returned in the id-swb-pkc-best-cert-path or id-swb-pkc-all-cert-paths wantBack 😭 and when it is included, it MUST include all of those certificates. the order doesn't matter, so no ordering requirements 🙈
RevInfoWantBack ::= SEQUENCE {
revocationInfo RevocationInfos,
extraCerts CertBundle OPTIONAL }the OCTET STRING for the public key information, { id-swb 4 }, holds a SubjectPublicKeyInfo. its syntax and semantics are in [PKIX-1] ✨
the OCTET STRING for the AC issuer certification path used to verify the certificate in the request, { id-swb 5 }, holds a CertBundle too (see Section 3.2.8). this one starts with the AC issuer certificate and ends with the certificate issued by the trust anchor 🦋
the OCTET STRING for the proof of revocation status of the AC issuer certification path, { id-swb 6 }, holds a RevInfoWantBack. RevocationInfos is in Section 3.2.9. the CertBundle MUST be included if any certificates needed to validate the revocation info were not returned in the id-aa-cert-path wantBack, and it MUST include all such certificates. again, no ordering requirements 💖
the OCTET STRING for the proof of revocation status of the attribute certificate, { id-swb 7 }, also holds a RevInfoWantBack (RevocationInfos is in Section 3.2.9). the CertBundle MUST be included if any certificates needed to validate the revocation info were not returned in the id-swb-aa-cert-path wantBack, and it MUST include all such certificates, but there are no ordering requirements 🌈
the OCTET STRING for returning all paths, { id-swb 12 }, contains an ASN.1 type called CertBundles, which is defined below. CertBundle is in Section 3.2.8. each CertBundle holds every certificate in one path, starting with the end certificate and ending with the one from the trust anchor 🍓
CertBundles ::= SEQUENCE SIZE (1..MAX) OF CertBundlethe OCTET STRING for relayed responses, { id-swb 9 }, contains an ASN.1 type called SCVPResponses, defined below. if the SCVP server used info it got from other SCVP servers to build this response, then SCVPResponses MUST include each of the SCVP responses it received from them. if it didn't use info from other servers, then SCVPResponses MUST be an empty sequence 🫶
SCVPResponses ::= SEQUENCE OF ContentInfothe OCTET STRING for the proof of revocation status of the path's target certificate, { id-swb-13 }, holds a RevInfoWantBack (RevocationInfos is in Section 3.2.9). the CertBundle MUST be included if any certificates needed to validate the revocation info were not returned in the id-swb-pkc-best-cert-path or id-swb-pkc-all-cert-paths wantBack, and it MUST include all such certificates. no ordering requirements, bestie 💅
the OCTET STRING for the proof of revocation status of the intermediate certificates in the path, { id-swb 14 }, holds a RevInfoWantBack too (RevocationInfos is in Section 3.2.9). same deal: the CertBundle MUST be included if any certificates needed to validate the revocation info were not returned in the id-swb-pkc-best-cert-path or id-swb-pkc-all-cert-paths wantBack, and it MUST include all such certificates, with no ordering requirements 🌸
4.9.6. validationErrors ⚠️
the validationErrors item MUST only be present in failure responses 🙈 when it's there, it MUST contain one or more OIDs that say why validation failed. the validation errors for the basic validation algorithm and name validation algorithm are defined in Sections 3.2.4.2.2 and 3.2.4.2.4 💜 the validationErrors item SHOULD only be included when the replyStatus is 3, 5, 6, 7, or 8. SCVP servers are not required to list every reason validation failed, and SCVP clients MUST NOT assume that the OIDs in validationErrors are all of the validation errors for the certification path. so don't get too comfy with that list, babe 😭
4.9.7. nextUpdate ⏰
the nextUpdate item tells you when the server expects fresh info about whether the certificate is valid to be available. it's especially interesting when the certificate revocation status info isn't available or the certificate is suspended 👀 nextUpdate is a date and time in UTC, using the GeneralizedTime type, and the encoding rules for GeneralizedTime in Section 3.2.7 MUST be used 🎀
4.9.8. certReplyExtensions 🧩
the certReplyExtensions item holds the responses to the queryExtensions item in the request. it uses the Extensions type defined in [PKIX-1]. the OIDs in queryExtensions from the request are how you match each reply value to its question ✨ when it's present, certReplyExtensions is a sequence of Extension items, and each one has an extnID item, a critical item, and an extnValue item 🦋
the extnID item is the identifier for the extension. it holds the OID that names the extension, and it MUST match one of the OIDs in the queryExtensions item in the request 💖
the critical item is a BOOLEAN, and it MUST be set to FALSE 🙅♀️
the extnValue item is an OCTET STRING, and the extension value lives inside it. each extension has an ASN.1 type specified for it, identified by its extnID OID 🌈
4.10. respNonce 🔐
the respNonce item is the identifier that binds the request to the response, basically the glue between the two 🫶
if the client includes a requestNonce value in the request and the server is generating a specific non-cached response to it, then the server MUST return the same value in the response 💅
if the server is using a cached response to the request, then it MUST omit the respNonce item 🙈
if the server is returning a specific non-cached response to a request without a nonce, then the server MAY include a message-specific nonce. for digitally signed messages, the server MAY use the value of the message-digest attribute in the signedAttrs within SignerInfo of the request as the value in the respNonce item 🧚
the requestNonce item uses the OCTET STRING type 🍓
conforming client implementations MUST be able to process a response that includes this item. conforming servers MUST support respNonce. no excuses, it's a must-have 👑
4.11. serverContextInfo 🧭
the serverContextInfo item in a response is how the server slips some opaque context info to the client. if the client doesn't like the certification path it got back, it can send a new query and pass this context info along 🦋
Section 3.2.6 has the details on how the client uses this item 📖
the context info is opaque to the client, but it tells the server to make sure a different certification path comes back (if one can be found). it could describe the state of the server, or it could hold a sequence of hashes of certification paths that were already sent to the client. the protocol doesn't dictate any structure or requirements for this item. implementers should review the Security Considerations section of this document before picking a structure, so please go read it first, fr fr 🔥
servers that can't return additional paths MUST NOT include the serverContextInfo item in the response 🙅♀️
4.12. cvResponseExtensions 🌟
if it's present, the cvResponseExtensions item holds a sequence of extensions that extend the response. this specification doesn't define any extensions. the facility is there so future specifications can extend SCVP 🔮 the syntax for Extensions is imported from [PKIX-1]. when it's present, cvResponseExtensions is a sequence of Extension items, and each one has an extnID item, a critical item, and an extnValue item ✨
the extnID item is an identifier for the extension. it contains the object identifier (OID) that names the extension 💜
the critical item is a BOOLEAN. each extension is either critical (TRUE) or non-critical (FALSE). an SCVP client MUST reject the response if it hits a critical extension it doesn't recognize, but a non-critical extension MAY be ignored if it isn't recognized 😭 the rule is basically: critical means don't skip it, non-critical means skipping is okay 🎀
the extnValue item is an OCTET STRING, with the extension value inside. each extension has an ASN.1 type specified for it, identified by the associated extnID OID 💖
4.13. requestorText 🎀
okay so requestorText is the client's little note-to-self 📝 It's a text field the client can slip into a request.
If the client includes a requestorText value and the server is cooking up a specific, non-cached response for that exact request, the server MUST send back the same value in the response. Same text, no glow-up 💅
If the server is handing out a cached response instead, it MUST omit the requestorText item 🙈
The requestNonce item uses the UTF8 string type.
quick heads up: this line talks about requestNonce even though it lives in the requestorText section, so I'm keeping it exactly as the original has it 🫶
Conforming client implementations that support the requestorText item in requests (see Section 3.10) MUST be able to process a response that includes this item. Conforming servers MUST support requestorText in responses ✨
4.14. SCVP Response Validation 🦋
there are two ways to validate SCVP responses bestie 👑 One is based on the client knowing a specific SCVP server key. The other is based on validating the certificate that goes with the private key used to protect the SCVP response. Two paths, both iconic.
4.14.1. Simple Key Validation
simple key validation is where the SCVP client has a local policy of one or more SCVP server keys that directly identify the set of valid SCVP servers 🔑 How the client stores those keys or identifiers is a local matter. For example, a client could store cryptographic hashes of public keys used to verify SignedData responses. Or, a client could store shared symmetric keys used to verify MACs in AuthenticatedData responses.
Simple key validation MUST be used by SCVP clients that cannot validate PKIX-1 certificates and are therefore making delegated path validation requests to the SCVP server [RQMTS]. It's a matter of local policy with these clients whether to use SignedData or AuthenticatedData. Simple key validation MAY be used by other SCVP clients for other reasons 🌸
4.14.2. SCVP Server Certificate Validation
what validation policy the client uses when validating responses is a matter of local policy, so it's totally up to the client 💅 When validating protected SCVP responses, SCVP clients SHOULD use the validation algorithm defined in Section 6 of [PKIX-1]. SCVP clients may impose additional limitations on the algorithm, such as limiting the number of certificates in the path or establishing initial name constraints, as specified in Section 6.2 of [PKIX-1] 🧚
If the certificate used to sign the validation policy responses and SignedData validation responses contains the key usage extension ([PKIX-1], Section 4.2.1.3), it MUST have either the digital signature bit set, the non-repudiation bit set, or both bits set.
If the certificate for AuthenticatedData validation responses contains the key usage extension, it MUST have the key agreement bit set.
If the certificate used on a validation policy response or a validation response contains the extended key usage extension ([PKIX-1], Section 4.2.1.13), it MUST contain either the anyExtendedKeyUsage OID or the following OID:
id-kp-scvpServer OBJECT IDENTIFIER ::= { id-kp 15 }5. Server Policy Request 🌈
an SCVP client uses the ValPolRequest item to ask about an SCVP server's policies and configuration info, including the list of validation policies the server supports 🔍 When a ValPolRequest is encapsulated in a MIME body part, it MUST be carried in an application/scvp-vp-request MIME body part.
The request is a ValPolRequest wrapped up in a ContentInfo. The client does not sign the request 🤍
ContentInfo {
contentType id-ct-scvp-valPolRequest,
-- (1.2.840.113549.1.9.16.1.12)
content ValPolRequest }the ValPolRequest type has this syntax:
ValPolRequest ::= SEQUENCE {
vpRequestVersion INTEGER DEFAULT 1,
requestNonce OCTET STRING }Conforming SCVP server implementations MUST recognize and process the server policy request. Conforming clients SHOULD support the server policy request ✨
5.1. vpRequestVersion
the syntax and semantics of vpRequestVersion are the same as cvRequestVersion, as described in Section 3.1 🦋
5.2. requestNonce
the requestNonce item holds a request identifier generated by the SCVP client. If the server returns a specific response, it MUST include the requestNonce from the request in the response. The server MAY return a cached response, which MUST NOT include a requestNonce 🔥
6. Validation Policy Response 💜
when a client sends a ValPolRequest, the SCVP server answers with a ValPolResponse 💌 The ValPolResponse doesn't have to be unique to any one ValPolRequest, so the server can reuse it for multiple ValPolRequests. It also tells you how often it can be reissued. The server MUST sign the response using its digital signature certificate. When a ValPolResponse is encapsulated in a MIME body part, it MUST be carried in an application/scvp-vp-response MIME body part.
The response is a ValPolResponse wrapped in a SignedData, which is then wrapped in a ContentInfo. So the EncapsulatedContentInfo field of SignedData has an eContentType field set to id-ct-scvp-valPolResponse (1.2.840.113549.1.9.16.1.13), and an eContent field that holds a DER-encoded ValPolResponse. The SCVP server MUST include its own certificate in the certificates field within SignedData, and the signerInfos field of SignedData MUST include exactly one SignerInfo. The SignedData MUST NOT include the unsignedAttrs field 🧾
the ValPolResponse type has this syntax:
ValPolResponse ::= SEQUENCE {
vpResponseVersion INTEGER,
maxCVRequestVersion INTEGER,
maxVPRequestVersion INTEGER,
serverConfigurationID INTEGER,
thisUpdate GeneralizedTime,
nextUpdate GeneralizedTime OPTIONAL,
supportedChecks CertChecks,
supportedWantBacks WantBack,
validationPolicies SEQUENCE OF OBJECT IDENTIFIER,
validationAlgs SEQUENCE OF OBJECT IDENTIFIER,
authPolicies SEQUENCE OF AuthPolicy,
responseTypes ResponseTypes,
defaultPolicyValues RespValidationPolicy,
revocationInfoTypes RevocationInfoTypes,
signatureGeneration SEQUENCE OF AlgorithmIdentifier,
signatureVerification SEQUENCE OF AlgorithmIdentifier,
hashAlgorithms SEQUENCE SIZE (1..MAX) OF
OBJECT IDENTIFIER,
serverPublicKeys SEQUENCE OF KeyAgreePublicKey
OPTIONAL,
clockSkew INTEGER DEFAULT 10,
requestNonce OCTET STRING OPTIONAL }
ResponseTypes ::= ENUMERATED {
cached-only (0),
non-cached-only (1),
cached-and-non-cached (2) }
RevocationInfoTypes ::= BIT STRING {
fullCRLs (0),
deltaCRLs (1),
indirectCRLs (2),
oCSPResponses (3) }SCVP clients that support validation policy requests MUST support validation policy responses. SCVP servers MUST support validation policy responses 🫶
SCVP servers MUST support cached policy responses and MAY support specific responses to policy requests ✨
6.1. vpResponseVersion
the syntax and semantics of vpResponseVersion are the same as cvRequestVersion, as described in Section 3.1. The vpResponseVersion used MUST be the same as the vpRequestVersion, unless the client has used a value greater than the values the server supports. If the client submits a vpRequestVersion greater than the version supported by the server, the server MUST return a vpResponseVersion using the highest version number the server supports as the version number 🔢
6.2. maxCVRequestVersion
the maxCVRequestVersion item defines the maximum version number for CV requests that the server supports 💖
6.3. maxVPRequestVersion
the maxVPRequestVersion item defines the maximum version number for VP requests that the server supports 💖
6.4. serverConfigurationID
the serverConfigurationID item is an integer that uniquely represents the version of the server configuration, as represented by the validationPolicies, validationAlgs, authPolicies, defaultPolicyValues, and clockSkew. If any of these values change, the server MUST create a new ValPolResponse with a new serverConfigurationID. If the configuration hasn't changed, the server may reuse serverConfigurationID across multiple ValPolResponse messages. However, if the server reverts to an earlier configuration, the server MUST NOT revert the configuration ID as well, but MUST select another unique value 🌀
6.5. thisUpdate
this item indicates the signing date and time of this policy response 🕰️
GeneralizedTime values MUST be expressed in Greenwich Mean Time (Zulu) and interpreted as defined in Section 3.2.7.
6.6. nextUpdate and requestNonce
these items are used to indicate whether policy responses are specific to policy requests 👀 Where policy responses are cached, these items indicate when the information will be updated. The optional nextUpdate item indicates the time by which the next policy response will be published. The optional requestNonce item links the response to a specific request by returning the nonce provided in the request.
If the nextUpdate item is omitted, it indicates a non-cached response generated in response to a specific request (i.e., the ValPolResponse is bound to a specific request). If this item is omitted, the requestNonce item MUST be present and MUST include the requestNonce value from the request.
If the nextUpdate item is present, it indicates a cached response that is not bound to a specific request. An SCVP server MUST periodically generate a new response as defined by the next update time, but MAY use the same ValPolResponse to respond to multiple requests. The requestNonce is omitted if the nextUpdate item is present.
It is a matter of local server policy to return a cached or non-cached specific response 🤷♀️
GeneralizedTime values in nextUpdate MUST be expressed in Greenwich Mean Time (Zulu) as specified in Section 3.2.7.
6.7. supportedChecks
the supportedChecks item contains a sequence of object identifiers representing the checks supported by the server ✅
6.8. supportedWantBacks
the supportedWantBacks item contains a sequence of object identifiers representing the wantBacks supported by the server 🎁
6.9. validationPolicies
the validationPolicies item contains a sequence of object identifiers representing the validation policies the server supports. It's a matter of local policy whether the server wants to process requests using the default validation policy. If it doesn't, then it MUST NOT include the id-svp-defaultValPolicy in this list 🚫
6.10. validationAlgs
the validationAlgs item contains a sequence of OIDs. Each OID identifies a validation algorithm supported by the server 🧠
6.11. authPolicies 🔐
okay so authPolicies is the server's little list of authentication policy references 💅 each entry is an OID that the client and server have both agreed means "this is an authentication policy." the whole point is to let the client see whether some requests need authentication, and if they do, how 🧚
AuthPolicy ::= OBJECT IDENTIFIER6.12. responseTypes 🎀
the responseTypes item is how the server shows off what kinds of responses it can give 🦋 "Cached only" means the server will only ever return cached responses. "Non-cached only" means it returns a specific response to the request, i.e., one containing the requestor's nonce. "Both" means it supports both, and it'll send back either a cached or a non-cached response depending on the request. iconic range 🌈
6.13. revocationInfoTypes 🌸
the revocationInfoTypes item lets the server say which sources of revocation information it can actually process 🔍 for each bit in the RevocationInfoTypes BIT STRING, the server MUST set the bit to one if it can process that revocation information type, and to zero if it can't. no guessing, just bits 🤓
6.14. defaultPolicyValues 👑
this is the default validation policy the server uses 💖 it holds a RespValidationPolicy, which is defined in Section 4.5. all OPTIONAL items in the validationPolicy item MUST be populated. the server uses these defaults when a request references the default validation policy and the client doesn't override them by supplying its own values.
this lets the client optimize the request by leaving out any parameters that already match the server's default values. less typing, more slay ✨
6.15. signatureGeneration ✍️
this sequence lists the digital signature algorithms an SCVP server supports for signing CVResponse messages 💌 each algorithm is written as an AlgorithmIdentifier, using the encoding rules tied to the signatureAlgorithm field in a public key certificate [PKIX-1]. supported algorithms are defined in [PKIX-ALG] and [PKIX-ALG2], but other signature algorithms may also be supported 🫶
by including an algorithm (e.g., RSA with SHA-1) in this list, the server is saying it has a private key and a matching certified public key for that asymmetric algorithm, and that it supports the specified hash algorithm 🔑 the list is ordered, and the first digital signature algorithm is the server's default. that default is what the server uses to protect signed messages unless the client picks a different algorithm.
for servers that don't have an on-line private key and therefore can't sign CVResponse messages, the signatureGeneration item is encoded as an empty sequence 🫠
6.16. signatureVerification 🔎
this sequence lists the digital signature algorithms this SCVP server can verify 🕵️♀️ each one is written as an AlgorithmIdentifier, using the encoding rules tied to the signatureAlgorithm field in a public key certificate [PKIX-1]. supported algorithms are defined in [PKIX-ALG] and [PKIX-ALG2], but other signature algorithms may also be supported.
for servers that don't verify signatures on CVRequest messages, the signatureVerification item is encoded as an empty sequence 💀
6.17. hashAlgorithms #️⃣
this sequence lists the hash algorithms the server can use to hash certificates and requests 🧁 the list is ordered, and the first hash algorithm is the server's default. the default is what the server uses to compute hashes included in responses, unless the client asks for a different algorithm.
each hash algorithm is written as an object identifier. [PKIX-ALG2] gives object identifiers for SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. other hash algorithms may also be supported 🌷
6.18. serverPublicKeys 🗝️
the serverPublicKeys item is a sequence of one or more key agreement public keys plus their parameters 💜 clients use it when they make AuthenticatedData requests to the server. each entry in the serverPublicKeys sequence is a KeyAgreePublicKey:
KeyAgreePublicKey ::= SEQUENCE {
algorithm AlgorithmIdentifier,
publicKey BIT STRING,
macAlgorithm AlgorithmIdentifier,
kDF AlgorithmIdentifier OPTIONAL }the KeyAgreePublicKey holds the algorithm identifier and the server's public key 🎀 SCVP servers that support the key agreement mode of AuthenticatedData for SCVP requests MUST support serverPublicKeys and the Diffie-Hellman key agreement algorithm as specified in [PKIX-ALG]. SCVP servers that support serverPublicKeys MUST support the 1024-bit Modular Exponential (MODP) group key (group 2) as defined in [IKE]. SCVP servers that support serverPublicKeys MAY support other Diffie-Hellman groups [IKE-GROUPS], as well as other key agreement algorithms 🌈
the macAlgorithm item says which symmetric algorithm the server expects the client to use with the result of the key agreement algorithm 🔐 a key derivation function (KDF), which turns the key agreement result into symmetric key material, may be implied by the macAlgorithm. or, the KDF can be spelled out explicitly with the optional kDF item.
6.19. clockSkew ⏰
the clockSkew item is the number of minutes the server will allow for clock skew 🕰️ the default value is 10 minutes. bestie, that's the whole thing ✨
7. SCVP Server Relay 🔁
okay this one is giving network drama 🍿 in some network environments, especially ones with firewalls, an SCVP server might not be able to get all the info it needs to process a request. but the server might be set up to lean on one or more other SCVP servers to fulfill requests 💁♀️ in that case the SCVP client has no idea the first server is handing work off to other servers. that first server acts as a client to another SCVP server. unlike the original client, this server is expected to have moderate computing and memory resources 💪
this section covers SCVP server-to-SCVP server exchanges. it doesn't impose any requirements on SCVP clients that aren't also SCVP servers. it also doesn't impose any requirements on SCVP servers that don't relay requests to other SCVP servers 🫶
when one SCVP server relays a request to another, in a badly configured system of servers, it's possible that the same request gets relayed right back again 😭 which is why any SCVP server that relays requests MUST implement the conventions described in this section to detect and break loops. no infinite ping-pong, please 🙅♀️
when an SCVP server relays a request, the request MUST include the requestorRef item. if the request being relayed already has a requestorRef item, then the server-generated request MUST contain a requestorRef item built from that value plus an extra GeneralName that identifies the SCVP server. if the request being relayed doesn't have a requestorRef item, then the server-generated request MUST contain a requestorRef item that includes a GeneralName identifying the SCVP server 🧚
to avoid false loop detection, servers should use identifiers that are unique within their network of cooperating SCVP servers 🦋 SCVP servers that support relay SHOULD fill this item with the DNS name of the server or the distinguished name from the server's certificate. SCVP servers MAY choose other procedures for generating identifiers that are unique within their community. mix and match, as long as it's unique 💅
when an SCVP server receives a request containing a requestorRef item, the server MUST check the sequence of names in the requestorRef item for its own identifier. if it finds its own identifier there, it MUST respond with an error, setting the statusCode in the responseStatus item to 40. caught in the loop, respond with a 40 🚫
when an SCVP server generates a non-cached response to a relayed request, the server MUST include the requestorRef item from the request in the response 🎀
8. SCVP ASN.1 Module 🧩
this section defines the syntax for SCVP request-response pairs 🌸 the semantics for the messages live in Sections 3, 4, 5, and 6. here's the SCVP ASN.1 module:
SCVP
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) 21 }
DEFINITIONS IMPLICIT TAGS ::= BEGIN
IMPORTS
AlgorithmIdentifier, Attribute, Certificate, Extensions,
-- Import UTF8String if required by compiler
-- UTF8String, -- CertificateList, CertificateSerialNumber
FROM PKIX1Explicit88 -- RFC 3280
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) 18 }
GeneralNames, GeneralName, KeyUsage, KeyPurposeId
FROM PKIX1Implicit88 -- RFC 3280
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) 19 }
AttributeCertificate
FROM PKIXAttributeCertificate -- RFC 3281
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) 12 }
OCSPResponse
FROM OCSP -- RFC 2560
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) 14 }
ContentInfo
FROM CryptographicMessageSyntax2004 -- RFC 3852
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } ;
-- SCVP Certificate Validation Request
id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9)
id-smime(16) 1 }
id-ct-scvp-certValRequest OBJECT IDENTIFIER ::= { id-ct 10 }
CVRequest ::= SEQUENCE {
cvRequestVersion INTEGER DEFAULT 1,
query Query,
requestorRef [0] GeneralNames OPTIONAL,
requestNonce [1] OCTET STRING OPTIONAL,
requestorName [2] GeneralName OPTIONAL,
responderName [3] GeneralName OPTIONAL,
requestExtensions [4] Extensions OPTIONAL,
signatureAlg [5] AlgorithmIdentifier OPTIONAL,
hashAlg [6] OBJECT IDENTIFIER OPTIONAL,
requestorText [7] UTF8String (SIZE (1..256)) OPTIONAL }
Query ::= SEQUENCE {
queriedCerts CertReferences,
checks CertChecks,
wantBack [1] WantBack OPTIONAL,
validationPolicy ValidationPolicy,
responseFlags ResponseFlags OPTIONAL,
serverContextInfo [2] OCTET STRING OPTIONAL,
validationTime [3] GeneralizedTime OPTIONAL,
intermediateCerts [4] CertBundle OPTIONAL,
revInfos [5] RevocationInfos OPTIONAL,
producedAt [6] GeneralizedTime OPTIONAL,
queryExtensions [7] Extensions OPTIONAL }
CertReferences ::= CHOICE {
pkcRefs [0] SEQUENCE SIZE (1..MAX) OF PKCReference,
acRefs [1] SEQUENCE SIZE (1..MAX) OF ACReference }
CertReference::= CHOICE {
pkc PKCReference,
ac ACReference }
PKCReference ::= CHOICE {
cert [0] Certificate,
pkcRef [1] SCVPCertID }
ACReference ::= CHOICE {
attrCert [2] AttributeCertificate,
acRef [3] SCVPCertID }
SCVPCertID ::= SEQUENCE {
certHash OCTET STRING,
issuerSerial SCVPIssuerSerial,
hashAlgorithm AlgorithmIdentifier DEFAULT { algorithm sha-1 } }Okay bestie, we're still in the ASN.1 module, and this part is all about the structures that the validation policies, responses, and check identifiers are built from 🧚✨
SCVPIssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
ValidationPolicy ::= SEQUENCE {
validationPolRef ValidationPolRef,
validationAlg [0] ValidationAlg OPTIONAL,
userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT
IDENTIFIER OPTIONAL,
inhibitPolicyMapping [2] BOOLEAN OPTIONAL,
requireExplicitPolicy [3] BOOLEAN OPTIONAL,
inhibitAnyPolicy [4] BOOLEAN OPTIONAL,
trustAnchors [5] TrustAnchors OPTIONAL,
keyUsages [6] SEQUENCE OF KeyUsage OPTIONAL,
extendedKeyUsages [7] SEQUENCE OF KeyPurposeId OPTIONAL,
specifiedKeyUsages [8] SEQUENCE OF KeyPurposeId OPTIONAL }
CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
ValidationPolRef ::= SEQUENCE {
valPolId OBJECT IDENTIFIER,
valPolParams ANY DEFINED BY valPolId OPTIONAL }
ValidationAlg ::= SEQUENCE {
valAlgId OBJECT IDENTIFIER,
parameters ANY DEFINED BY valAlgId OPTIONAL }
NameValidationAlgParms ::= SEQUENCE {
nameCompAlgId OBJECT IDENTIFIER,
validationNames GeneralNames }
TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF PKCReference
KeyAgreePublicKey ::= SEQUENCE {
algorithm AlgorithmIdentifier,
publicKey BIT STRING,
macAlgorithm AlgorithmIdentifier,
kDF AlgorithmIdentifier OPTIONAL }
ResponseFlags ::= SEQUENCE {
fullRequestInResponse [0] BOOLEAN DEFAULT FALSE,
responseValidationPolByRef [1] BOOLEAN DEFAULT TRUE,
protectResponse [2] BOOLEAN DEFAULT TRUE,
cachedResponse [3] BOOLEAN DEFAULT TRUE }
CertBundle ::= SEQUENCE SIZE (1..MAX) OF Certificate
RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo
RevocationInfo ::= CHOICE {
crl [0] CertificateList,
delta-crl [1] CertificateList,
ocsp [2] OCSPResponse,
other [3] OtherRevInfo }
OtherRevInfo ::= SEQUENCE {
riType OBJECT IDENTIFIER,
riValue ANY DEFINED BY riType }
-- SCVP Certificate Validation Response
id-ct-scvp-certValResponse OBJECT IDENTIFIER ::= { id-ct 11 }
CVResponse ::= SEQUENCE {
cvResponseVersion INTEGER,
serverConfigurationID INTEGER,
producedAt GeneralizedTime,
responseStatus ResponseStatus,
respValidationPolicy [0] RespValidationPolicy OPTIONAL,
requestRef [1] RequestReference OPTIONAL,
requestorRef [2] GeneralNames OPTIONAL,
requestorName [3] GeneralNames OPTIONAL,
replyObjects [4] ReplyObjects OPTIONAL,
respNonce [5] OCTET STRING OPTIONAL,
serverContextInfo [6] OCTET STRING OPTIONAL,
cvResponseExtensions [7] Extensions OPTIONAL,
requestorText [8] UTF8String (SIZE (1..256)) OPTIONAL }
ResponseStatus ::= SEQUENCE {
statusCode CVStatusCode DEFAULT okay,
errorMessage UTF8String OPTIONAL }
CVStatusCode ::= ENUMERATED {
okay (0),
skipUnrecognizedItems (1),
tooBusy (10),
invalidRequest (11),
internalError (12),
badStructure (20),
unsupportedVersion (21),
abortUnrecognizedItems (22),
unrecognizedSigKey (23),
badSignatureOrMAC (24),
unableToDecode (25),
notAuthorized (26),
unsupportedChecks (27),
unsupportedWantBacks (28),
unsupportedSignatureOrMAC (29),
invalidSignatureOrMAC (30),
protectedResponseUnsupported (31),
unrecognizedResponderName (32),
relayingLoop (40),
unrecognizedValPol (50),
unrecognizedValAlg (51),
fullRequestInResponseUnsupported (52),
fullPolResponseUnsupported (53),
inhibitPolicyMappingUnsupported (54),
requireExplicitPolicyUnsupported (55),
inhibitAnyPolicyUnsupported (56),
validationTimeUnsupported (57),
unrecognizedCritQueryExt (63),
unrecognizedCritRequestExt (64) }
RespValidationPolicy ::= ValidationPolicy
RequestReference ::= CHOICE {
requestHash [0] HashValue, -- hash of CVRequest
fullRequest [1] CVRequest }
HashValue ::= SEQUENCE {
algorithm AlgorithmIdentifier DEFAULT { algorithm sha-1 },
value OCTET STRING }
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply
CertReply ::= SEQUENCE {
cert CertReference,
replyStatus ReplyStatus DEFAULT success,
replyValTime GeneralizedTime,
replyChecks ReplyChecks,
replyWantBacks ReplyWantBacks,
validationErrors [0] SEQUENCE SIZE (1..MAX) OF
OBJECT IDENTIFIER OPTIONAL,
nextUpdate [1] GeneralizedTime OPTIONAL,
certReplyExtensions [2] Extensions OPTIONAL }
ReplyStatus ::= ENUMERATED {
success (0),
malformedPKC (1),
malformedAC (2),
unavailableValidationTime (3),
referenceCertHashFail (4),
certPathConstructFail (5),
certPathNotValid (6),
certPathNotValidNow (7),
wantBackUnsatisfied (8) }
ReplyChecks ::= SEQUENCE OF ReplyCheck
ReplyCheck ::= SEQUENCE {
check OBJECT IDENTIFIER,
status INTEGER DEFAULT 0 }
ReplyWantBacks ::= SEQUENCE OF ReplyWantBack
ReplyWantBack::= SEQUENCE {
wb OBJECT IDENTIFIER,
value OCTET STRING }
CertBundles ::= SEQUENCE SIZE (1..MAX) OF CertBundle
RevInfoWantBack ::= SEQUENCE {
revocationInfo RevocationInfos,
extraCerts CertBundle OPTIONAL }
SCVPResponses ::= SEQUENCE OF ContentInfo
-- SCVP Validation Policies Request
id-ct-scvp-valPolRequest OBJECT IDENTIFIER ::= { id-ct 12 }
ValPolRequest ::= SEQUENCE {
vpRequestVersion INTEGER DEFAULT 1,
requestNonce OCTET STRING }
-- SCVP Validation Policies Response
id-ct-scvp-valPolResponse OBJECT IDENTIFIER ::= { id-ct 13 }
ValPolResponse ::= SEQUENCE {
vpResponseVersion INTEGER,
maxCVRequestVersion INTEGER,
maxVPRequestVersion INTEGER,
serverConfigurationID INTEGER,
thisUpdate GeneralizedTime,
nextUpdate GeneralizedTime OPTIONAL,
supportedChecks CertChecks,
supportedWantBacks WantBack,
validationPolicies SEQUENCE OF OBJECT IDENTIFIER,
validationAlgs SEQUENCE OF OBJECT IDENTIFIER,
authPolicies SEQUENCE OF AuthPolicy,
responseTypes ResponseTypes,
defaultPolicyValues RespValidationPolicy,
revocationInfoTypes RevocationInfoTypes,
signatureGeneration SEQUENCE OF AlgorithmIdentifier,
signatureVerification SEQUENCE OF AlgorithmIdentifier,
hashAlgorithms SEQUENCE SIZE (1..MAX) OF
OBJECT IDENTIFIER,
serverPublicKeys SEQUENCE OF KeyAgreePublicKey
OPTIONAL,
clockSkew INTEGER DEFAULT 10,
requestNonce OCTET STRING OPTIONAL }
ResponseTypes ::= ENUMERATED {
cached-only (0),
non-cached-only (1),
cached-and-non-cached (2) }
RevocationInfoTypes ::= BIT STRING {
fullCRLs (0),
deltaCRLs (1),
indirectCRLs (2),
oCSPResponses (3) }
AuthPolicy ::= OBJECT IDENTIFIER
-- SCVP Check Identifiers
id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 }
id-stc-build-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 }
id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 2 }
id-stc-build-status-checked-pkc-path
OBJECT IDENTIFIER ::= { id-stc 3 }
id-stc-build-aa-path OBJECT IDENTIFIER ::= { id-stc 4 }
id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 5 }
id-stc-build-status-checked-aa-path
OBJECT IDENTIFIER ::= { id-stc 6 }
id-stc-status-check-ac-and-build-status-checked-aa-path
OBJECT IDENTIFIER ::= { id-stc 7 }
-- SCVP WantBack Identifiers
id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 }
id-swb-pkc-best-cert-path OBJECT IDENTIFIER ::= { id-swb 1 }
id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 }
id-swb-pkc-public-key-info OBJECT IDENTIFIER ::= { id-swb 4 }
id-swb-aa-cert-path OBJECT IDENTIFIER ::= { id-swb 5 }
id-swb-aa-revocation-info OBJECT IDENTIFIER ::= { id-swb 6 }
id-swb-ac-revocation-info OBJECT IDENTIFIER ::= { id-swb 7 }
id-swb-relayed-responses OBJECT IDENTIFIER ::= { id-swb 9 }
id-swb-pkc-cert OBJECT IDENTIFIER ::= { id-swb 10}
id-swb-ac-cert OBJECT IDENTIFIER ::= { id-swb 11}
id-swb-pkc-all-cert-paths OBJECT IDENTIFIER ::= { id-swb 12}
id-swb-pkc-ee-revocation-info OBJECT IDENTIFIER ::= { id-swb 13}
id-swb-pkc-CAs-revocation-info OBJECT IDENTIFIER ::= { id-swb 14}
-- SCVP Validation Policy and Algorithm Identifiers
id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 }
id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 }
-- SCVP Basic Validation Algorithm Identifier
id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 }
-- SCVP Basic Validation Algorithm Errors
id-bvae OBJECT IDENTIFIER ::= id-svp-basicValAlg
id-bvae-expired OBJECT IDENTIFIER ::= { id-bvae 1 }
id-bvae-not-yet-valid OBJECT IDENTIFIER ::= { id-bvae 2 }
id-bvae-wrongTrustAnchor OBJECT IDENTIFIER ::= { id-bvae 3 }
id-bvae-noValidCertPath OBJECT IDENTIFIER ::= { id-bvae 4 }
id-bvae-revoked OBJECT IDENTIFIER ::= { id-bvae 5 }
id-bvae-invalidKeyPurpose OBJECT IDENTIFIER ::= { id-bvae 9 }
id-bvae-invalidKeyUsage OBJECT IDENTIFIER ::= { id-bvae 10 }
id-bvae-invalidCertPolicy OBJECT IDENTIFIER ::= { id-bvae 11 }
-- SCVP Name Validation Algorithm Identifier
id-svp-nameValAlg OBJECT IDENTIFIER ::= { id-svp 2 }
-- SCVP Name Validation Algorithm DN comparison algorithm
id-nva-dnCompAlg OBJECT IDENTIFIER ::= { id-svp 4 }
-- SCVP Name Validation Algorithm Errors
id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg id-nvae-name-mismatch OBJECT IDENTIFIER ::= { id-nvae 1 }
id-nvae-no-name OBJECT IDENTIFIER ::= { id-nvae 2 }
id-nvae-unknown-alg OBJECT IDENTIFIER ::= { id-nvae 3 }
id-nvae-bad-name OBJECT IDENTIFIER ::= { id-nvae 4 }
id-nvae-bad-name-type OBJECT IDENTIFIER ::= { id-nvae 5 }
id-nvae-mixed-names OBJECT IDENTIFIER ::= { id-nvae 6 }
-- SCVP Extended Key Usage Key Purpose Identifiers
id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 }
id-kp-scvpServer OBJECT IDENTIFIER ::= { id-kp 15 }
id-kp-scvpClient OBJECT IDENTIFIER ::= { id-kp 16 }
END9. Security Considerations 🔐
For security stuff specific to the Cryptographic Message Syntax message formats, check out [CMS]. For security stuff specific to PKI certification path validation, go to [PKIX-1]. 💅
Okay so, a client that trusts a server's response for validating a certificate is basically trusting that server as much as it would trust its own validation software 🫣. That means if an attacker compromises a trusted SCVP server, they can change the validation processing for every client that relies on that server. So an SCVP server needs to be protected at least as well as the trust anchors it trusts. Hard stop. 🔒
Clients MUST verify that the response matches their original request. Clients need to make sure the server did the right checks on the correct certificates under the requested validation policy for the specified validation time, and that the response includes the requested wantBacks and meets the client's freshness requirements. 🎀
When the SCVP response is used to figure out whether a certificate is valid, the client MUST validate the digital signature or MAC on the response so it knows the expected SCVP server actually generated it. If the client doesn't check the digital signature or MAC, a man-in-the-middle attack could trick it into believing modified responses, or responses to questions it never asked. 😱
If the client doesn't include a requestNonce item, or doesn't check that the requestNonce in the response matches the value in the request, an attacker can replay previous responses from the SCVP server. 🔁
If the server doesn't require some sort of authorization (like signed requests), an attacker can get the server to respond to arbitrary requests. Those responses might give the attacker info about weaknesses in the server or about how timely its checking is, and that info could be super valuable for a future attack. 👀
If the server uses the serverContextInfo item to indicate some server state associated with a requestor, implementers must take appropriate measures against denial-of-service attacks, where an attacker sends a lot of requests at one time to force the server to keep a lot of state information. 🚨
SCVP does not include any confidentiality mechanisms. If confidentiality is needed, it can be achieved with a lower-layer security protocol such as TLS [TLS]. 🤐
If an SCVP client isn't operating on a network with good physical protection, it must ensure that there is integrity over the SCVP request-response pair. The client can ensure integrity by using a protected transport such as TLS. It can also ensure integrity by using MACs or digital signatures to individually protect the request and response messages. 🧱
If an SCVP client populates the userPolicySet in a request with a value other than anyPolicy, but doesn't set the requireExplicitPolicy flag, the server may return an affirmative answer for paths that don't satisfy any of the specified policies. In general, when a client populates the userPolicySet in a request with a value other than anyPolicy, the requireExplicitPolicy flag should also be set. This guarantees that all valid paths satisfy at least one of the requested policies. 🍓
In SCVP, historical validation of a certificate returns the known status of the certificate at the time specified in validationTime. This can be used to show due diligence, but it doesn't necessarily give the most complete info. A certificate may have been revoked after the time specified in validationTime, but the revocation notice may specify an invalidity date that comes before the validationTime. The SCVP server would still give an affirmative response, even though the most current info available says the certificate shouldn't be trusted at that time. SCVP clients may wish to specify a validationTime later than the actual time of interest to mitigate this risk. 🫠
10. IANA Considerations 🦋
The details of SCVP requests and responses are communicated using object identifiers (OIDs). The objects are defined in an arc delegated by IANA to the PKIX Working Group. This document also includes four MIME type registrations in Appendix A. No further action by IANA is necessary for this document or any anticipated updates. 🌸
11. References 📚
11.1. Normative References
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[PKIX-1] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[PKIX-AC] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[PKIX-ALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[PKIX-ALG2] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[ESS] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[SMIME-CERT] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[IKE] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
11.2. Informative References
[IKE-GROUPS] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RQMTS] Pinkas, D. and R. Housley, "Delegated Path Validation and Delegated Path Discovery Protocol Requirements", RFC 3379, September 2002.
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
12. Acknowledgments 🙏
The lively debate in the PKIX Working Group has made a significant impact on this protocol. Special thanks to the following for their contributions to this document and diligence in greatly improving it.
- Paul Hoffman
- Phillip Hallam-Baker
- Mike Myers
- Frank Balluffi
- Ameya Talwalkar
- John Thielens
- Peter Sylvester
- Yuriy Dzambasow
- Sean P. Turner
- Wen-Cheng Wang
- Francis Dupont
- Dave Engberg
- Faisal Maqsood
Thanks also to working group chair Steve Kent for his support and help. 🫶
Appendix A. MIME Media Type Registrations 🎀
Four MIME media type registrations are provided in this appendix. ✨
A.1. application/scvp-cv-request
To: ietf-types@iana.org
Subject: Registration of MIME media type application/scvp-cv-request
MIME media type name: application
MIME subtype name: scvp-cv-request
Required parameters: None
Optional parameters: None
Encoding considerations: Binary
Security considerations: Carries a request for information. This
request may optionally be cryptographically protected.
Interoperability considerations: None
Published specification: RFC 5055
Applications that use this media type: SCVP clients sending
certificate validation requests
Additional information:
Magic number(s): None
File extension(s): .SCQ
Macintosh File Type Code(s): None
Person & email address to contact for further information:
Ambarish Malpani <ambarish@yahoo.com>
Intended usage: COMMON
Restrictions on usage: This media type can be used with any protocol
that can transport digitally signed objects.
Author: Ambarish Malpani <ambarish@yahoo.com>
Change controller: IESGA.2. application/scvp-cv-response
To: ietf-types@iana.org
Subject: Registration of MIME media type application/scvp-cv-response
MIME media type name: application
MIME subtype name: scvp-cv-response
Required parameters: None
Optional parameters: None
Encoding considerations: Binary
Security considerations: The client may require that this response be
cryptographically protected, or may choose to use a secure transport
mechanism. DPD responses may be unprotected, but the client
validates the information provided in the request.
Interoperability considerations: None
Published specification: RFC 5055
Applications that use this media type: SCVP servers responding to
certificate validation requests
Additional information:
Magic number(s): None
File extension(s): .SCS
Macintosh File Type Code(s): none
Person & email address to contact for further information:
Ambarish Malpani <ambarish@yahoo.com>
Intended usage: COMMON
Restrictions on usage: This media type can be used with any protocol
that can transport digitally signed objects.
Author: Ambarish Malpani <ambarish@yahoo.com>
Change controller: IESGA.3. application/scvp-vp-request ✨
To: ietf-types@iana.org
Subject: Registration of MIME media type application/scvp-vp-request
MIME media type name: application
MIME subtype name: scvp-vp-request
Required parameters: None
Optional parameters: None
Encoding considerations: Binary
Security considerations: Carries a request for information.
Interoperability considerations: None
Published specification: RFC 5055
Applications that use this media type: SCVP clients sending
validation policy requests
Additional information:
Magic number(s): None
File extension(s): .SPQ
Macintosh File Type Code(s): none
Person & email address to contact for further information:
Ambarish Malpani <ambarish@yahoo.com>
Intended usage: COMMON
Restrictions on usage: None
Author: Ambarish Malpani <ambarish@yahoo.com>
Change controller: IESGA.4. application/scvp-vp-response 🎀
To: ietf-types@iana.org
Subject: Registration of MIME media type application/scvp-vp-response
MIME media type name: application
MIME subtype name: scvp-vp-response
Required parameters: None
Optional parameters: None
Encoding considerations: Binary
Security considerations: None
Interoperability considerations: None
Published specification: RFC 5055
Applications that use this media type: SCVP servers responding to
validation policy requests
Additional information:
Magic number(s): None
File extension(s): .SPP
Macintosh File Type Code(s): none
Person & email address to contact for further information:
Ambarish Malpani <ambarish@yahoo.com>
Intended usage: COMMON
Restrictions on usage: This media type can be used with any protocol
that can transport digitally signed objects.
Author: Ambarish Malpani <ambarish@yahoo.com>
Change controller: IESGAppendix B. SCVP over HTTP 🦋
okay so this appendix is all about how SCVP requests and responses get dressed up for HTTP, bestie 💅 it explains the formatting and transport conventions when HTTP is carrying them around.
In order for SCVP clients and servers using HTTP to interoperate, the following rules apply. 🫶
- Clients MUST use the POST method to submit their requests.
- Servers MUST use the 200 response code for successful responses.
- Clients MAY attempt to send HTTPS requests using TLS 1.0 or later, although servers are not required to support TLS.
- Servers MUST NOT assume client support for any type of HTTP authentication such as cookies, Basic authentication, or Digest authentication.
- Clients and servers are expected to follow the other rules and restrictions in [HTTP]. Note that some of those rules are for HTTP methods other than POST; clearly, only the rules that apply to POST are relevant for this specification. ✨
B.1. SCVP Request 🌸
An SCVP request using the POST method is constructed as follows: 🧚
The Content-Type header MUST have the value application/scvp-cv-request.
The body of the message is the binary value of the DER encoding of the CVRequest, wrapped in a CMS body as described in Section 3.
B.2. SCVP Response 💜
An HTTP-based SCVP response is composed of the appropriate HTTP headers, followed by the binary value of the BER encoding of the CVResponse, wrapped in a CMS body as described in Section 4.
The Content-Type header MUST have the value application/scvp-cv-response.
B.3. SCVP Policy Request 🍓
An SCVP request using the POST method is constructed as follows:
The Content-Type header MUST have the value application/scvp-vp-request.
The body of the message is the binary value of the BER encoding of the ValPolRequest, wrapped in a CMS body as described in Section 5.
B.4. SCVP Policy Response 🌈
An HTTP-based SCVP policy response is composed of the appropriate HTTP headers, followed by the binary value of the DER encoding of the ValPolResponse, wrapped in a CMS body as described in Section 6. The Content-Type header MUST have the value application/scvp-vp-response.
Authors' Addresses 📮
Trevor Freeman Microsoft Corporation, One Microsoft Way Redmond, WA 98052 USA. EMail: trevorf@microsoft.com
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com
Ambarish Malpani Malpani Consulting Services EMail: ambarish@yahoo.com
David Cooper National Institute of Standards and Technology 100 Bureau Drive, Mail Stop 8930 Gaithersburg, MD 20899-8930 EMail: david.cooper@nist.gov
Tim Polk National Institute of Standards and Technology 100 Bureau Drive, Mail Stop 8930 Gaithersburg, MD 20899-8930 EMail: wpolk@nist.gov
Full Copyright Statement 🔥
Copyright (C) The IETF Trust (2007).
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.
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.
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.
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.
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.
📦 where this page comes from
- ietf: rfc5055 2007-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms