idnits 2.17.1 draft-ietf-pkix-scvp-22.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3899. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3581. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3588. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3594. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 3241 -- Looks like a reference, but probably isn't: '1' on line 3243 -- Looks like a reference, but probably isn't: '2' on line 3244 -- Looks like a reference, but probably isn't: '3' on line 3179 -- Looks like a reference, but probably isn't: '4' on line 3180 -- Looks like a reference, but probably isn't: '5' on line 3181 -- Looks like a reference, but probably isn't: '6' on line 3182 -- Looks like a reference, but probably isn't: '7' on line 3183 == Missing Reference: 'RQTMS' is mentioned on line 2623, but not defined == Unused Reference: 'SHA' is defined on line 3532, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3369 (ref. 'CMS') (Obsoleted by RFC 3852) ** Obsolete normative reference: RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 3280 (ref. 'PKIX-1') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3281 (ref. 'PKIX-AC') (Obsoleted by RFC 5755) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' ** Obsolete normative reference: RFC 2279 (ref. 'UTF8') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2818 (ref. 'HTTP-TLS') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3850 (ref. 'SMIME-CERT') (Obsoleted by RFC 5750) ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft T. Freeman 3 draft-ietf-pkix-scvp-22.txt Microsoft Corp 4 January 2006 R. Housley 5 Expires in six months Vigil Security 6 A. Malpani 7 Malpani Consulting Services 8 D. Cooper 9 NIST 10 T. Polk 11 NIST 13 Standard Certificate Validation Protocol (SCVP) 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 SCVP allows a client to delegate certificate path construction and 45 certificate path validation to a server. The path construction or 46 validation (e.g. making sure that none of the certificates in the 47 path are revoked) is performed according to a validation policy, 48 which contains one or more trust anchors. It allows simplification 49 of client implementations and use of a set of predefined validation 50 policies. 52 Table of Contents 54 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 55 1.1 SCVP overview and requirements . . . . . . . . . . . . . 5 56 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 57 1.3 Validation Policies . . . . . . . . . . . . . . . . . . . 6 58 1.4 Validation Algorithm . . . . . . . . . . . . . . . . . . 7 59 1.5 Validation Requirements . . . . . . . . . . . . . . . . . 8 60 2 Protocol Overview . . . . . . . . . . . . . . . . . . . . . 8 61 3 Validation Request . . . . . . . . . . . . . . . . . . . . . 9 62 3.1 cvRequestVersion . . . . . . . . . . . . . . . . . . . . 11 63 3.2 query . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 3.2.1 queriedCerts . . . . . . . . . . . . . . . . . . . . 13 65 3.2.2 checks . . . . . . . . . . . . . . . . . . . . . . . 14 66 3.2.3 wantBack . . . . . . . . . . . . . . . . . . . . . . 16 67 3.2.4 validationPolicy . . . . . . . . . . . . . . . . . . . 18 68 3.2.4.1 validationPolRef . . . . . . . . . . . . . . . . 19 69 3.2.4.1.1 Default Validation Policy . . . . . . . . . . 20 70 3.2.4.2 validationAlg . . . . . . . . . . . . . . . . . . 21 71 3.2.4.2.1 Basic Validation Algorithm . . . . . . . . . 21 72 3.2.4.2.2 Basic Validation Algorithm Errors . . . . . . 22 73 3.2.4.2.3 Name Validation Algorithm . . . . . . . . . . 23 74 3.2.4.2.4 Name Validation Algorithm Errors . . . . . . 24 75 3.2.4.3 userPolicySet . . . . . . . . . . . . . . . . . . 25 76 3.2.4.4 inhibitPolicyMapping . . . . . . . . . . . . . . 25 77 3.2.4.5 requireExplicitPolicy . . . . . . . . . . . . . . 25 78 3.2.4.6 inhibitAnyPolicy . . . . . . . . . . . . . . . . 25 79 3.2.4.7 trustAnchors . . . . . . . . . . . . . . . . . . 26 80 3.2.4.8 keyUsages . . . . . . . . . . . . . . . . . . . . 26 81 3.2.4.9 extendedKeyUsages . . . . . . . . . . . . . . . . 27 82 3.2.5 responseFlags . . . . . . . . . . . . . . . . . . . . 27 83 3.2.5.1 fullRequestInResponse . . . . . . . . . . . . . . 28 84 3.2.5.2 responseValidationPolByRef . . . . . . . . . . . 28 85 3.2.5.3 protectResponse . . . . . . . . . . . . . . . . . 29 86 3.2.5.4 cachedResponse . . . . . . . . . . . . . . . . . 29 87 3.2.6 serverContextInfo . . . . . . . . . . . . . . . . . . 29 88 3.2.7 validationTime . . . . . . . . . . . . . . . . . . . 30 89 3.2.8 intermediateCerts . . . . . . . . . . . . . . . . . . 31 90 3.2.9 revInfos . . . . . . . . . . . . . . . . . . . . . . 32 91 3.2.10 producedAt . . . . . . . . . . . . . . . . . . . . . 32 92 3.2.11 queryExtensions . . . . . . . . . . . . . . . . . . 33 93 3.2.11.1 extnID . . . . . . . . . . . . . . . . . . . . . 33 94 3.2.11.2 critical . . . . . . . . . . . . . . . . . . . . 33 95 3.2.11.3 extnValue . . . . . . . . . . . . . . . . . . . . 33 96 3.3 requestorRef . . . . . . . . . . . . . . . . . . . . . . 33 97 3.4 requestNonce . . . . . . . . . . . . . . . . . . . . . . 34 98 3.5 requestorName . . . . . . . . . . . . . . . . . . . . . . 35 99 3.6 responderName . . . . . . . . . . . . . . . . . . . . . . 35 100 3.7 requestExtensions . . . . . . . . . . . . . . . . . . . . 35 101 3.7.1 extnID . . . . . . . . . . . . . . . . . . . . . . . 36 102 3.7.2 critical . . . . . . . . . . . . . . . . . . . . . . 36 103 3.7.3 extnValue . . . . . . . . . . . . . . . . . . . . . . 36 104 3.8 signatureAlg . . . . . . . . . . . . . . . . . . . . . . 36 105 3.9 hashAlg . . . . . . . . . . . . . . . . . . . . . . . . . 37 106 3.10 SCVP Request Authentication . . . . . . . . . . . . . . 37 107 4 Validation Response . . . . . . . . . . . . . . . . . . . . 38 108 4.1 cvResponseVersion . . . . . . . . . . . . . . . . . . . . 40 109 4.2 serverConfigurationID . . . . . . . . . . . . . . . . . . 41 110 4.3 producedAt . . . . . . . . . . . . . . . . . . . . . . . 41 111 4.4 responseStatus . . . . . . . . . . . . . . . . . . . . . 41 112 4.5 respValidationPolicy . . . . . . . . . . . . . . . . . . 43 113 4.6 requestRef . . . . . . . . . . . . . . . . . . . . . . . 44 114 4.6.1 requestHash . . . . . . . . . . . . . . . . . . . . . 44 115 4.6.2 fullRequest . . . . . . . . . . . . . . . . . . . . . 45 116 4.7 requestorRef . . . . . . . . . . . . . . . . . . . . . . 45 117 4.8 requestorName . . . . . . . . . . . . . . . . . . . . . . 45 118 4.9 replyObjects . . . . . . . . . . . . . . . . . . . . . . 46 119 4.9.1 cert . . . . . . . . . . . . . . . . . . . . . . . . 47 120 4.9.2 replyStatus . . . . . . . . . . . . . . . . . . . . . 47 121 4.9.3 replyValTime . . . . . . . . . . . . . . . . . . . . 48 122 4.9.4 replyChecks . . . . . . . . . . . . . . . . . . . . . 48 123 4.9.5 replyWantBacks . . . . . . . . . . . . . . . . . . . 50 124 4.9.6 validationErrors . . . . . . . . . . . . . . . . . . 52 125 4.9.7 nextUpdate . . . . . . . . . . . . . . . . . . . . . 53 126 4.9.8 certReplyExtensions . . . . . . . . . . . . . . . . . 53 127 4.10 respNonce . . . . . . . . . . . . . . . . . . . . . . . 53 128 4.11 serverContextInfo . . . . . . . . . . . . . . . . . . . 54 129 4.12 cvResponseExtensions . . . . . . . . . . . . . . . . . . 54 130 4.13 SCVP Response Validation . . . . . . . . . . . . . . . . 55 131 4.13.1 Simple Key Validation . . . . . . . . . . . . . . . 55 132 4.13.2 SCVP Server Certificate Validation . . . . . . . . . 55 133 5 Server Policy Request . . . . . . . . . . . . . . . . . . . 56 134 5.1 vpRequestVersion . . . . . . . . . . . . . . . . . . . . 56 135 5.2 requestNonce . . . . . . . . . . . . . . . . . . . . . . 56 136 6 Validation Policy Response . . . . . . . . . . . . . . . . . 56 137 6.1 vpResponseVersion . . . . . . . . . . . . . . . . . . . . 58 138 6.2 maxCVRequestVersion . . . . . . . . . . . . . . . . . . . 58 139 6.3 maxVPRequestVersion . . . . . . . . . . . . . . . . . . . 58 140 6.4 serverConfigurationID . . . . . . . . . . . . . . . . . . 58 141 6.5 thisUpdate . . . . . . . . . . . . . . . . . . . . . . . 58 142 6.6 nextUpdate and requestNonce . . . . . . . . . . . . . . . 59 143 6.7 validationPolicies . . . . . . . . . . . . . . . . . . . 59 144 6.8 validationAlgs . . . . . . . . . . . . . . . . . . . . . 59 145 6.9 authPolicies . . . . . . . . . . . . . . . . . . . . . . 59 146 6.10 responseTypes . . . . . . . . . . . . . . . . . . . . . 60 147 6.11 revocationInfoTypes . . . . . . . . . . . . . . . . . . 60 148 6.12 defaultPolicyValues . . . . . . . . . . . . . . . . . . 60 149 6.13 signatureGeneration . . . . . . . . . . . . . . . . . . 60 150 6.14 signatureVerification . . . . . . . . . . . . . . . . . 61 151 6.15 hashAlgorithms . . . . . . . . . . . . . . . . . . . . . 61 152 6.16 serverPublicKeys . . . . . . . . . . . . . . . . . . . . 61 153 6.17 clockSkew . . . . . . . . . . . . . . . . . . . . . . . 62 154 7 SCVP Server Relay . . . . . . . . . . . . . . . . . . . . . 62 155 8 SCVP ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 63 156 9 Security Considerations . . . . . . . . . . . . . . . . . . 71 157 10 References . . . . . . . . . . . . . . . . . . . . . . . . 73 158 10.1 Normative References . . . . . . . . . . . . . . . . . . 73 159 10.2 Informative References . . . . . . . . . . . . . . . . . 74 160 11 Intellectual Property Rights . . . . . . . . . . . . . . . 75 161 12 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 75 162 Appendix A -- MIME Registrations . . . . . . . . . . . . . . . 76 163 A.1 application/cv-request . . . . . . . . . . . . . . . . . 76 164 A.2 application/cv-response . . . . . . . . . . . . . . . . . 76 165 A.3 application/vp-request . . . . . . . . . . . . . . . . . 77 166 A.4 application/vp-response . . . . . . . . . . . . . . . . . 78 167 Appendix B -- SCVP over HTTP . . . . . . . . . . . . . . . . . 79 168 B.1 SCVP Request . . . . . . . . . . . . . . . . . . . . . . 79 169 B.2 SCVP Response . . . . . . . . . . . . . . . . . . . . . . 79 170 B.3 SCVP Policy Request . . . . . . . . . . . . . . . . . . . 80 171 B.4 SCVP Policy Response . . . . . . . . . . . . . . . . . . 80 172 Appendix C -- Authors' Addresses . . . . . . . . . . . . . . . 80 173 1 Introduction 175 Certificate validation is complex. If certificate handling is to be 176 widely deployed in a variety of applications and environments, the 177 amount of processing an application needs to perform before it can 178 accept a certificate needs to be reduced. There are a variety of 179 applications that can make use of public key certificates, but these 180 applications are burdened with the overhead of constructing and 181 validating the certification paths. SCVP reduces this overhead for 182 two classes of certificate-using applications. 184 The first class of applications wants just two things: confirmation 185 that the public key belongs to the identity named in the certificate 186 and confirmation that the public key can be used for the intended 187 purpose. Such clients can completely delegate certification path 188 construction and validation to the SCVP server. This is often 189 referred to as delegated path validation (DPV). 191 The second class of applications can perform certification path 192 validation, but they lack a reliable or efficient method of 193 constructing a valid certification path. Such clients delegate 194 certification path construction to the SCVP server, but not 195 validation of the returned certification path. This is often 196 referred to as delegated path discovery (DPD). 198 1.1 SCVP overview and requirements 200 SCVP meets the mandatory requirements documented in [RQMTS]. 202 The primary goals of SCVP are to make it easier to deploy PKI- 203 enabled applications by delegating path discovery and/or validation 204 processing to a server, and to allow central administration of 205 validation policies within an organization. SCVP can be used by 206 clients that do much of the certificate processing themselves but 207 simply want an untrusted server to collect information for them. 208 However, when the client has complete trust in the SCVP server, SCVP 209 can be used to delegate the work of certification path construction 210 and validation, and SCVP can be used to ensure that policies are 211 consistently enforced throughout an organization. 213 Untrusted SCVP servers can provide clients the certification paths. 214 They can also provide clients the revocation information, such as 215 CRLs and OCSP responses, that the clients need to validate the 216 certification paths constructed by the SCVP server. These services 217 can be valuable to clients that do not include the protocols needed 218 to find and download intermediate certificates, CRLs, and OCSP 219 responses. 221 Trusted SCVP servers can perform certification path construction and 222 validation for the client. For a client that uses these services, 223 the client inherently trusts the SCVP server as much as it would its 224 own certification path validation software (if it contained such 225 software). There are two main reasons that a client may want to 226 trust such an SCVP server: 228 1. The client does not want to incur the overhead of including 229 certification path validation software and running it for each 230 certificate it receives. 232 2. The client is in an organization or community that wants to 233 centralize management of validation policies. These policies 234 might dictate that particular trust anchors are to be used and 235 the types of policy checking that are to be performed during 236 certification path validation. 238 1.2 Terminology 240 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 241 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 242 document are to be interpreted as described in [STDWORDS]. 244 1.3 Validation Policies 246 A validation policy (as defined in RFC 3379 [RQMTS]) specifies the 247 rules and parameters to be used by the SCVP server when validating a 248 certificate. In SCVP, the validation policy to be used by the 249 server can either be fully referenced in the request by the client 250 (and thus no additional parameters are necessary) or it can be 251 referenced in the request by the client with additional parameters. 253 Policy definitions can be quite long and complex, and some policies 254 may allow for the setting of a few parameters. The request can 255 therefore be very simple if an OBJECT IDENTIFIER (OID) is used to 256 specify both the algorithm to be used and all the associated 257 parameters of the validation policy. The request can be more 258 complex if the validation policy fixes many of the parameters but 259 allows the client to specify some of them. When the validation 260 policy defines every parameter necessary, an SCVP request needs only 261 to contain the certificate to be validated, the referenced 262 validation policy, and any run-time parameters for the request. 264 A server publishes the references of the validation policies it 265 supports. When these policies have parameters that may be 266 overridden, the server communicates the default values for these 267 parameters as well. The client can simplify the request by omitting 268 a parameter from a request if the default value published by the 269 server for a given validation policy reference is acceptable. 271 However, if there is a desire to demonstrate to someone else that a 272 specific validation policy with all its parameters has been used, 273 the client will need to ask the server for the inclusion of the full 274 validation policy with all the parameters in the response. 276 The inputs to the basic certification path processing algorithm used 277 by SCVP are defined by [PKIX-1] in section 6.1.1 and comprise: 279 Certificate to be validated (by value or by reference); 281 Validation time; 283 The initial policy set; 285 Initial inhibit policy mapping setting; 287 Initial inhibit anyPolicy setting; and 289 Initial require explicit policy setting. 291 The basic certification path processing algorithm also supports 292 specification of one or more Trust Anchors (by value or reference) 293 as an input. Where the client demands a certification originating 294 with a specific CA, a single Trust Anchor is specified. Where the 295 client is willing to accept paths beginning with any of several CAs, 296 a set of Trust anchors is specified. 298 The basic certification path processing algorithm also supports the 299 following parameters, which are defined in [PKIX-1] section 4: 301 The usage of the key contained in the certificate (e.g., key 302 encipherment, key agreement, signature); and 304 Other application-specific purposes for which the certified public 305 key may be used. 307 1.4 Validation Algorithm 309 The validation algorithm is determined by agreement between the 310 client and the server and is represented as an OID. The algorithm 311 defines the checking that will be performed by the server to 312 determine whether the certificate is valid. A validation algorithm 313 is one of the parameters to a validation policy. SCVP defines a 314 basic validation algorithm that implements the basic path validation 315 algorithm as defined in [PKIX-1], and permits the client to request 316 additional information about the certificate to be validated. New 317 validation algorithms can be specified that define additional checks 318 if needed. These new validation algorithms may specify additional 319 parameters. The values for these parameters may be defined by any 320 validation policy that uses the algorithm or may be included by the 321 client in the request. 323 Application-specific validation algorithms in addition to those 324 defined in this document can be defined to meet specific 325 requirements not covered by the basic validation algorithm. The 326 validation algorithms documented here should serve as a guide for 327 the development of further application-specific validation 328 algorithms. For example, a new application-specific validation 329 algorithm might require the presence of a particular name form in 330 the subject alternative name extension of the certificate. 332 1.5 Validation Requirements 334 For a certification path to be considered valid under a particular 335 validation policy it MUST be a valid certification path as defined 336 in [PKIX-1] and all validation policy constraints that apply to the 337 certification path MUST be verified. 339 Revocation checking is one aspect of certification path validation 340 defined in [PKIX-1]. However, revocation checking is an optional 341 feature in [PKIX-1], and revocation information is distributed in 342 multiple formats. Clients specify in requests whether revocation 343 checking should be performed and whether revocation information 344 should be returned in the response. 346 Servers MUST be capable of indicating the sources of revocation 347 information that they are capable of processing: 349 1. full CRLs (or full Authority Revocation Lists); 351 2. OCSP responses, using [OCSP]; 353 3. delta CRLs; and 355 4. indirect CRLs. 357 2 Protocol Overview 359 SCVP uses a simple request-response model. That is, the SCVP client 360 creates a request and sends it to the SCVP server, and then the SCVP 361 server creates a single response and sends it to the client. The 362 typical use of SCVP is expected to be over HTTP [HTTP], but it can 363 also be used with email or any other protocol that can transport 364 digitally signed objects. Appendices A and B provide the details 365 necessary to use SCVP with HTTP. 367 SCVP includes two request-response pairs. The primary request- 368 response pair handles certificate validation. The secondary 369 request-response pair is used to determine the list of validation 370 policies and default parameters supported by a specific SCVP server. 372 Section 3 defines the certificate validation request. 374 Section 4 defines the corresponding certificate validation response. 376 Section 5 defines the validation policies request. 378 Section 6 defines the corresponding validation policies response. 380 Appendix A registers MIME types for SCVP requests and responses, and 381 Appendix B describes the use of these MIME types with HTTP. 383 3 Validation Request 385 An SCVP client request to the server MUST be a single CVRequest 386 item. When a CVRequest is encapsulated in a MIME body part, 387 application/cv-request MUST be used. 389 There are two forms of SCVP request: unprotected and protected. A 390 protected request is used to authenticate the client to the server 391 or to provide anonymous client integrity over the request-response 392 pair. The protection is provided by a digital signature or message 393 authentication code (MAC). In the later case, the MAC key is 394 derived using a key agreement algorithm, such as Diffie-Hellman. If 395 the client's public key is contained in a certificate, then it may 396 be used to authenticate the client. More commonly, the client's key 397 agreement public key will be ephemeral, supporting anonymous client 398 integrity. 400 A server MAY require all requests to be protected, and a server MAY 401 discard all unprotected requests. Alternatively, a server MAY 402 choose to process unprotected requests. 404 The unprotected request consists of a CVRequest encapsulated in a 405 CMS ContentInfo [CMS]. An overview of this structure is provided 406 below and is only intended as illustrative. The definitive ASN.1 is 407 found in [CMS]. Many details are not shown, but the way that SCVP 408 makes use of CMS is clearly illustrated. 410 ContentInfo { 411 contentType id-ct-scvp-certValRequest, 412 -- (1.2.840.113549.1.9.16.1.10) 413 content CVRequest } 415 The protected request consists of a CVRequest encapsulated in either 416 a SignedData or AuthenticatedData, which is in turn encapsulated in 417 a ContentInfo. That is, the EncapsulatedContentInfo field of either 418 SignedData or AuthenticatedData consists of an eContentType field 419 with a value of id-ct-scvp-certValRequest and an eContent field that 420 contains a DER encoded CVRequest. SignedData is used when the 421 request is digitally signed. AuthenticatedData is used with a 422 message authentication code (MAC). 424 All SCVP clients MUST support SignedData for signed requests and 425 responses. SCVP clients SHOULD support AuthenticatedData for MAC 426 protected requests and responses. 428 If the client uses SignedData it MUST have a public key that has 429 been bound to a subject identity by a certificate that conforms to 430 the PKIX profile [PKIX-1] and that certificate MUST be suitable for 431 signing the SCVP request. That is: 433 1. If the key usage extension is present, either the digital 434 signature or the non-repudiation bit MUST be asserted. 436 2. If the extended key usage extension is present, it MUST 437 contain either the SCVP client OID (see Section 3.10) or 438 another OID acceptable to the SCVP server. 440 The client MUST put an unambiguous reference to its certificate in 441 the SignedData that encapsulates the request. The client SHOULD 442 include its certificate in the request, but MAY omit the certificate 443 to reduce the size of the request. The client MAY include other 444 certificates in the request to aid the validation of its 445 certificates by the SCVP server. The signerInfos field of 446 SignedData MUST include exactly one SignerInfo. The SignedData MUST 447 NOT include the unsignedAttrs field. 449 The client MUST put its key agreement public key or an unambiguous 450 reference to a certificate that contains its key agreement public 451 key in the AuthenticatedData that encapsulates the request. If an 452 ephemeral key agreement key pair is used, then the ephemeral key 453 agreement public key is carried in the originatorKey field of 454 KeyAgreeRecipientInfo, which requires the client to obtain the 455 server's key agreement public key before computing the message 456 authentication code (MAC). The recipientInfos field of 457 AuthenticatedData MUST include exactly one RecipientInfo, which 458 contains information for the SCVP server. The AuthenticatedData 459 MUST NOT include the unauthAttrs field. 461 The syntax and semantics for SignedData, AuthenticatedData, and 462 ContentInfo are defined in [CMS]. The syntax and semantics for 463 CVRequest are defined below. The CVRequest item contains the client 464 request. The CVRequest contains the cvRequestVersion and query 465 items; the CVRequest MAY also contain the requestorRef, 466 requestNonce, requestorName, responderName, requestExtensions, 467 signatureAlg, and hashAlg items. 469 The CVRequest MUST have the following syntax: 471 CVRequest ::= SEQUENCE { 472 cvRequestVersion INTEGER DEFAULT 1, 473 query Query, 474 requestorRef [0] GeneralNames OPTIONAL, 475 requestNonce [1] OCTET STRING OPTIONAL, 476 requestorName [2] GeneralName OPTIONAL, 477 responderName [3] GeneralName OPTIONAL, 478 requestExtensions [4] Extensions OPTIONAL, 479 signatureAlg [5] AlgorithmIdentifier OPTIONAL, 480 hashAlg [6] OBJECT IDENTIFIER OPTIONAL } 482 Conforming clients MUST be able to construct requests with 483 cvRequestVersion and query. Conforming clients MUST DER-encode the 484 CVRequest in both protected and unprotected messages to facilitate 485 unambiguous hash-based referencing in the corresponding response 486 message. SCVP clients that insist on creation of a fresh response 487 (e.g., to protect against a replay attack or ensure information is 488 up to date) MUST support requestNonce. Support for the remaining 489 items is optional in client implementations. 491 Conforming servers MUST be able to parse CVRequests that contain any 492 or all of the optional items. 494 Each of the items within the CVRequest is described in the following 495 sections. 497 3.1 cvRequestVersion 499 The cvRequestVersion item defines the version of the SCVP CVRequest 500 used in a request. The subsequent response MUST use the same 501 version number. The value of the cvRequestVersion item MUST be one 502 (1) for a client implementing this specification. Future updates to 503 this specification must specify other values if there are any 504 changes to syntax or semantics. 506 SCVP clients MUST support asserting this value and SCVP servers must 507 be capable of processing this value. 509 3.2 query 511 The query item specifies one or more certificates that are the 512 subject of the request; the certificates can be either public key 513 certificates [PKIX-1] or attribute certificates [PKIX-AC]. A query 514 MUST contain a queriedCerts item as well as one checks, and one 515 validationPolicy item; a query MAY also contain wantback, 516 responseFlags, serverContextInfo, validationTime, intermediateCerts, 517 revInfos, producedAt, and queryExtensions items. 519 Query MUST have the following syntax: 521 Query ::= SEQUENCE { 522 queriedCerts CertReferences, 523 checks CertChecks, 524 wantBack [1] WantBack OPTIONAL, 525 validationPolicy ValidationPolicy, 526 responseFlags ResponseFlags OPTIONAL, 527 serverContextInfo [2] OCTET STRING OPTIONAL, 528 validationTime [3] GeneralizedTime OPTIONAL, 529 intermediateCerts [4] CertBundle OPTIONAL, 530 revInfos [5] RevocationInfos OPTIONAL, 531 producedAt [6] GeneralizedTime OPTIONAL, 532 queryExtensions [7] Extensions OPTIONAL } 534 The list of certificate references in the queriedCerts item tells 535 the server the certificate(s) for which the client wants 536 information. The checks item specifies the checking that the client 537 wants performed. The wantBack item specifies the objects that the 538 client wants the server to return in the response. The 539 validationPolicy item specifies the validation policy that the 540 client wants the server to employ. The responseFlags item allows 541 the client to request optional features for the response. The 542 serverContextInfo item tells the server that additional information 543 from a previous request-response is desired. The validationTime 544 item tells the date and time relative to which the client wants the 545 server to perform the checks. The intermediateCerts and revInfos 546 items provide context for the client request. The queryExtensions 547 item provides for future expansion of the query syntax. The syntax 548 and semantics of each of these items is discussed in the following 549 sections. 551 Conforming clients MUST be able to construct a Query with a 552 queriedCerts item that specifies at least one certificate, checks, 553 and validationPolicy. Conforming SCVP clients MAY support 554 specification of multiple certificates and MAY support the optional 555 items in the Query structure. 557 SCVP clients that support delegated path discovery (DPD) as defined 558 in [RQMTS] MUST support wantBack and responseFlags. SCVP clients 559 that insist on creation of a fresh response (e.g., to protect 560 against a replay attack or ensure information is up to date) MUST 561 support responseFlags. 563 Conforming servers MUST be able to process a Query that contains any 564 of the optional items, and MUST be able to process a Query that 565 specifies multiple certificates. 567 3.2.1 queriedCerts 569 The queriedCerts item is a SEQUENCE of one or more certificates, 570 each of which is a subject of the request. The specified 571 certificates are either public key certificates or attribute 572 certificates; if more than one certificate is specified, all must be 573 of the same type. Each certificate is either directly included or 574 it is referenced. When referenced, a hash value of the referenced 575 item is included to ensure that the SCVP client and the SCVP server 576 both obtain the same certificate when the referenced certificate is 577 fetched. Certificate references use the CertID type, which is 578 described below. A single request MAY contain both directly 579 included and referenced certificates. 581 CertReferences has the following syntax: 583 CertReferences ::= CHOICE { 584 pkcRefs [0] SEQUENCE SIZE (1..MAX) OF PKCReference, 585 acRefs [1] SEQUENCE SIZE (1..MAX) OF ACReference } 587 PKCReference ::= CHOICE { 588 cert [0] Certificate, 589 pkcRef [1] CertID } 591 ACReference ::= CHOICE { 592 attrCert [2] AttributeCertificate, 593 acRef [3] CertID } 595 CertID ::= SEQUENCE { 596 certHash OCTET STRING, 597 issuerSerial IssuerSerial, 598 hashAlgorithm AlgorithmIdentifier DEFAULT { sha-1 } } 600 The ASN.1 definition of Certificate is imported from [PKIX-1] and 601 the definition of AttributeCertificate is imported from [PKIX-AC]. 603 When creating a CertID, the certHash is computed over the entire DER 604 encoded certificate including the signature. The hash algorithm 605 used to compute certHash is specified in hashAlgorithm. The hash 606 algorithm used to compute certHash SHOULD be one of the hash 607 algorithms specified in the hashAlgorithms item of the server's 608 validation policy response message. 610 When encoding IssuerSerial, serialNumber is the serial number that 611 uniquely identifies the certificate. For public key certificates, 612 the issuer MUST contain only the issuer name from the certificate 613 encoded in the directoryName choice of GeneralNames. For attribute 614 certificates, the issuer MUST contain the issuer name field from the 615 attribute certificate. 617 Conforming clients MUST be able to reference a certificate by direct 618 inclusion. Clients SHOULD be able to specify a certificate using 619 the CertID. Conforming clients MAY be able to reference multiple 620 certificates and MAY be able to reference both public key and 621 attribute certificates. 623 Conforming SCVP Server implementations MUST be able to process 624 CertReferences with multiple certificates. Conforming SCVP Server 625 implementations MUST be able to parse CertReferences that contain 626 either public key or attribute certificates. Conforming SCVP Server 627 implementations MUST be able to parse CertReferences with 628 certificates referenced by both inclusion and CertID. 630 3.2.2 checks 632 The checks item describes the checking that the SCVP client wants 633 the SCVP server to perform on the certificate(s) in the queriedCerts 634 item. The checks item contains a sequence of object identifiers 635 (OIDs). Each OID tells the SCVP server what checking the client 636 expects the server to perform. For each check specified in the 637 request, the SCVP server MUST perform the requested check, or return 638 an error. A server may choose to perform additional checks (e.g., a 639 server that is only asked to build a validated certification path 640 may choose to also perform revocation status checks), although the 641 server cannot indicate in the response that the additional checks 642 have been performed. 644 The checks item uses the CertChecks type, which has the following 645 syntax: 647 CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 649 For public key certificates, the following checks are defined: 651 - id-stc-build-pkc-path: Build a prospective certification path to 652 a trust anchor (as defined in section 6.1 of [PKIX-1]); 654 - id-stc-build-valid-pkc-path: Build a validated certification path 655 to a trust anchor (revocation checking not required); 657 - id-stc-build-status-checked-pkc-path: Build a validated 658 certification path to a trust anchor and perform revocation 659 status checks on the certification path. 661 Conforming SCVP server implementations that support delegated path 662 discovery (DPD) as defined in [RQMTS] MUST support the id-stc-build- 663 pkc-path check. Conforming SCVP server implementations that support 664 delegated path validation (DPV) as defined in [RQMTS] MUST support 665 the id-stc-build-valid-pkc-path and id-stc-build-status-checked-pkc- 666 path checks. 668 For attribute certificates, the following checks are defined: 670 - id-stc-build-aa-path: Build a certification path to a trust 671 anchor for the AC issuer; 673 - id-stc-build-valid-aa-path: Build a validated certification path 674 to a trust anchor for the AC issuer; 676 - id-stc-build-status-checked-aa-path: Build a validated 677 certification path to a trust anchor for the AC issuer and 678 perform revocation status checks on the certification path for 679 the AC issuer; 681 - id-stc-status-check-ac-and-build-status-checked-aa-path: Build a 682 validated certification path to a trust anchor for the AC 683 issuer and perform revocation status checks on the AC as well 684 as the certification path for the AC issuer. 686 Conforming SCVP server implementations MAY support the attribute 687 certificates checks. 689 For these purposes, the following OIDs are defined: 691 id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 692 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 } 694 id-stc-build-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 } 695 id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 2 } 696 id-stc-build-status-checked-pkc-path 697 OBJECT IDENTIFIER ::= { id-stc 3 } 698 id-stc-build-aa-path OBJECT IDENTIFIER ::= { id-stc 4 } 699 id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 5 } 700 id-stc-build-status-checked-aa-path 701 OBJECT IDENTIFIER ::= { id-stc 6 } 702 id-stc-status-check-ac-and-build-status-checked-aa-path 703 OBJECT IDENTIFIER ::= { id-stc 7 } 705 Conforming client implementations MUST be able to assert at least 706 one of the standard checks. Conforming clients MAY be able to 707 assert multiple checks. Conforming clients need not support all of 708 the checks defined in this section. 710 3.2.3 wantBack 712 The optional wantBack item describes any information the SCVP client 713 wants from the SCVP server for the certificate(s) in the 714 queriedCerts item in addition to the results of the checks specified 715 in certChecks. If present, the wantBack item MUST contain a 716 sequence of object identifiers (OIDs). Each OID tells the SCVP 717 server what the client wants to know about the queriedCerts item. 718 For each type of information specified in the request, the server 719 MUST return information regarding its finding (in a successful 720 response). 722 For example, a request might include a checks item that only 723 specifies certification path building and include a wantBack item 724 that requests the return of the certification path built by the 725 server. In this case, the response would not include a status for 726 the validation of the certification path, but it would include a 727 certification path that the server considers to be valid. A client 728 that wants to perform its own certification path validation might 729 use a request of this form. 731 Alternatively, a request might include a checks item that requests 732 the server to build a certification path and validate it, including 733 revocation checking, and not include a wantBack item. In this case, 734 the response would include only a status for the validation of the 735 certification path. A client that completely delegates 736 certification path validation might use a request of this form. 738 The wantBack item uses the WantBack type, which has the following 739 syntax: 741 WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 743 For public key certificates, the types of information that can be 744 requested are: 746 - id-swb-pkc-cert: The certificate that was the subject of the 747 request; 749 - id-swb-pkc-best-cert-path: The certification path built for the 750 certificate including the certificate that was validated; 752 - id-swb-pkc-revocation-info: Proof of revocation status for each 753 certificate in the certification path; 755 - id-swb-pkc-public-key-info: The public key from the certificate; 756 and 758 - id-swb-pkc-all-cert-paths: A set of certification paths for the 759 certificate. 761 All conforming SCVP server implementations MUST support the id-swb- 762 pkc-cert and id-swb-pkc-public-key-info wantBacks. Conforming SCVP 763 server implementations that support delegated path discovery (DPD) 764 as defined in [RQMTS] MUST support the id-swb-pkc-best-cert-path and 765 id-swb-pkc-revocation-info wantBacks. 767 The SCVP protocol provides two methods for a client to obtain 768 multiple certification paths for a certificate. The client could 769 use serverContextInfo to request one path at a time (see section 770 3.2.6). After obtaining each path, the client could submit the 771 serverContextInfo from the previous request to obtain another path 772 until the client either found a suitable path or the server 773 indicated (by not returning a serverContextInfo) that no more paths 774 were available. Alternatively, the client could send a single 775 request with an id-swb-pkc-all-cert-paths wantBack, in which case 776 the server would return all of the available paths in a single 777 response. 779 The server may, at its discretion, limit the number of paths that it 780 returns in response to the id-swb-pkc-all-cert-paths. When the 781 request includes an id-swb-pkc-all-cert-paths wantBack, the response 782 should not include a serverContextInfo. 784 For attribute certificates, the types of information that can be 785 requested are: 787 - id-swb-ac-cert: The attribute certificate that was the subject of 788 the request; 790 - id-swb-aa-cert-path: The certification path built for the AC 791 issuer certificate; 793 - id-swb-ac-revocation-info: Proof of revocation status for each 794 certificate in the AC issuer certification path; and 796 - id-swb-aa-revocation-info: Proof of revocation status for the 797 attribute certificate. 799 The following wantBack can be used for either public key or 800 attribute certificates: 802 - id-swb-relayed-responses: Any SCVP responses received by the 803 server that were used to generate the response to this query. 805 Conforming SCVP servers MAY support the id-swb-relayed-responses 806 wantBack. 808 For these purposes, the following OIDs are defined: 810 id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 811 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 } 813 id-swb-pkc-best-cert-path OBJECT IDENTIFIER ::= { id-swb 1 } 814 id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 } 815 id-swb-pkc-public-key-info OBJECT IDENTIFIER ::= { id-swb 4 } 816 id-swb-aa-cert-path OBJECT IDENTIFIER ::= { id-swb 5 } 817 id-swb-aa-revocation-info OBJECT IDENTIFIER ::= { id-swb 6 } 818 id-swb-ac-revocation-info OBJECT IDENTIFIER ::= { id-swb 7 } 819 id-swb-relayed-responses OBJECT IDENTIFIER ::= { id-swb 9 } 820 id-swb-pkc-cert OBJECT IDENTIFIER ::= { id-swb 10} 821 id-swb-ac-cert OBJECT IDENTIFIER ::= { id-swb 11} 822 id-swb-pkc-all-cert-paths OBJECT IDENTIFIER ::= { id-swb 12} 824 Conforming client implementations SHOULD be able to assert at least 825 one wantback. Conforming clients MAY be able to assert multiple 826 wantbacks. Conforming clients need not support all of the wantbacks 827 defined in this section. 829 3.2.4 validationPolicy 831 The validationPolicy item defines the validation policy that the 832 client wants the SCVP server to use during certificate validation. 833 If this policy cannot be used for any reason, then the server MUST 834 return an error response. 836 A validation policy MUST define default values for all parameters 837 necessary for processing an SCVP request. For each parameter, a 838 validation policy may either allow the client to specify a non- 839 default value or forbid the use of a non-default value. If the 840 client wishes to use the default values for all of the parameters, 841 then the client need only supply a reference to the policy in this 842 item. If the client wishes to use non-default values for one or 843 more parameters, then the client supplies a reference to the policy 844 plus whatever parameters are necessary to complete the request in 845 this item. If there are any conflicts between the policy referenced 846 in the request and any supplied parameter values in the request, 847 then the server MUST return an error response. 849 The syntax of the validationPolicy item is: 851 ValidationPolicy ::= SEQUENCE { 852 validationPolRef ValidationPolRef, 853 validationAlg [0] ValidationAlg OPTIONAL, 854 userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT 855 IDENTIFIER OPTIONAL, 856 inhibitPolicyMapping [2] BOOLEAN OPTIONAL, 857 requireExplicitPolicy [3] BOOLEAN OPTIONAL, 858 inhibitAnyPolicy [4] BOOLEAN OPTIONAL, 859 trustAnchors [5] TrustAnchors OPTIONAL, 860 keyUsages [6] SEQUENCE OF KeyUsage OPTIONAL, 861 extendedKeyUsages [7] SEQUENCE OF KeyPurposeId OPTIONAL } 863 The validationPolRef item is required, but the remaining items are 864 optional. The optional items are used to provide validation policy 865 parameters. When the client uses the validation policy's default 866 values for all parameters, all of the optional items are absent. 868 At a minimum, conforming SCVP client implementations MUST support 869 the ValidationPolRef item. Conforming client implementations MAY 870 support any or all of the optional items in ValidationPolicy. 872 Conforming SCVP servers MUST be able to process a ValidationPolicy 873 that contains any or all of the optional items. 875 The validationAlg item specifies the validation algorithm. The 876 userPolicySet item provides an acceptable set of certificate 877 policies. The inhibitPolicyMapping item inhibits certificate policy 878 mapping during certification path validation. The 879 requireExplicitPolicy item requires at least one valid certificate 880 policy in the certificate policies extension. The inhibitAnyPolicy 881 item indicates whether the anyPolicy certificate policy OID is 882 processed or ignored when evaluating certificate policy. The 883 trustAnchors item indicates the trust anchors that are acceptable to 884 the client. The keyUsages item indicates the technical usage of the 885 public key that is to be confirmed by the server as acceptable. The 886 extendedKeyUsages item indicates the application-specific usage of 887 the public key that is to be confirmed by the server as acceptable. 888 The syntax and semantics of each of these items is discussed in the 889 following sections. 891 3.2.4.1 validationPolRef 893 The reference to the validation policy is an OID that the client and 894 server have agreed represents a particular validation policy. 896 The syntax of the ValidationPolRef item is: 898 ValidationPolRef::= SEQUENCE { 899 valPolId OBJECT IDENTIFIER, 900 valPolParams ANY DEFINED BY valPolId OPTIONAL } 902 Where a validation policy supports additional policy-specific 903 parameter settings, these values are specified using the 904 valPolParams item. The syntax and semantics of the parameters 905 structure is defined by the object identifier encoded as the 906 valPolId. Where a validation policy has no parameters, such as the 907 default validation policy (see 3.2.4.1.1), this item MUST be 908 omitted. 910 Parameters specified in this item are independent of the validation 911 algorithm and the validation algorithm's parameters (see Section 912 3.2.4.2). For example, a server may support a validation policy 913 where it validates a certificate using the name validation algorithm 914 and also makes a determination regarding the creditworthiness of the 915 subject. In this case, the validation policy parameters could be 916 used to specify the value of the transaction. The validation 917 algorithm parameters are used to specify the application identifier 918 and name for the name validation algorithm. 920 Conforming SCVP client implementations MUST be able to specify a 921 validation policy. Conforming SCVP client implementations MAY be 922 able to specify parameters for a validation policy. Conforming SCVP 923 server implementations MUST be able to process valPolId and MAY be 924 able to process valPolParams. 926 3.2.4.1.1 Default Validation Policy 928 The client can request the SCVP server's default validation policy 929 or another validation policy. The default validation policy 930 corresponds to standard certification path processing as defined in 931 [PKIX-1] with server chosen default values (e.g., with a server 932 determined policy set and trust anchors). The default values can be 933 distributed out of band or using the policy request mechanism (see 934 Section 5). This mechanism permits the deployment of an SCVP server 935 without obtaining a new object identifier. 937 The object identifier that identifies the default validation policy 938 is: 940 id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 941 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 } 943 id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 } 945 The default validation policy MUST use the basic validation 946 algorithm as its default validation algorithm (see section 947 3.2.4.2.1), and has no validation policy parameters (see section 948 3.2.4.1). 950 When using the default validation policy, the client can override 951 any of the default parameter values by supplying a specific value in 952 the request. The SCVP server MUST make use of the provided 953 parameter values or return an error response. 955 Conforming implementations of SCVP servers MUST support the default 956 policy. However, an SCVP server may be configured to send an error 957 response to all requests using the default policy to meet local 958 security requirements. 960 3.2.4.2 validationAlg 962 The optional validationAlg item defines the validation algorithm to 963 be used by the SCVP server during certificate validation. The value 964 of this item can be determined by agreement between the client and 965 the server. The validation algorithm is represented by an object 966 identifier. 968 The syntax of the validationAlg is: 970 ValidationAlg ::= SEQUENCE { 971 valAlgId OBJECT IDENTIFIER, 972 parameters ANY DEFINED BY valAlgId OPTIONAL } 974 The following section specifies the basic validation algorithm and 975 the name validation algorithm. 977 SCVP servers MUST recognize and support both validation algorithms 978 defined in this section. SCVP clients that support explicit 979 assertion of the validation algorithm MUST support the basic 980 validation algorithm and SHOULD support the name validation 981 algorithm. Other validation algorithms can be specified in other 982 documents for use with specific applications. SCVP clients and 983 servers MAY support any such validation algorithms. 985 3.2.4.2.1 Basic Validation Algorithm 987 The client can request use of the SCVP basic validation algorithm or 988 another algorithm. For identity certificates, the basic validation 989 algorithm MUST implement the certification path validation algorithm 990 as defined in section 6 of [PKIX-1]. For attribute certificates, 991 the basic validation algorithm MUST implement certificate path 992 validation as defined in section 5 of [PKIX-AC]. Other validation 993 algorithms MAY implement functions over and above those in the basic 994 algorithm, but validation algorithms MUST generate results compliant 995 with the basic validation algorithm. That is, none of the 996 validation requirements in the basic algorithm may be omitted from 997 any newly defined validation algorithms. However, other validation 998 algorithms MAY reject paths that are valid using the basic 999 validation algorithm. The object identifier to identify the basic 1000 validation algorithm is: 1002 id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 } 1004 When id-svp-basicValAlg appears in valAlgId, the parameters item 1005 MUST be absent. 1007 3.2.4.2.2 Basic Validation Algorithm Errors 1009 The following errors are defined for the basic validation algorithm 1010 for inclusion in the validationErrors item in the response (see 1011 section 4.9.6). These errors can be used by any other validation 1012 algorithm since all validation algorithms MUST implement the 1013 functionality of the basic validation algorithm. 1015 id-bvae OBJECT IDENTIFIER ::= id-svp-basicValAlg 1017 id-bvae-expired OBJECT IDENTIFIER ::= { id-bvae 1 } 1018 id-bvae-not-yet-valid OBJECT IDENTIFIER ::= { id-bvae 2 } 1019 id-bvae-wrongTrustAnchor OBJECT IDENTIFIER ::= { id-bvae 3 } 1020 id-bvae-noValidCertPath OBJECT IDENTIFIER ::= { id-bvae 4 } 1021 id-bvae-revoked OBJECT IDENTIFIER ::= { id-bvae 5 } 1022 id-bvae-invalidKeyPurpose OBJECT IDENTIFIER ::= { id-bvae 9 } 1023 id-bvae-invalidKeyUsage OBJECT IDENTIFIER ::= { id-bvae 10 } 1024 id-bvae-invalidCertPolicy OBJECT IDENTIFIER ::= { id-bvae 11 } 1026 The id-bvae-expired value means that the validation time used for 1027 the request was later than the notAfter time in the end certificate 1028 (the certificate specified in the queriedCerts item). 1030 The id-bvae-not-yet-valid value means that the validation time used 1031 for the request was before the notBefore time in the end 1032 certificate. 1034 The id-bvae-wrongTrustAnchor value means that a certification path 1035 could not be constructed for the client specified trust anchor(s), 1036 but a path exists for one of the trust anchors specified in the 1037 server's default validation policy. 1039 The id-bvae-invalidKeyUsage value means that the keyUsage extension 1040 (PKIX-1 section 4.2.1.3) in the end certificate does not satisfy the 1041 validation policy. For example, the keyUsage extension in the 1042 certificate may assert only the keyEncipherment bit, but the 1043 validation policy specifies in the keyUsages item that 1044 digitalSignature is required. 1046 The id-bvae-invalidCertPolicy value means that the path is not valid 1047 under any of the policies specified in the user policy set and 1048 explicit policies are required. That is, the valid_policy_tree is 1049 NULL and the explicit_policy variable is zero (PKIX-1 section 1050 6.1.5). 1052 The id-bvae-invalidKeyPurpose value means that the extended key 1053 usage extension (PKIX-1 section 4.2.1.13) in the end certificate 1054 does not satisfy the validation policy. 1056 The id-bvae-revoked value means that the end certificate was 1057 revoked. 1059 3.2.4.2.3 Name Validation Algorithm 1061 The name validation algorithm allows the client to specify one or 1062 more subject names that MUST appear in the end certificate in 1063 addition to the requirements specified for the basic validation 1064 algorithm. The name validation algorithm allows the client to 1065 supply an application identifier and a name to the server. The 1066 application identifier defines the name matching rules to use in 1067 comparing the name supplied in the request with the names in the 1068 certificate. 1070 id-svp-nameValAlg OBJECT IDENTIFIER ::= { id-svp 2 } 1072 When the id-svp-nameValAlg appears as a valAlgId, the parameters 1073 MUST use the NameValidationAlgParms syntax: 1075 NameValidationAlgParms ::= SEQUENCE { 1076 nameCompAlgId OBJECT IDENTIFIER, 1077 validationNames GeneralNames } 1079 GeneralNames is defined in [PKIX-1]. 1081 If more than one name is supplied in the validationNames value, all 1082 names MUST be of the same type. The certificate must contain a 1083 matching name for each of the names supplied in validationNames 1084 according to the name matching rules associated with the 1085 nameCompAlgId. This specification defines three sets of name 1086 matching rules. 1088 If the nameCompAlgId supplied in the request is id-nva-dnCompAlg, 1089 then GeneralNames supplied in the request MUST be a directoryName, 1090 and the matching rules to be used are defined in [PKIX-1]. The 1091 certificate must contain a matching name in either the subject field 1092 or a directoryName in the subjectAltName extension. This 1093 specification defines the OID for id-nva-dnCompAlg as follows: 1095 id-nva-dnCompAlg OBJECT IDENTIFIER ::= { id-svp 4 } 1097 If the nameCompAlgId supplied in the request is id-kp-serverAuth 1098 [PKIX-1], then GeneralNames supplied in the request MUST be a 1099 dNSName, and the matching rules to be used are defined in [HTTP- 1100 TLS]. 1102 If the nameCompAlgId supplied in the request is id-kp-mailProtection 1103 [PKIX-1], then GeneralNames supplied in the request MUST be an 1104 rfc822Name, and the matching rules are defined in [SMIME-CERT]. 1106 Conforming SCVP servers MUST support the name validation algorithm 1107 and the matching rules associated with id-nva-dnCompAlg, id-kp- 1108 serverAuth, id-kp-mailProtection. SCVP server MAY support other 1109 name matching rules. 1111 3.2.4.2.4 Name Validation Algorithm Errors 1113 The following errors are defined for the Name Validation Algorithm: 1115 id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg 1117 id-nvae-name-mismatch OBJECT IDENTIFIER ::= { id-nvae 1 } 1118 id-nvae-no-name OBJECT IDENTIFIER ::= { id-nvae 2 } 1119 id-nvae-unknown-alg OBJECT IDENTIFIER ::= { id-nvae 3 } 1120 id-nvae-bad-name OBJECT IDENTIFIER ::= { id-nvae 4 } 1121 id-nvae-bad-name-type OBJECT IDENTIFIER ::= { id-nvae 5 } 1122 id-nvae-mixed-names OBJECT IDENTIFIER ::= { id-nvae 6 } 1124 The id-nvae-name-mismatch value means the client supplied a name 1125 with the request, which the server recognized and the server found a 1126 corresponding name type in the certificate, but was unable to find a 1127 match to the name supplied. For example, the client supplied a DNS 1128 name of example1.com, the certificate contained a DNS name of 1129 example.com. 1131 The id-nvae-no-name value means the client supplied a name with the 1132 request, which the server recognized, but the server could not find 1133 the corresponding name type in the certificate. For example, the 1134 client supplied a DNS name of example1.com, the certificate only 1135 contained a rfc822Name of user@example.com. 1137 The id-nvae-unknown-alg value means the client supplied a 1138 nameCompAlgId which the server does not recognize. 1140 The id-nvae-bad-name value means the client supplied either an empty 1141 or malformed name in the request. 1143 The id-nvae-bad-name-type value means the client supplied an 1144 inappropriate name type for the application identifier. For 1145 example, the client specified a nameCompAlgId of id-kp-serverAuth, 1146 and an rfc822Name of user@example.com. 1148 The id-nvae-mixed-names value means the client supplied multiple 1149 names in the request of different types. 1151 3.2.4.3 userPolicySet 1153 The userPolicySet item specifies a list of certificate policy 1154 identifiers that the SCVP server MUST use when constructing and 1155 validating a certification path. The userPolicySet item specifies 1156 the user-initial-policy-set as defined in Section 6 of [PKIX-1]. A 1157 userPolicySet containing the anyPolicy OID indicates a user-initial- 1158 policy-set of any-policy. 1160 SCVP clients SHOULD support userPolicySet item in requests, and SCVP 1161 servers MUST support userPolicySet item in requests. 1163 3.2.4.4 inhibitPolicyMapping 1165 The inihibitPolicyMapping item specifies an input to the 1166 certification path validation algorithm, and it controls whether 1167 policy mapping is allowed during certification path validation (see 1168 [PKIX-1], section 6.1.1). If the client wants the server to inhibit 1169 policy mapping, inhibitPolicyMapping is set to TRUE in the request. 1171 SCVP clients MAY support inhibiting policy mapping. SCVP servers 1172 SHOULD support inhibiting policy mapping. 1174 3.2.4.5 requireExplicitPolicy 1176 The requireExplicitPolicy item specifies an input to the 1177 certification path validation algorithm, and it controls whether 1178 there must be at least one valid policy in the certificate policies 1179 extension (see [PKIX-1], section 6.1.1). If the client wants the 1180 server to require at least one policy, requireExplicitPolicy is set 1181 to TRUE in the request. 1183 SCVP clients MAY support requiring explicit policies. SCVP servers 1184 SHOULD support requiring explicit policies. 1186 3.2.4.6 inhibitAnyPolicy 1188 The inhibitAnyPolicy item specifies an input to the certification 1189 path validation algorithm (see [PKIX-1], section 6.1.1), and it 1190 controls whether the anyPolicy OID is processed or ignored when 1191 evaluating certificate policy. If the client wants the server to 1192 ignore the anyPolicy OID, inhibitAnyPolicy MUST be set to TRUE in 1193 the request. 1195 SCVP clients MAY support ignoring the anyPolicy OID. SCVP servers 1196 SHOULD support ignoring the anyPolicy OID. 1198 3.2.4.7 trustAnchors 1200 The trustAnchors item specifies the trust anchors at which the 1201 certification path must terminate if the path is to be considered 1202 valid by the SCVP server for the request. If a trustAnchors item is 1203 present, the server MUST NOT consider any certification paths ending 1204 in other trust anchors as valid. 1206 The TrustAnchors type contains one or more trust anchor 1207 specifications. A certificate reference can be used to identify the 1208 trust anchor by certificate hash and distinguished name with serial 1209 number. Alternatively, trust anchors can be provided directly. The 1210 order of trust anchor specifications within the sequence is not 1211 important. Any CA certificate that meets the requirements of [PKIX- 1212 1] for signing certificates can be provided as a trust anchor. If a 1213 trust anchor is supplied that does not meet these requirements, the 1214 server MUST return an error response. 1216 The trust anchor itself, regardless of its form, MUST NOT be 1217 included in any certification path returned by the SCVP server. 1219 TrustAnchors has the following syntax: 1221 TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF PKCReference 1223 SCVP server MUST support trustAnchors. SCVP clients SHOULD support 1224 trustAnchors. 1226 3.2.4.8 keyUsages 1228 The key usage extension [PKIX-1, section 4.2.1.3] in the certificate 1229 defines the technical purpose (such as encipherment, signature, and 1230 CRL signing) of the key contained in the certificate. If the client 1231 wishes to confirm the technical usage, then it can communicate the 1232 usage it wants to validate by the same structure using the same 1233 semantics as defined in [PKIX-1]. For example, if the client 1234 obtained the certificate in the context of a digital signature, it 1235 can confirm this use by including a keyUsage structure with the 1236 digital signature bit set. 1238 If the keyUsages item is present and contains an empty sequence, it 1239 indicates that the client does not require any particular key usage. 1241 If the keyUsages item contains one or more keyUsage definitions, 1242 then the certificate MUST satisfy at least one of the specified 1243 keyUsage definitions. If the client is willing to accept multiple 1244 possibilities then the client passes in a sequence of possible 1245 patterns. Each keyUsage can contain a set of one or more bits set 1246 in the request, all bits MUST be present in the certificate to match 1247 against an instance of the keyUsage in the SCVP request. If the 1248 certificate key usage extension contains more usages than requested, 1249 then the certificate MUST be considered a match. For example, if a 1250 client wishes to check for either digital signature or non- 1251 repudiation, then the client provides two keyUsage values, one with 1252 digital signature set and the other with non-repudiation set. If 1253 the key usage extension is absent from the certificate, the 1254 certificate MUST be considered good for all usages and therefore any 1255 pattern in the SCVP request will match. 1257 SCVP clients SHOULD support keyUsages, and SCVP servers MUST support 1258 keyUsages. 1260 3.2.4.9 extendedKeyUsages 1262 The extended key usage extension [PKIX-1, section 4.2.1.13] defines 1263 more specific technical purposes, in addition to or in place of the 1264 purposes indicated in the key usage extension, for which the 1265 certified public key may be used. If the client wishes to confirm 1266 the extended key usage, then it can communicate the usage it wants 1267 to validate by the same extension using the same semantics as 1268 defined in [PKIX-1]. For example, if the client obtained the 1269 certificate in the context of a TLS server, it can confirm this 1270 usage by including the extended key usage structure with the id-kp- 1271 serverAuth object identifier. If the extension is absent or is 1272 present and asserts the anyExtendedKeyUsage OID, then all usages 1273 specified in the request are a match. If the extension is present 1274 and more than one usage is set in the request, all usages MUST be 1275 present in the certificate. If the certificate extension contains 1276 more usages than requested, then the certificate MUST be considered 1277 a match. 1279 Where the client does not require any particular extended key usage, 1280 the client can specify an empty SEQUENCE. This may be used to 1281 override extended key usage requirements imposed in the validation 1282 policy specified by valPolId. 1284 SCVP clients SHOULD support extendedKeyUsages, and SCVP servers MUST 1285 support extendedKeyUsages. 1287 3.2.5 responseFlags 1288 The optional response flags item allows the client to indicate which 1289 optional features in the CVResponse it wants the server to include. 1290 If the default values for all of the flags are used, then the 1291 response flags item MUST NOT be included in the request. 1293 The syntax of the responseFlags is: 1295 ResponseFlags ::= SEQUENCE { 1296 fullRequestInResponse [0] BOOLEAN DEFAULT FALSE, 1297 responseValidationPolByRef [1] BOOLEAN DEFAULT TRUE, 1298 protectResponse [2] BOOLEAN DEFAULT TRUE, 1299 cachedResponse [3] BOOLEAN DEFAULT TRUE } 1301 Each of the response flags is described in the following sections. 1303 3.2.5.1 fullRequestInResponse 1305 By default, the server includes a hash of the request in non-cached 1306 responses to allow the client to identify the response. If the 1307 client wants the server to include the full request in the non- 1308 cached response, fullRequestInResponse is set to TRUE. The main 1309 reason a client would request the server to include the full request 1310 in the response is to archive the request-response exchange in a 1311 single object. That is, the client wants to archive a single object 1312 that includes both request and response. 1314 SCVP clients and servers MUST support the default behavior. SCVP 1315 clients MAY support requesting and processing the full request. 1316 SCVP servers SHOULD support returning the full request. 1318 3.2.5.2 responseValidationPolByRef 1320 The responseValidationPolByRef item controls whether the response 1321 includes just a reference to the policy or a reference to the policy 1322 plus all the parameters by value of the policy used to process the 1323 request. The response MUST contain a reference to the validation 1324 policy. If the client wants the validation policy parameters to be 1325 also included by value, then responseValidationPolByRef is set to 1326 FALSE. The main reason a client would request the server to include 1327 validation policy to be included by value is to archive the request- 1328 response exchange in a single object. That is, the client wants to 1329 archive the CVResponse and have it include every aspect of the 1330 validation policy. 1332 SCVP clients and servers MUST support the default behavior. SCVP 1333 clients MAY support requesting and processing the validation policy 1334 by values. SVCP server SHOULD support returning the validation 1335 policy by values. 1337 3.2.5.3 protectResponse 1339 The protectResponse item indicates whether the client requires the 1340 server to protect the response. If the client is performing full 1341 certification path validation on the response and it is not 1342 concerned about the source of the response, then the client does not 1343 benefit from a digital signature or MAC on the response. In this 1344 case, the client can indicate to the server that protecting the 1345 message is unnecessary. However, the server is always permitted to 1346 return a protected response. 1348 SCVP clients that support delegated path discovery (DPD) as defined 1349 in [RQMTS] MUST support setting this value to FALSE. 1351 SCVP clients that support delegated path validation (DPV) as defined 1352 in [RQMTS] require an authenticated response. Unless a protected 1353 transport mechanism (such a TLS) is used, such clients MUST always 1354 set this value to TRUE or omit the responseFlags item entirely, 1355 which requires the server to return a protected response. 1357 SCVP servers MUST support returning protected responses, and SCVP 1358 servers SHOULD support returning unprotected responses. Based on 1359 local policy, the server can be configured to return protected or 1360 unprotected responses if this value is set to FALSE. If based on 1361 local policy the server is unable to return protected responses, 1362 then the server MUST return an error if this value is set to TRUE. 1364 3.2.5.4 cachedResponse 1366 The cachedResponse item indicates whether the client will accept a 1367 cached response. To enhance performance and limit the exposure of 1368 signing keys, an SCVP service may be designed to cache responses 1369 until new revocation information is expected. Where cachedResponse 1370 is set to TRUE, the client will accept a previously cached response. 1372 Clients may insist on creation of a fresh response to protect 1373 against a replay attack and ensure information is up to date. Where 1374 cachedResponse is FALSE, the client will not accept a cached 1375 response. To ensure that a response is fresh, the client MUST also 1376 include the requestNonce as defined in Section 3.4. 1378 Servers MUST process the cachedResponse flag. Where cachedResponse 1379 is FALSE, servers that cannot produce fresh responses MUST reply 1380 with an error message. Servers MAY choose to provide fresh 1381 responses even where cachedResponse is set to TRUE. 1383 3.2.6 serverContextInfo 1384 The optional serverContextInfo item, if present, contains context 1385 from a previous request-response exchange with the same SCVP server. 1386 It allows the server to return more than one certification path for 1387 the same certificate to the client. For example, if a server 1388 constructs a particular certification path for a certificate, but 1389 the client finds it unacceptable, the client can then send the same 1390 query back to the server with the serverContextInfo from the first 1391 response, and the server will be able to provide a different 1392 certification path (if another one can be found). 1394 Contents of the serverContextInfo are opaque to the SCVP client. 1395 That is, the client only knows that it needs to return the value 1396 provided by the server with the subsequent request to get a 1397 different certification path. Note that the subsequent query needs 1398 to be identical to the previous query with the exception of the 1399 following: 1401 - requestNonce; 1403 - serverContextInfo; and 1405 - the client's digital signature or MAC on the request. 1407 SCVP clients MAY support serverContextInfo, and SCVP servers SHOULD 1408 support serverContextInfo. 1410 3.2.7 validationTime 1412 The optional validationTime item, if present, tells the date and 1413 time relative to which the SCVP client wants the server to perform 1414 the checks. If the validationTime is not present, the server MUST 1415 perform the validation using the date and time at which the server 1416 processes the request. If the validationTime is present, it MUST be 1417 encoded as GeneralizedTime. The validationTime provided MUST be a 1418 retrospective time since the server can only perform a validity 1419 check using the current time (default) or previous time. A server 1420 can ignore the validationTime provided in the request if the time is 1421 within the clock skew of the server's current time. 1423 The revocation status information is obtained with respect to the 1424 validation time. When specifying a validation time other than the 1425 current time, the validation time should not necessarily be 1426 identical to the time when the private key was used. The validation 1427 time specified by the client may be adjusted to compensate for: 1429 1) time for the end-entity to realize that its private key has 1430 been or could possibly be compromised, and/or 1432 2) time for the end-entity to report the key compromise, and/or 1433 3) time for the revocation authority to process the revocation 1434 request from the end-entity, and/or 1436 4) time for the revocation authority to update and distribute 1437 the revocation status information. 1439 GeneralizedTime values MUST be expressed in Universal Coordinated 1440 Time (UTC) (which is also known as Greenwich Mean Time and Zulu 1441 time) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), 1442 even when the number of seconds is zero. GeneralizedTime values 1443 MUST NOT include fractional seconds. 1445 The information in the corresponding CertReply item in the response 1446 MUST be formatted as if the server created the response at the time 1447 indicated in the validationTime. However, if the server does not 1448 have appropriate historical information, the server MUST return an 1449 error response. 1451 SCVP servers MUST apply a clock skew to the validity time to allow 1452 for minor time synchronization errors. The default value is 10 1453 minutes. If the server uses a value other than the default it MUST 1454 include the clock skew value in the validation policy response. 1456 SCVP clients MAY support validationTime other than the current time. 1457 SCVP servers MUST support using its current time, and SHOULD support 1458 the client setting the validationTime in the request. 1460 3.2.8 intermediateCerts 1462 The optional intermediateCerts item may help the SCVP server create 1463 valid certification paths. The intermediateCerts item, when 1464 present, provides certificates that the server MAY use when forming 1465 a certification path. When building certification paths, the server 1466 MAY use the certificates in the intermediateCerts item in addition 1467 to any other certificates that the server can access. When present, 1468 the intermediateCerts item MUST contain at least one certificate, 1469 and the intermediateCerts item MUST be structured as a CertBundle. 1470 The certificates in the intermediateCerts item MUST NOT be 1471 considered as valid by the server just because they are present in 1472 this item. 1474 The CertBundle type contains one or more certificates. The order of 1475 the entries in the bundle is not important. CertBundle has the 1476 following syntax: 1478 CertBundle ::= SEQUENCE SIZE (1..MAX) OF Certificate 1480 SCVP clients SHOULD support intermediateCerts, and SCVP servers MUST 1481 support intermediateCerts. 1483 3.2.9 revInfos 1485 The optional revInfos item specifies revocation information such as 1486 CRLs, delta CRLs [PKIX-1], and OCSP responses [OCSP] that the SCVP 1487 server MAY use when validating certification paths. The purpose of 1488 the revInfos item is to provide revocation information to which the 1489 server might not otherwise have access, such as an OCSP response 1490 that the client received along with the certificate. Note that the 1491 information in the revInfos item might not be used by the server. 1492 For example, the revocation information might be associated with 1493 certificates that the server does not use in the certification path 1494 that it constructs. 1496 Clients SHOULD be courteous to the SCVP server by separating CRLs 1497 and delta CRLs. However, since the two share a common syntax, SCVP 1498 servers SHOULD accept delta CRLs even if they are identified as 1499 regular CRLs by the SCVP client. 1501 CRLs, delta CRLs, and OCSP responses can be provided as revocation 1502 information. If needed, additional object identifiers can be 1503 assigned for additional revocation information types in the future. 1505 The revInfos item uses the RevocationInfos type, which has the 1506 following syntax: 1508 RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo 1510 RevocationInfo ::= CHOICE { 1511 crl [0] CertificateList, 1512 delta-crl [1] CertificateList, 1513 ocsp [2] OCSPResponse, 1514 other [3] OtherRevInfo } 1516 OtherRevInfo ::= SEQUENCE { 1517 riType OBJECT IDENTIFIER, 1518 riValue ANY DEFINED BY riType } 1520 3.2.10 producedAt 1522 The client MAY allow the server to use a cached SCVP response. When 1523 doing so, the client MAY use the producedAt item to express 1524 requirements on the freshness of the cached response. The 1525 producedAt item tells the earliest date and time at which an 1526 acceptable cached response could have been produced. The producedAt 1527 item represents the date and time in UTC, using the GeneralizedTime 1528 type. The value in the producedAt item is independent of the 1529 validation time. 1531 GeneralizedTime value MUST be expressed in UTC, as defined in 1532 section 3.2.7. 1534 SCVP clients MAY support using producedAt values in the request. 1535 SCVP servers MAY support the producedAt values in the request. SCVP 1536 servers that support cached responses SHOULD support the producedAt 1537 value in requests. 1539 3.2.11 queryExtensions 1541 The optional queryExtensions item contains Extensions. If present, 1542 each extension in the sequence extends the query. This 1543 specification does not define any extensions; the facility is 1544 provided to allow future specifications to extend SCVP. The syntax 1545 for extensions is imported from [PKIX-1]. The queryExtensions item, 1546 when present, MUST contain a sequence of extension items, and each 1547 of the extensions MUST contain extnID, critical, and extnValue 1548 items. Each of these is described in the following sections. 1550 3.2.11.1 extnID 1552 The extnID item is an identifier for the extension. It contains the 1553 object identifier that names the extension. 1555 3.2.11.2 critical 1557 The critical item is a BOOLEAN. Each extension is designated as 1558 either critical (with a value of TRUE) or non-critical (with a value 1559 of FALSE). By default, the extension is non-critical. An SCVP 1560 server MUST reject the query if it encounters a critical extension 1561 that it does not recognize; however, a non-critical extension MAY be 1562 ignored if it is not recognized, but MUST be processed if it is 1563 recognized. 1565 3.2.11.3 extnValue 1567 The extnValue item is an octet string, which contains the extension 1568 value. An ASN.1 type is specified for each extension, identified by 1569 the associated extnID object identifier. 1571 3.3 requestorRef 1573 The optional requestorRef item contains a SEQUENCE of names 1574 identifying SCVP servers, and it is intended for use in environments 1575 where SCVP relay is employed. As described in [RQMTS], in some 1576 network environments an SCVP server might not be able to obtain all 1577 of the information that it needs to process a request. However, the 1578 SCVP server might be configured to use the services of one or more 1579 other SCVP servers to fulfill all requests. In such cases, the 1580 client is unaware that the queried SCVP server is using the services 1581 of other SCVP servers, and the client-queried SCVP server acts as an 1582 SCVP client to another SCVP server. Unlike the original client, the 1583 SCVP server is expected to have moderate computing and memory 1584 resources, enabling the use of relay, re-direct or multicasting 1585 mechanisms. The requestorRef item is used to detect looping in some 1586 configurations. The value and use of requestorRef is defined in 1587 section 7. To detect loops, the server MUST inspect the sequence of 1588 names, looking for the value that it inserted as a client. 1590 Conforming SCVP clients MAY support specification of the 1591 requestorRef value. Conforming SCVP server implementations MUST 1592 process the requestorRef value if present. If the SCVP client 1593 includes a requestorRef value in the request, then the SCVP server 1594 MUST return the same value in a non-cached response. The SCVP 1595 server MAY omit the requestorRef value from cached SCVP responses. 1597 The requestorRef item MUST be a sequence of GeneralName. No 1598 provisions are made to ensure uniqueness of the requestorRef 1599 GeneralName values. 1601 3.4 requestNonce 1603 The optional requestNonce item contains a request identifier 1604 generated by the SCVP client. If the client includes a requestNonce 1605 value in the request, it is expressing a preference that the SCVP 1606 server SHOULD return a non-cached response. If the server returns a 1607 non-cached response it MUST include the value of requestNonce from 1608 the request in the response as the respNonce item; however, the 1609 server MAY return a cached response which MUST NOT have a respNonce. 1611 SCVP clients that insist on creation of a fresh response (e.g., to 1612 protect against a replay attack or ensure information is up to date) 1613 MUST support requestNonce. Conforming SCVP server implementations 1614 MUST process the requestNonce value if present. 1616 If the client includes a requestNonce and also sets the 1617 cachedResponse flag to FALSE as defined in section 3.2.5.4, the 1618 client is indicating that the SCVP server MUST return either a non- 1619 cached response including the respNonce or an error response. The 1620 client SHOULD include a requestNonce item in every request to 1621 prevent an attacker from acting as a man-in-the-middle by replaying 1622 old responses from the server. The requestNonce value SHOULD change 1623 with every request sent by the client. 1625 The client MUST NOT set the cachedResponse flag to FALSE without 1626 also including a requestNonce. A server receiving such a request 1627 SHOULD return an invalidRequest error response. 1629 The requestNonce item, if present, MUST be an octet string that was 1630 generated exclusively for this request. 1632 3.5 requestorName 1634 The optional requestorName item is used by the client to include an 1635 identifier in the request. The client MAY include this information 1636 for the DPV server to copy into the response. 1638 Conforming SCVP clients MAY support specification of this item in 1639 requests. SCVP servers MUST be able to process requests that 1640 include this item. 1642 3.6 responderName 1644 The optional responderName item is used by the client to indicate 1645 the identity of the SCVP server that the client expects to sign the 1646 SCVP response if the response is digitally signed. The 1647 requestorName item SHOULD only be included if: 1649 1. the request is either unprotected or digitally signed (i.e., is 1650 not protected using a MAC); and 1651 2. the responseFlags item is either absent or present with the 1652 protectResponse set to TRUE. 1654 Conforming SCVP clients MAY support specification of this item in 1655 requests. SCVP servers MUST be able to process requests that 1656 include this item. SCVP servers that maintain a single private key 1657 for signing SCVP responses or that are unable to return digitally 1658 signed responses MAY ignore the value in this item. SCVP servers 1659 that maintain more than one private key for signing SCVP responses 1660 SHOULD either (a) digitally sign the response using a private key 1661 that corresponds to a certificate that includes the name specified 1662 in responderName in either subject field or subjectAltName extension 1663 or (b) return a error indicating that the server does not possess a 1664 certificate that asserts the specified name. 1666 3.7 requestExtensions 1668 The OPTIONAL requestExtensions item contains Extensions. If 1669 present, each Extension in the sequence extends the request. This 1670 specification does not define any extensions; the facility is 1671 provided to allow future specifications to extend SCVP. The syntax 1672 for Extensions is imported from [PKIX-1]. The requestExtensions 1673 item, when present, MUST contain a sequence of extension items, and 1674 each of extension MUST contain extnID, critical, and extnValue 1675 items. Each of these is described in the following sections. 1677 3.7.1 extnID 1679 The extnID item is an identifier for the extension. It contains the 1680 object identifier that names the extension. 1682 3.7.2 critical 1684 The critical item is a BOOLEAN. Each extension is designated as 1685 either critical (with a value of TRUE) or non-critical (with a value 1686 of FALSE). By default, the extension is non-critical. An SCVP 1687 server MUST reject the query if it encounters a critical extension 1688 it does not recognize. A non-critical extension MAY be ignored if it 1689 is not recognized, but MUST be processed if it is recognized. 1691 3.7.3 extnValue 1693 The extnValue item contains an octet string. Within the octet 1694 string is the extension value. An ASN.1 type is specified for each 1695 extension, identified by the associated extnID object identifier. 1697 3.8 signatureAlg 1699 The signatureAlg item contains an AlgorithmIdentifier indicating 1700 which algorithm the server should use to sign the response message. 1701 The signatureAlg item SHOULD only be included if: 1703 1. the request is either unprotected or digitally signed (i.e., is 1704 not protected using a MAC); and 1705 2. the responseFlags item is either absent or present with the 1706 protectResponse set to TRUE. 1708 If included, the signatureAlg item SHOULD specify one of the 1709 signature algorithms specified in the signatureGeneration item of 1710 the server's validation policy response message. 1712 SCVP servers MUST be able to process requests that include this 1713 item. If the server is returning a digitally signed response to 1714 this message, then: 1716 1. If the signatureAlg item is present and specifies an algorithm 1717 that is included in the signatureGeneration item of the 1718 server's validation policy response message, the server MUST 1719 sign the response using the signature algorithm specified in 1720 signatureAlg. 1722 2. Otherwise, if the signatureAlg item is absent or is present but 1723 specifies an algorithm that is not supported by the server, the 1724 server MUST sign the response using the server's default 1725 signature algorithm as specified in the signatureGeneration 1726 item of the server's validation policy response message. 1728 3.9 hashAlg 1730 The hashAlg item contains an OBJECT IDENTIFIER indicating which hash 1731 algorithm the server should use to compute the hash value for the 1732 requestHash item in the response. SCVP clients SHOULD NOT include 1733 this item if fullRequestInResponse is set to TRUE. If included, the 1734 hashAlg item SHOULD specify one of the hash algorithms specified in 1735 the hashAlgorithms item of the server's validation policy response 1736 message. 1738 SCVP servers MUST be able to process requests that include this 1739 item. If the server is returning a response to this message that 1740 includes a requestHash then: 1742 1. If the hashAlg item is present and specifies an algorithm that 1743 is included in the hashAlgorithms item of the server's 1744 validation policy response message, the server MUST use the 1745 algorithm specified in hashAlg to compute the requestHash. 1747 2. Otherwise, if the hashAlg item is absent or is present but 1748 specifies an algorithm that is not supported by the server, the 1749 server MUST compute the requestHash using the server's default 1750 hash algorithm as specified in the hashAlgorithms item of the 1751 server's validation policy response message. 1753 3.10 SCVP Request Authentication 1755 It is a matter of local policy what validation policy the server 1756 uses when authenticating requests. When authenticating protected 1757 SCVP requests, the SCVP servers SHOULD use the validation algorithm 1758 defined in section 6 of [PKIX-1]. 1760 If the certificate used to validate a SignedData validation request 1761 includes the key usage extension [PKIX-1, section 4.2.1.3], it MUST 1762 have either the digital signature bit set, the non-repudiation bit 1763 set, or both bits set. 1765 If the certificate used to validate an AuthenticatedData validation 1766 request includes the key usage extension, it MUST have the key 1767 agreement bit set. 1769 If the certificate used on a validation request contains the 1770 extended key usage extension [PKIX-1, section 4.2.1.13], the server 1771 SHALL verify that it contains the SCVP client OID or another OID 1772 acceptable to the server. The SCVP client OID is defined as 1773 follows: 1775 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 1777 id-kp-scvpClient OBJECT IDENTIFIER ::= { id-kp 16 } 1779 If a protected request fails to meet the validation policy of the 1780 server, it MUST be treated as an unauthenticated request. 1782 4 Validation Response 1784 An SCVP server response to the client MUST be a single CVResponse 1785 item. When a CVResponse is encapsulated in a MIME body part, 1786 application/cv-response MUST be used. 1788 There are a number of forms of an SCVP response: 1790 1. A success response to a request made over a protected transport 1791 such as TLS. These responses SHOULD NOT be protected by the 1792 server. 1794 2. A success response to a request that has protectResponse set to 1795 FALSE. These responses SHOULD NOT be protected by the server. 1797 3. The server MUST protect all other success responses. If the 1798 server is unable to return a protected success response due to 1799 local policy, then it MUST return an error response. 1801 4. An error response to a request made over a protected transport 1802 such as TLS. These responses SHOULD NOT be protected by the 1803 server 1805 5. An error response to a request that has protectResponse set to 1806 FALSE. These responses SHOULD NOT be protected by the server. 1808 6. An error response to an authenticated request. The server 1809 SHOULD protect these responses. 1811 7. An error response to an AuthenticatedData request where MAC is 1812 valid. The server MUST protect these responses. 1814 8. All other error responses MUST NOT be protected by the server. 1816 Successful responses are made when the server has fully complied 1817 with the request. That is, the server was able to build a 1818 certification path using the referenced or supplied validation 1819 policy, and it was able to comply with all the requested parameters. 1821 If the server is unable to perform validations using the required 1822 validation policy or the request contains an unsupported option, 1823 then the server MUST return an error response. 1825 For protected requests and responses, SCVP servers MUST support 1826 SignedData and SHOULD support AuthenticatedData. It is a matter of 1827 local policy which types are used. 1829 If the server is making a protected response to a protected request, 1830 then the server MUST use the same protection mechanism (SignedData 1831 or AuthenticatedData) as in the request. 1833 An overview of the structure used for an unprotected response is 1834 provided below. Many details are not shown, but the way that SCVP 1835 makes use of CMS is clearly illustrated. 1837 ContentInfo { 1838 contentType id-ct-scvp-certValResponse, 1839 -- (1.2.840.113549.1.9.16.1.11) 1840 content CVResponse } 1842 The protected response consists of a CVResponse encapsulated in 1843 either a SignedData or an AuthenticatedData, which is in turn 1844 encapsulated in a ContentInfo. That is, the EncapsulatedContentInfo 1845 field of either SignedData or AuthenticatedData consists of an 1846 eContentType field with a value of id-ct-scvp-certValResponse and an 1847 eContent field that contains a DER encoded CVResponse. 1849 The SCVP server MUST include its own certificate in the certificates 1850 field within SignedData. Other certificates MAY also be included. 1851 The SCVP server MAY also provide one or more CRLs in the crls field 1852 within SignedData. The signerInfos field of SignedData MUST include 1853 exactly one SignerInfo. The SignedData MUST NOT include the 1854 unsignedAttrs field. 1856 The signedAttrs field within SignerInfo MUST include the content- 1857 type and message-digest attributes defined in [CMS], and it SHOULD 1858 include the signing-certificate attribute as defined in [ESS]. 1859 Within the signing-certificate attribute, the first certificate 1860 identified in the sequence of certificate identifiers MUST be the 1861 certificate of the SCVP server. The inclusion of other certificate 1862 identifiers in the signing-certificate attribute is OPTIONAL. The 1863 inclusion of policies in the signing-certificate is OPTIONAL. 1865 The recipientInfos field of AuthenticatedData MUST include exactly 1866 one RecipientInfo, which contains information for the client that 1867 sent the request. The AuthenticatedData MUST NOT include the 1868 unauthAttrs field. 1870 The CVResponse item contains the server's response. The CVResponse 1871 MUST contain the cvResponseVersion, serverConfigurationID, 1872 producedAt, and responseStatus items. The CVResponse MAY also 1873 contain the respValidationPolicy, requestRef, requestorRef, 1874 requestorName, replyObjects, respNonce, serverContextInfo, and 1875 cvResponseExtensions items. The replyObjects item MUST contain 1876 exactly one CertReply item for each certificate requested. The 1877 requestorRef item MUST be included if the request included a 1878 requestorRef item and a non-cached response is provided. The 1879 respNonce item MUST be included if the request included a 1880 requestNonce item and a non-cached response is provided. 1882 The CVResponse MUST have the following syntax: 1884 CVResponse ::= SEQUENCE { 1885 cvResponseVersion INTEGER, 1886 serverConfigurationID INTEGER, 1887 producedAt GeneralizedTime, 1888 responseStatus ResponseStatus, 1889 respValidationPolicy [0] RespValidationPolicy OPTIONAL, 1890 requestRef [1] RequestReference OPTIONAL, 1891 requestorRef [2] GeneralNames OPTIONAL, 1892 requestorName [3] GeneralNames OPTIONAL, 1893 replyObjects [4] ReplyObjects OPTIONAL, 1894 respNonce [5] OCTET STRING OPTIONAL, 1895 serverContextInfo [6] OCTET STRING OPTIONAL, 1896 cvResponseExtensions [7] Extensions OPTIONAL } 1898 Conforming SCVP servers MAY be capable of constructing a CVResponse 1899 that includes the serverContextInfo or cvResponseExtensions items. 1900 Conforming SCVP servers MUST be capable of constructing a CVResponse 1901 with any of the remaining optional items. Conforming SCVP clients 1902 MUST be capable of processing a CVResponse with the following 1903 optional items: respValidationPolicy; requestRef; requestorName; 1904 replyObjects; and respNonce. 1906 Conforming SCVP clients that are capable of including requestorRef 1907 in a request MUST be capable of processing a CVResponse that 1908 includes the requestorRef item. Conforming SCVP clients MUST be 1909 capable of processing a CVResponse that includes the 1910 serverContextInfo or cvResponseExtensions items. Conforming clients 1911 MUST be able to determine if critical extensions are present in the 1912 cvResponseExtensions item. 1914 4.1 cvResponseVersion 1916 The syntax and semantics of cvResponseVersion are the same as 1917 cvRequestVersion as described in section 3.1. The cvResponseVersion 1918 MUST match the cvRequestVersion in the request. If the server 1919 cannot generate a response with a matching version number, then the 1920 server MUST return an error response that indicates the highest 1921 version number that the server supports as the version number. 1923 4.2 serverConfigurationID 1925 The server configuration ID represents the version of the SCVP 1926 server configuration when it processed the request. See section 6.4 1927 for details. 1929 4.3 producedAt 1931 The producedAt item tells the date and time at which the SCVP server 1932 generated the response. The producedAt item MUST be expressed in 1933 UTC, and it MUST be interpreted as defined in section 3.2.7. This 1934 value is independent of the validation time. 1936 4.4 responseStatus 1938 The responseStatus item gives status information to the SCVP client 1939 about its request. The responseStatus item has a numeric status 1940 code and an optional string that is a sequence of characters from 1941 the ISO/IEC 10646-1 character set encoded with the UTF-8 1942 transformation format defined in [UTF8]. 1944 The string MAY be used to transmit status information. The client 1945 MAY choose to display the string to a human user. However, because 1946 there is often no way to know the languages understood by a human 1947 user, the string may be of little or no assistance. 1949 The responseStatus item uses the ResponseStatus type, which has the 1950 following syntax: 1952 ResponseStatus ::= SEQUENCE { 1953 statusCode CVStatusCode DEFAULT okay, 1954 errorMessage UTF8String OPTIONAL } 1956 CVStatusCode ::= ENUMERATED { 1957 okay (0), 1958 skipUnrecognizedItems (1), 1959 tooBusy (10), 1960 invalidRequest (11), 1961 internalError (12), 1962 badStructure (20), 1963 unsupportedVersion (21), 1964 abortUnrecognizedItems (22), 1965 unrecognizedSigKey (23), 1966 badSignatureOrMAC (24), 1967 unableToDecode (25), 1968 notAuthorized (26), 1969 unsupportedChecks (27), 1970 unsupportedWantBacks (28), 1971 unsupportedSignatureOrMAC (29), 1972 invalidSignatureOrMAC (30), 1973 protectedResponseUnsupported (31), 1974 unrecognizedResponderName (32), 1975 relayingLoop (40), 1976 unrecognizedValPol (50), 1977 unrecognizedValAlg (51), 1978 fullRequestInResponseUnsupported (52), 1979 fullPolResponseUnsupported (53), 1980 inhibitPolicyMappingUnsuported (54), 1981 requireExplicitPolicyUnsupported (55), 1982 inhibitAnyPolicyUnsupported (56), 1983 validityTimeUnsupported (57), 1984 unrecognizedCritQueryExt (63), 1985 unrecognizedCritRequestExt (64) } 1987 The CVStatusCode values have the following meaning: 1989 0 The request was fully processed. 1990 1 The request included some unrecognized non-critical extensions; 1991 however, processing was able to continue ignoring them. 1992 10 Too busy; try again later. 1993 11 The server was able to decode the request, but there was some 1994 other problem with the request. 1995 12 An internal server error occurred. 1996 20 The structure of the request was wrong. 1997 21 The version of request is not supported by this server. 1998 22 The request included unrecognized items, and the server was not 1999 able to continue processing. 2000 23 The server could not validate the key used to protect the 2001 request. 2002 24 The signature or message authentication code did not match the 2003 body of the request. 2004 25 The encoding was not understood. 2005 26 The request was not authorized. 2006 27 The request included unsupported checks items, and the server 2007 was not able to continue processing. 2008 28 The request included unsupported want back items, and the 2009 server was not able to continue processing. 2010 29 The server does not support the signature or message 2011 authentication code algorithm used by the client to protect the 2012 request. 2013 30 The server could not validate the client's signature or message 2014 authentication code on the request. 2015 31 The server could not generate a protected response as requested 2016 by the client. 2018 32 The server does not have a certificate matching the requested 2019 responder name. 2020 40 The request was previously relayed by the same server. 2021 50 The request contained an unrecognized validation policy 2022 reference. 2023 51 The request contained an unrecognized validation algorithm OID. 2024 52 The server does not support returning the full request in the 2025 response. 2026 53 The server does not support returning the full validation 2027 policy by value in the response. 2028 54 The server does not support inhibiting policy mapping. 2029 55 The server does not support requiring explicit policy. 2030 56 The server does not support ignoring the anyPolicy certificate 2031 policy OID. 2032 57 The server only validates requests using current time. 2033 63 The query item in the request contains a critical extension 2034 whose OID is not recognized. 2035 64 The request contains a critical request extension whose OID is 2036 not recognized. 2038 Status codes 0-9 are reserved for codes that indicate the request 2039 was processed by the server and therefore MUST be sent in a success 2040 response. Status codes 10 and above indicate an error and MUST 2041 therefore be sent in an error response. 2043 4.5 respValidationPolicy 2045 The respValidationPolicy item contains either a reference to the 2046 full validation policy or the full policy by value used by the 2047 server to validate the request. It MUST be present in success 2048 responses and MUST NOT be present in error responses. The choice 2049 between returning the policy by reference or by value is controlled 2050 by the responseValidationPolByRef item in the request. The 2051 resultant validation policy is the union of the following: 2053 1. Values from the request. 2055 2. For values that are not explicitly included in the request, 2056 values from the validation policy specified by reference in 2057 the request. 2059 The RespValidationPolicy syntax is: 2061 RespValidationPolicy ::= ValidationPolicy 2063 The validationPolicy item is defined in section 3.2.4. When 2064 responseValidationPolByRef is set to FALSE in the request, all items 2065 in the validationPolicy item MUST be populated. When 2066 responseValidationPolByRef is set to TRUE, OPTIONAL items in the 2067 validationPolicy item only need to be populated for items for which 2068 the value in the request differs from the value from the referenced 2069 validation policy. 2071 Conforming SCVP clients MUST be capable of processing the validation 2072 policy by reference. SCVP clients MAY be capable of processing the 2073 optional items in the validation policy. 2075 Conforming SCVP server implementations MUST be capable of asserting 2076 the policy by reference, and MUST be capable of including the 2077 optional items. 2079 4.6 requestRef 2081 The requestRef item allows the SCVP client to identify the request 2082 that corresponds to this response from the server. It associates 2083 the response to a particular request using either a hash of the 2084 request or a copy of CVRequest from the request. 2086 The requestRef item does not provide authentication, but does allow 2087 the client to determine that the request was not maliciously 2088 modified. 2090 The requestRef item allows the client to associate a response with a 2091 request. The requestNonce provides an alternative mechanism for 2092 matching requests and responses. When the fullRequest alternative 2093 is used, the response provides a single data structure that is 2094 suitable for archive of the transaction. 2096 The requestRef item uses the RequestReference type, which has the 2097 following syntax: 2099 RequestReference ::= CHOICE { 2100 requestHash [0] HashValue, -- hash of CVRequest 2101 fullRequest [1] CVRequest } 2103 SCVP clients MUST support requestHash, and they MAY support 2104 fullRequest. SCVP servers MUST support using requestHash, and they 2105 SHOULD support using fullRequest. 2107 4.6.1 requestHash 2109 The requestHash item is the hash of the CVRequest. The one-way hash 2110 function used to compute the hash of the CVRequest is as specified 2111 in section 3.9. The requestHash item serves two purposes. First, 2112 it allows a client to determine that the request was not maliciously 2113 modified. Second, it allows the client to associate a response with 2114 a request when using connectionless protocols. The requestNonce 2115 provides an alternative mechanism for matching requests and 2116 responses. 2118 The requestHash item uses the HashValue type, which has the 2119 following syntax: 2121 HashValue ::= SEQUENCE { 2122 algorithm AlgorithmIdentifier DEFAULT { sha-1 }, 2123 value OCTET STRING } 2125 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 2126 oiw(14) secsig(3) algorithm(2) 26 } 2128 The algorithm identifier for SHA-1 is imported from [PKIX-ALG]. It 2129 is repeated here for convenience. 2131 4.6.2 fullRequest 2133 Like requestHash, the fullRequest alternative allows a client to 2134 determine that the request was not maliciously modified. It also 2135 provides a single data structure that is suitable for archive of the 2136 transaction. 2138 The fullRequest item uses the CVRequest type. The syntax and 2139 semantics of the CVRequest type are described in section 3. 2141 4.7 requestorRef 2143 The optional requestorRef item is used by the client to identify the 2144 original requestor in cases where SCVP relay is used. The value is 2145 only of local significance to the client. If the SCVP client 2146 includes a requestorRef value in the request, then the SCVP server 2147 MUST return the same value if the server is generating a non-cached 2148 response. 2150 4.8 requestorName 2152 The optional requestorName item is used by the server to return one 2153 or more identities associated with the client in the response. 2155 The SCVP server MAY choose to include any or all of the following: 2157 (1) the identity asserted by the client in the requestorName item 2158 of the request, 2159 (2) an authenticated identity for the client from a certificate or 2160 other credential used to authenticate the request, or 2161 (3) a client identifier from an out-of-band mechanism. 2163 Alternatively, the SCVP server MAY omit this item. 2165 In the case of non-cached responses to authenticated requests, the 2166 SCVP server SHOULD return a requestor name. 2168 SCVP servers that support authenticated requests SHOULD support this 2169 item. 2171 SCVP clients MUST be able to process responses that include this 2172 item, although the item value might not impact the processing in any 2173 manner. 2175 4.9 replyObjects 2177 The replyObjects item returns requested objects to the SCVP client, 2178 each of which tells the client about a single certificate from the 2179 request. The replyObjects item MUST be present in the response, 2180 unless the response is reporting an error. The CertReply item MUST 2181 contain cert, replyStatus, replyValTime, replyChecks, and 2182 replyWantBacks items; and the CertReply item MAY contain the 2183 validationErrors, nextUpdate, and certReplyExtensions items. 2185 A success response MUST contain one CertReply for each certificate 2186 specified in the queriedCerts item in the request. The order is 2187 important. The first CertReply in the sequence MUST correspond to 2188 the first certificate in the request; the second CertReply in the 2189 sequence MUST correspond to the second certificate in the request; 2190 and so on. 2192 The checks item in the request determines the content of the 2193 replyChecks item in the response. The wantBack item in the request 2194 determines the content of the replyWantBacks item in the response. 2195 The queryExtensions items in the request controls the absence or the 2196 presence and content of the certReplyExtensions item in the 2197 response. 2199 The replyObjects item uses the ReplyObjects type, which has the 2200 following syntax: 2202 ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply 2204 CertReply ::= SEQUENCE { 2205 cert CertReference, 2206 replyStatus ReplyStatus DEFAULT success, 2207 replyValTime GeneralizedTime, 2208 replyChecks ReplyChecks, 2209 replyWantBacks ReplyWantBacks, 2210 validationErrors [0] SEQUENCE SIZE (1..MAX) OF 2211 OBJECT IDENTIFIER OPTIONAL, 2212 nextUpdate [1] GeneralizedTime OPTIONAL, 2213 certReplyExtensions [2] Extensions OPTIONAL } 2215 4.9.1 cert 2217 The cert item contains either the certificate or a reference to the 2218 certificate about which the client is requesting information. If 2219 the certificate was specified by reference in the request, the 2220 request included either the id-swb-pkc-cert or id-swb-aa-cert 2221 wantBack, and the server was able to obtain the referenced 2222 certificate then this item MUST include the certificate. Otherwise, 2223 this item MUST include the same value as was used in the 2224 queriedCerts item in the request. 2226 CertReference has the following syntax: 2228 CertReference ::= CHOICE { 2229 pkc PKCReference, 2230 ac ACReference } 2232 4.9.2 replyStatus 2234 The replyStatus item gives status information to the client about 2235 the request for the specific certificate. Note that the 2236 responseStatus item is different than the replyStatus item. The 2237 responseStatus item is the status of the whole request, while the 2238 replyStatus item is the status for the individual query item. 2240 The replyStatus item uses the ReplyStatus type, which has the 2241 following syntax: 2243 ReplyStatus ::= ENUMERATED { 2244 success (0), 2245 malformedPKC (1), 2246 malformedAC (2), 2247 unavailableValidityTime (3), 2248 referenceCertHashFail (4), 2249 certPathConstructFail (5), 2250 certPathNotValid (6), 2251 certPathNotValidNow (7), 2252 wantBackUnsatisfied (8) } 2254 The meaning of the various ReplyStatus values are: 2256 0 Success: all checks were performed successfully. 2257 1 Failure: the public key certificate was malformed. 2258 2 Failure: the attribute certificate was malformed. 2259 3 Failure: historical data for the requested validity time is not 2260 available. 2262 4 Failure: the server could not locate the reference certificate or 2263 the referenced certificate did not match the hash value 2264 provided. 2265 5 Failure: no certification path could be constructed. 2266 6 Failure: the constructed certification path is not valid with 2267 respect to the validation policy. 2268 7 Failure: the constructed certification path is not valid with 2269 respect to the validation policy, but a query at a later time 2270 may be successful. 2271 8 Failure: all checks were performed successfully, however one or 2272 more of the wantBacks could not be satisfied. 2274 Codes 1 and 2 are used to tell the client that the request was 2275 properly formed, but the certificate in question was not. This is 2276 especially useful to clients that do not parse certificates. 2278 Code 7 is used to tell the client that a valid certification path 2279 was found with the exception that a certificate in the path is on 2280 hold, current revocation information is unavailable, or the 2281 validation time precedes the notBefore time in one or more 2282 certificates in the path. 2284 For codes 1, 2, 3, and 4, the replyChecks and replyWantBacks items 2285 are not populated (i.e., they MUST be an empty sequence). For codes 2286 5, 6, 7, and 8 replyChecks MUST include an entry corresponding to 2287 each check in the request; the replyWantBacks item is not populated. 2289 4.9.3 replyValTime 2291 The replyValTime item tells the time at which the information in the 2292 CertReply was correct. The replyValTime item represents the date 2293 and time in UTC, using GeneralizedTime type. The encoding rules for 2294 GeneralizedTime in section 3.2.7 MUST be used. 2296 Within the request, the optional validityTime item tells the date 2297 and time relative to which the SCVP client wants the server to 2298 perform the checks. If the validityTime is not present, the server 2299 MUST respond as if the client provided the date and time at which 2300 the server processes the request. 2302 The information in the CertReply item MUST be formatted as if the 2303 server created this portion of the response at the time indicated in 2304 the validityTime item of the query. However, if the server does not 2305 have appropriate historical information, the server MAY either 2306 return an error or return information for a later time. 2308 4.9.4 replyChecks 2309 The replyChecks item contains the responses to the checks item in 2310 the query. The replyChecks item includes the object identifier 2311 (OID) from the query and an integer. The value of the integer 2312 indicates whether the requested check was successful. The OIDs in 2313 the checks item of the query are used to identify the corresponding 2314 replyChecks values. Each OID specified in the checks item in the 2315 request MUST be matched by an OID in the replyChecks item of the 2316 response. In the case of an error response, the server MAY include 2317 additional checks in the response to further explain the error. 2318 Clients MUST ignore any unrecognized ReplyCheck included in the 2319 response. 2321 The replyChecks item uses the ReplyChecks type, which has the 2322 following syntax: 2324 ReplyChecks ::= SEQUENCE OF ReplyCheck 2326 ReplyCheck ::= SEQUENCE { 2327 check OBJECT IDENTIFIER, 2328 status INTEGER DEFAULT 0 } 2330 The status value for public key certification path building to a 2331 trusted root, { id-stc 1 }, can be one of the following: 2333 0: Built a path 2334 1: Could not build a path 2336 The status value for public key certification path building to a 2337 trusted root along with simple validation processing, { id-stc 2 }, 2338 can be one of the following: 2340 0: Valid 2341 1: Not valid 2343 The status value for public key certification path building to a 2344 trusted root along with complete status checking, { id-stc 3 }, can 2345 be one of the following: 2347 0: Valid 2348 1: Not valid 2349 2: Revocation Offline 2350 3: Revocation Unavailable 2351 4: No known source for revocation information 2353 Revocation offline means that the server or distribution point for 2354 the revocation information was connected to successfully without a 2355 network error but either no data was returned or if data was 2356 returned it was stale. Revocation unavailable means that a network 2357 error was returned when an attempt was made to reach the server or 2358 distribution point. No known source for revocation information 2359 means that the server was able to build a valid certification path 2360 but was unable to locate a source for revocation information for one 2361 or more certificates in the path. 2363 The status value for AC issuer certification path building to a 2364 trusted root, { id-stc 4 }, can be one of the following: 2366 0: Built a path 2367 1: Could not build a path 2369 The status value for AC issuer certification path building to a 2370 trusted root along with simple validation processing, { id-stc 5 }, 2371 can be one of the following: 2373 0: Valid 2374 1: Not valid 2376 The status value for AC issuer certification path building to a 2377 trusted root along with complete status checking, { id-stc 6 }, can 2378 be one of the following: 2380 0: Valid 2381 1: Not Valid 2382 2: Revocation Offline 2383 3: Revocation Unavailable 2384 4: No known source for revocation information 2386 The status value for revocation status checking of an AC as well as 2387 AC issuer certification path building to a trusted root along with 2388 complete status checking, { id-stc 7 }, can be one of the following: 2390 0: Valid 2391 1: Not Valid 2392 2: Revocation Offline 2393 3: Revocation Unavailable 2394 4: No known source for revocation information 2396 4.9.5 replyWantBacks 2398 The replyWantBacks item contains the responses to the wantBack item 2399 in the request. The replyWantBacks item includes the object 2400 identifier (OID) from the wantBack item in the request and an octet 2401 string. Within the octet string is the requested value. The OIDs 2402 in the wantBack item in the request are used to identify the 2403 corresponding reply value. The OIDs in the replyWantBacks item MUST 2404 match the OIDs in the wantBack item in the request. For a non-error 2405 response, replyWantBacks MUST include exactly one replyWantBack for 2406 each wantBack specified in the request (excluding id-swb-pkc-cert 2407 and id-swb-ac-cert, where the requested information is included in 2408 the cert item). 2410 The replyWantBacks item uses the ReplyWantBacks type, which has the 2411 following syntax: 2413 ReplyWantBacks ::= SEQUENCE OF ReplyWantBack 2415 ReplyWantBack::= SEQUENCE { 2416 wb OBJECT IDENTIFIER, 2417 value OCTET STRING } 2419 The octet string value for the certification path used to verify the 2420 certificate in the request, { id-swb 1 }, contains the CertBundle 2421 type. The syntax and semantics of the CertBundle type are described 2422 in section 3.2.8. This CertBundle includes all the certificates in 2423 the path, starting with the end certificate and ending with the 2424 certificate issued by the trust anchor. 2426 The octet string value for the proof of revocation status, { id-swb 2427 2 }, contains the RevInfoWantBack type. The RevInfoWantBack type is 2428 a SEQUENCE of the RevocationInfos type and an optional CertBundle. 2429 The syntax and semantics of the RevocationInfos type are described 2430 in section 3.2.9. The CertBundle MUST be included if any 2431 certificates required to validate the revocation information were 2432 not returned in the id-swb-pkc-best-cert-path or id-swb-pkc-all- 2433 cert-paths want back. The CertBundle MUST include all such 2434 certificates but there are no ordering requirements. 2436 RevInfoWantBack ::= SEQUENCE { 2437 revocationInfo RevocationInfos, 2438 extraCerts CertBundle OPTIONAL } 2440 The octet string value for the public key information, { id-swb 4 }, 2441 contains the SubjectPublicKeyInfo type. The syntax and semantics of 2442 the SubjectPublicKeyInfo type are described in [PKIX-1]. 2444 The octet string value for the AC issuer certification path used to 2445 verify the certificate in the request, { id-swb 5 }, contains the 2446 CertBundle type. The syntax and semantics of the CertBundle type 2447 are described in section 3.2.8. This CertBundle includes all the 2448 certificates in the path, beginning with the AC issuer certificate 2449 and ending with the certificate issued by the trust anchor. 2451 The octet string value for the proof of revocation status of the AC 2452 issuer certification path, { id-swb 6 }, contains the 2453 RevInfoWantBack type. The RevInfoWantBack type is a SEQUENCE of the 2454 RevocationInfos type and an optional CertBundle. The syntax and 2455 semantics of the RevocationInfos type are described in section 2456 3.2.9. The CertBundle MUST be included if any certificates required 2457 to validate the revocation information were not returned in the id- 2458 aa-cert-path want back. The CertBundle MUST include all such 2459 certificates but there are no ordering requirements. 2461 The octet string value for the proof of revocation status of the 2462 attribute certificate, { id-swb 7 }, contains the RevInfoWantBack 2463 type. The RevInfoWantBack type is a SEQUENCE of the RevocationInfos 2464 type and an optional CertBundle. The syntax and semantics of the 2465 RevocationInfos type are described in section 3.2.9. The CertBundle 2466 MUST be included if any certificates required to validate the 2467 revocation information were not returned in the id-swb-aa-cert-path 2468 want back. The CertBundle MUST include all such certificates but 2469 there are no ordering requirements. 2471 The octet string value for returning all paths, { id-swb 12 }, 2472 contains an ASN.1 type CertBundles, as defined below. The syntax 2473 and semantics of the CertBundle type are described in section 3.2.8. 2474 Each CertBundle includes all the certificates in one path, starting 2475 the end certificate and ending with the certificate issued by the 2476 trust anchor. 2478 CertBundles ::= SEQUENCE SIZE (1..MAX) OF CertBundle 2480 The octet string value for relayed responses, { id-swb 13 }, 2481 contains an ASN.1 type SCVPResponses, as defined below. If the SCVP 2482 server used information obtained from other SCVP servers when 2483 generating this response, then SCVPResponses MUST include each of 2484 the SCVP responses received from those servers. If the SCVP server 2485 did not use information obtained from other SCVP servers when 2486 generating the response, then SCVPResponses MUST be an empty 2487 sequence. 2489 SCVPResponses ::= SEQUENCE OF ContentInfo 2491 4.9.6 validationErrors 2493 The validationErrors item MUST only be present in failure responses. 2494 If present, it MUST contain one or more OIDs representing the reason 2495 the validation failed (validation errors for the basic validation 2496 algorithm and name validation algorithm are defined in sections 2497 3.2.4.2.2 and 3.2.4.2.4). The validationErrors item SHOULD only be 2498 included when the replyStatus is 3, 5, 6, 7, or 8. SCVP servers are 2499 not required to specify all of the reasons that validation failed. 2500 SCVP clients MUST NOT assume that the OIDs included in 2501 validationErrors represent all of the validation errors for the 2502 certification path. 2504 4.9.7 nextUpdate 2506 The nextUpdate item tells the time at which the server expects a 2507 refresh of information regarding the validity of the certificate to 2508 become available. The nextUpdate item is especially interesting if 2509 the certificate revocation status information is not available or 2510 the certificate is suspended. The nextUpdate item represents the 2511 date and time in UTC, using the GeneralizedTime type. The encoding 2512 rules for GeneralizedTime in section 3.2.7 MUST be used. 2514 4.9.8 certReplyExtensions 2516 The certReplyExtensions contains the responses to the 2517 queryExtensions item in the request. The certReplyExtensions item 2518 uses the Extensions type defined in [PKIX-1]. The object 2519 identifiers (OIDs) in the queryExtensions item in the request are 2520 used to identify the corresponding reply values. The 2521 certReplyExtensions item, when present, contains a sequence of 2522 Extension items, each of which contains an extnID item, a critical 2523 item, and an extnValue item. 2525 The extnID item is an identifier for the extension. It contains the 2526 OID that names the extension, and it MUST match one of the OIDs in 2527 the queryExtensions item in the request. 2529 The critical item is a BOOLEAN, and it MUST be set to FALSE. 2531 The extnValue item contains an OCTET STRING. Within the OCTET 2532 STRING is the extension value. An ASN.1 type is specified for each 2533 extension, identified by the associated extnID object identifier. 2535 4.10 respNonce 2537 The respNonce item contains an identifier to bind the request to the 2538 response. 2540 If the client includes a requestNonce value in the request and the 2541 server is generating a specific non-cached response to the request 2542 then the server MUST return the same value in the response. 2544 If the server is using a cached response to the request then it MUST 2545 omit the respNonce item. 2547 If the server is returning a specific non-cached response to a 2548 request without a nonce, then the server MAY include a message 2549 specific nonce. For digitally signed messages, the server MAY use 2550 the value of the message-digest attribute in the signedAttrs within 2551 SignerInfo of the request as the value in the respNonce item. 2553 The requestNonce item uses the octet string type. 2555 Conforming client implementations MUST be able to process a response 2556 that includes this item. Conforming servers MUST support respNonce. 2558 4.11 serverContextInfo 2560 The serverContextInfo item in a response is a mechanism for the 2561 server to pass some opaque context information to the client. If 2562 the client does not like the certification path returned, it can 2563 make a new query and pass along this context information. 2565 Section 3.2.6 contains information about the client's usage of this 2566 item. 2568 The context information is opaque to the client, but it provides 2569 information to the server that ensures that a different 2570 certification path will be returned (if another one can be found). 2571 The context information could indicate state of the server or it 2572 could contain a sequence of hashes of certification paths that have 2573 already been returned to the client. The protocol does not dictate 2574 any structure or requirements for this item. However, implementers 2575 should review the Security Considerations section of this document 2576 before selecting a structure. 2578 Servers that are incapable of returning additional paths MUST NOT 2579 include the serverContextInfo item in the response. 2581 4.12 cvResponseExtensions 2583 If present, the cvResponseExtensions item contains a sequence of 2584 Extensions that extend the response. This specification does not 2585 define any extensions. The facility is provided to allow future 2586 specifications to extend SCVP. The syntax for Extensions is 2587 imported from [PKIX-1]. The cvResponseExtensions item, when 2588 present, contains a sequence of Extension items, each of which 2589 contains an extnID item, a critical item, and an extnValue item. 2591 The extnID item is an identifier for the extension. It contains the 2592 object identifier (OID) that names the extension. 2594 The critical item is a BOOLEAN. Each extension is designated as 2595 either critical (with a value of TRUE) or non-critical (with a value 2596 of FALSE). An SCVP client MUST reject the response if it encounters 2597 a critical extension it does not recognize; however, a non-critical 2598 extension MAY be ignored if it is not recognized. 2600 The extnValue item contains an OCTET STRING. Within the OCTET 2601 STRING is the extension value. An ASN.1 type is specified for each 2602 extension, identified by the associated extnID object identifier. 2604 4.13 SCVP Response Validation 2606 There are two mechanisms for validation of SCVP responses, one based 2607 on the client's knowledge of a specific SCVP server key and the 2608 other based on validation of the certificate corresponding to the 2609 private key used to protect the SCVP response. 2611 4.13.1 Simple Key Validation 2613 The simple key validation method is where the SCVP client has a 2614 local policy of one or more SCVP server keys that directly identify 2615 the set of valid SCVP servers. Mechanisms for storage of server 2616 keys or identifiers are a local matter. For example, a client could 2617 store cryptographic hashes of public keys used to verify SignedData 2618 responses. Alternatively, a client could store shared symmetric 2619 keys used to verify MACs in AuthenticatedData responses. 2621 Simple key validation MUST be used by SCVP clients that cannot 2622 validate PKIX-1 certificates and are therefore making delegated path 2623 validation requests to the SCVP server [RQTMS]. It is a matter of 2624 local policy with these clients whether to use SignedData or 2625 AuthenticatedData. Simple key validation MAY be used by other SCVP 2626 clients for other reasons. 2628 4.13.2 SCVP Server Certificate Validation 2630 It is a matter of local policy what validation policy the client 2631 uses when validating responses. When validating protected SCVP 2632 responses, SCVP clients SHOULD use the validation algorithm defined 2633 in section 6 of [PKIX-1]. SCVP clients may impose additional 2634 limitations on the algorithm, such as limiting the number of 2635 certificates in the path or establishing initial name constraints, 2636 as specified in section 6.2 of [PKIX-1]. 2638 If the certificate used to sign the validation policy responses and 2639 SignedData validation responses contains the key usage extension 2640 [PKIX-1 section 4.2.1.3] it MUST have either the digital signature 2641 bit set, the non-repudiation bit set, or both bits set. 2643 If the certificate for AuthenticatedData validation responses 2644 contains the key usage extension it MUST have the key agreement bit 2645 set. 2647 If the certificate used on a validation policy response or a 2648 validation response contains the extended key usage extension [PKIX- 2649 1 section 4.2.1.13] it MUST contain the following OID: 2651 id-kp-scvpServer OBJECT IDENTIFIER ::= { id-kp 15 } 2653 5 Server Policy Request 2655 An SCVP client uses the ValPolRequest item to request information 2656 about an SCVP server's policies and configuration information, 2657 including the list of validation policies supported by the SCVP 2658 server. When a ValPolRequest is encapsulated in a MIME body part, 2659 it MUST be carried in an application/vp-request MIME body part. 2661 The request consists of a ValPolRequest encapsulated in a 2662 ContentInfo. The client does not sign the request. 2664 ContentInfo { 2665 contentType id-ct-scvp-valPolRequest, 2666 -- (1.2.840.113549.1.9.16.1.12) 2667 content ValPolRequest } 2669 The ValPolRequest type has the following syntax: 2671 ValPolRequest ::= SEQUENCE { 2672 vpRequestVersion INTEGER DEFAULT 1, 2673 requestNonce OCTET STRING } 2675 Conforming SCVP server implementations MUST recognize and process 2676 the server policy request. Conforming clients SHOULD support the 2677 server policy request. 2679 5.1 vpRequestVersion 2681 The syntax and semantics of vpRequestVersion are the same as 2682 cvRequestVersion as described in section 3.1. 2684 5.2 requestNonce 2686 The requestNonce item contains a request identifier generated by the 2687 SCVP client. If the server returns a specific response it MUST 2688 include the requestNonce from the request in the response, but the 2689 server MAY return a cached response which MUST NOT include a 2690 requestNonce. 2692 6 Validation Policy Response 2694 In response to a ValPolRequest, the SCVP server provides a 2695 ValPolResponse. The ValPolResponse MAY not be unique to any 2696 ValPolRequest, so may be reused by the server in response to 2697 multiple ValPolRequests. The ValPolResponse also has an indication 2698 of how frequently the ValPolResponse may be reissued. The server 2699 MUST sign the response using its digital signature certificate. 2700 When a ValPolResponse is encapsulated in a MIME body part, it MUST 2701 be carried in an application/vp-response MIME body part. 2703 The response consists of a ValPolResponse encapsulated in a 2704 SignedData, which is in turn encapsulated in a ContentInfo. That 2705 is, the EncapsulatedContentInfo field of SignedData consists of an 2706 eContentType field with a value of id-ct-scvp-valPolResponse 2707 (1.2.840.113549.1.9.16.1.13) and an eContent field that contains a 2708 DER encoded ValPolResponse. The SCVP server MUST include it's own 2709 certificate in the certificates field within SignedData and the 2710 signerInfos field of SignedData MUST include exactly one SignerInfo. 2711 The SignedData MUST NOT include the unsignedAttrs field. 2713 The ValPolResponse type has the following syntax: 2715 ValPolResponse ::= SEQUENCE { 2716 vpResponseVersion INTEGER, 2717 maxCVResponseVersion INTEGER, 2718 maxVPResponseVersion INTEGER, 2719 serverConfigurationID INTEGER, 2720 thisUpdate GeneralizedTime, 2721 nextUpdate GeneralizedTime OPTIONAL, 2722 validationPolicies SEQUENCE OF OBJECT IDENTIFIER, 2723 validationAlgs SEQUENCE OF OBJECT IDENTIFIER, 2724 authPolicies SEQUENCE OF AuthPolicy, 2725 responseTypes ResponseTypes, 2726 defaultPolicyValues RespValidationPolicy, 2727 revocationInfoTypes RevocationInfoTypes, 2728 signatureGeneration SEQUENCE OF AlgorithmIdentifier, 2729 signatureVerification SEQUENCE OF AlgorithmIdentifier, 2730 hashAlgorithms SEQUENCE SIZE (1..MAX) OF 2731 OBJECT IDENTIFIER, 2732 serverPublicKeys SEQUENCE OF KeyAgreePublicKey 2733 OPTIONAL, 2734 clockSkew INTEGER DEFAULT 10, 2735 requestNonce OCTET STRING OPTIONAL } 2737 ResponseTypes ::= ENUMERATED { 2738 cached-only (0), 2739 non-cached-only (1), 2740 cached-and-non-cached (2) } 2742 RevocationInfoTypes ::= BIT STRING { 2743 fullCRLs (0), 2744 deltaCRLs (1), 2745 indirectCRLs (2), 2746 oCSPResponses (3) } 2748 SCVP clients that support validation policy requests MUST support 2749 validation policy responses. SCVP servers MUST support validation 2750 policy responses. 2752 SCVP servers MUST support cached policy responses and MAY support 2753 specific responses to policy requests. 2755 6.1 vpResponseVersion 2757 The syntax and semantics of the vpResponseVersion item are the same 2758 as cvRequestVersion as described in section 3.1. The 2759 vpResponseVersion used MUST be the same as the vpRequestVersion 2760 unless the client has used a value greater than the values the 2761 server supports. If the client submits a vpRequestVersion greater 2762 than the version supported by the server, the server MUST return a 2763 vpResponseVersion using the highest version number the server 2764 supports as the version number. 2766 6.2 maxCVRequestVersion 2768 The maxCVRequestVersion defines the maximum version number for CV 2769 requests that the server supports. 2771 6.3 maxVPRequestVersion 2773 The maxVPRequestVersion defines the maximum version number for VP 2774 requests that the server supports. 2776 6.4 serverConfigurationID 2778 An integer that uniquely represents the version of the server 2779 configuration as represented by the validationPolicies, 2780 validationAlgs, authPolicies, defaultPolicyValues, and clockSkew. 2781 If any of these values change, the server MUST create a new 2782 ValPolResponse with a new serverConfigurationID. If the 2783 configuration has not changed, then the server may reuse 2784 serverConfigurationID across multiple ValPolResponse messages. 2785 However if the server reverts to an earlier configuration, the 2786 server MUST NOT revert the configuration ID as well, but MUST select 2787 another unique value. 2789 6.5 thisUpdate 2791 This item indicates the signing date and time of this policy 2792 response. 2794 GeneralizedTime values MUST be expressed Greenwich Mean Time (Zulu) 2795 and interpreted as defined in section 3.2.7. 2797 6.6 nextUpdate and requestNonce 2799 These items are used to indicate whether policy responses are 2800 specific to policy requests. Where policy responses are cached, 2801 these items indicate when the information will be updated. The 2802 optional nextUpdate item indicates the time by which the next policy 2803 response will be published. The optional requestNonce item links 2804 the response to a specific request by returning the nonce provided 2805 in the request. 2807 If the nextUpdate item is omitted it indicates a non-cached response 2808 generated in response to a specific request (i.e. the ValPolResponse 2809 is bound to a specific request). If this item is omitted the 2810 requestNonce item MUST be present and MUST include the requestNonce 2811 value from the request. 2813 If the nextUpdate item is present it indicates a cached response 2814 that is not bound to a specific request. An SCVP server MUST 2815 periodically generate a new response as defined by the next update 2816 time, but MAY use the same ValPolResponse to respond to multiple 2817 requests. The requestNonce is omitted if the nextUpdate item is 2818 present. 2820 It is a matter of local server policy to return a cached or non- 2821 cached specific response. 2823 GeneralizedTime values in nextUpdate MUST be expressed Greenwich 2824 Mean Time (Zulu) as specified in section 3.2.7. 2826 6.7 validationPolicies 2828 The validationPolicies item contains a sequence of object 2829 identifiers representing the validation policies supported by the 2830 server. It is a matter of local policy if the server wishes to 2831 process requests using the default validation policy, and if it does 2832 not, then it MUST NOT include the id-svp-defaultValPolicy in this 2833 list. 2835 6.8 validationAlgs 2837 The validationAlgs item contains a sequence of OIDs. Each OID 2838 identifies a validation algorithm supported by the server. 2840 6.9 authPolicies 2841 The authPolicies item contains a sequence of policy references for 2842 authenticating to the SCVP server. 2844 The reference to the authentication policy is an OID that the client 2845 and server have agreed represents an authentication policy. The 2846 list of policies is intended to document to the client if 2847 authentication is required for some requests and if so how. 2849 AuthPolicy ::= OBJECT IDENTIFIER 2851 6.10 responseTypes 2853 responseTypes allows the server to publish the range of response 2854 types it supports. Cached only means the server will only return 2855 cached responses to requests. Non-cached only means the server will 2856 return a specific response to the request i.e. containing the 2857 requestor's nonce. Both means the server will return either, 2858 depending on the request. 2860 6.11 revocationInfoTypes 2862 revocationInfoTypes allows the server to indicate the sources of 2863 revocation information that it is capable of processing. For each 2864 bit in the RevocationInfoTypes bit string, the server MUST set the 2865 bit to one if it is capable of processing the corresponding 2866 revocation information type and to zero if it can not. 2868 6.12 defaultPolicyValues 2870 This is the default validation policy used by the server. It 2871 contains a RespValidationPolicy, which is defined in section 4.5. 2872 All OPTIONAL items in the validationPolicy item MUST be populated. 2873 A server will use these default values when the request references 2874 the default validation policy and the client does not override the 2875 default values by supplying other values in the request. 2877 This allows the client to optimize the request by omitting 2878 parameters that match the server default values. 2880 6.13 signatureGeneration 2882 This sequence specifies the set of digital signature algorithms 2883 supported by an SCVP server for signing CVResponse messages. Each 2884 digital signature algorithm is specified as an AlgorithmIdentifier, 2885 using the encoding rules associated with the signatureAlgorithm 2886 field in a public key certificate [PKIX-1]. Supported algorithms 2887 are defined in [PKIX-ALG] and [PKIX-ALG2], but other signature 2888 algorithms may also be supported. 2890 By including an algorithm (e.g., RSA with SHA-1) in this list, the 2891 server states that it has a private key and corresponding certified 2892 public key for that asymmetric algorithm, and supports the specified 2893 hash algorithm. The list is ordered; the first digital signature 2894 algorithm is the server's default algorithm. The default algorithm 2895 will be used by the server to protect signed messages unless the 2896 client specifies another algorithm. 2898 For servers that do not have an online private key, and cannot sign 2899 CVResponse messages, the signatureGeneration item is encoded as an 2900 empty sequence. 2902 6.14 signatureVerification 2904 This sequence specifies the set of digital signature algorithms that 2905 can be verified by this SCVP server. Each digital signature 2906 algorithm is specified as an AlgorithmIdentifier, using the encoding 2907 rules associated with the signatureAlgorithm field in a public key 2908 certificate [PKIX-1]. Supported algorithms are defined in [PKIX- 2909 ALG] and [PKIX-ALG2], but other signature algorithms may also be 2910 supported. 2912 For servers that do not verify signatures on CVRequest messages, the 2913 signatureVerification item is encoded as an empty sequence. 2915 6.15 hashAlgorithms 2917 This sequence specifies the set of hash algorithms that the server 2918 can use to hash certificates and requests. The list is ordered; the 2919 first hash algorithm is the server's default algorithm. The default 2920 algorithm will be used by the server to compute hashes included in 2921 responses unless the client specifies another algorithm. Each hash 2922 algorithm is specified as an object identifier. [PKIX-ALG2] 2923 specifies object identifiers for SHA-1, SHA-224, SHA-256, SHA-384, 2924 and SHA-512. Other hash algorithms may also be supported. 2926 6.16 serverPublicKeys 2928 The serverPublicKeys item is a sequence of one or more key agreement 2929 public keys and associated parameters. It is used by clients making 2930 AuthenticatedData requests to the server. Each item in the 2931 serverPublicKeys sequence is of the KeyAgreePublicKey type: 2933 KeyAgreePublicKey ::= SEQUENCE { 2934 algorithm AlgorithmIdentifier, 2935 publicKey BIT STRING, 2936 macAlgorithm AlgorithmIdentifier, 2937 kDF AlgorithmIdentifier OPTIONAL } 2939 The KeyAgreePublicKey includes the algorithm identifier and the 2940 server's public key. SCVP servers that support the key agreement 2941 mode of AuthenticatedData for SCVP requests MUST support 2942 serverPublicKeys and the Diffie-Hellman key agreement algorithm as 2943 specified in [PKIX-ALG]. SCVP servers that support serverPublicKeys 2944 MUST support the 1024-bit MODP group key (group 2) as defined in 2945 [IKE]. SCVP servers that support serverPublicKeys MAY support other 2946 Diffie-Hellman groups [IKE-GROUPS], as well as other key agreement 2947 algorithms. 2949 The macAlgorithm item specifies the symmetric algorithm the server 2950 expects the client to use with the result of the key agreement 2951 algorithm. A key derivation function (KDF), which derives symmetric 2952 key material from the key agreement result, may be implied by the 2953 macAlgorithm. Alternatively, the KDF may be explicitly specified 2954 using the optional kDF item. 2956 6.17 clockSkew 2958 The clockSkew item is the number of minutes the server will allow 2959 for clock skew. The default value of 10 minutes. 2961 7 SCVP Server Relay 2963 In some network environments, especially ones that include 2964 firewalls, an SCVP server might not be able to obtain all of the 2965 information that it needs to process a request. However, the server 2966 might be configured to use the services of one or more other SCVP 2967 servers to fulfill all requests. In such cases, the SCVP client is 2968 unaware that the initial SCVP server is using the services of other 2969 SCVP servers. The initial SCVP server acts as a client to another 2970 SCVP server. Unlike the original client, the SCVP server is 2971 expected to have moderate computing and memory resources. This 2972 section describes SCVP server-to-SCVP server exchanges. This 2973 section does not impose any requirements on SCVP clients that are 2974 not also SCVP servers. Further, this section does not impose any 2975 requirements on SCVP servers that do not relay requests to other 2976 SCVP servers. 2978 When one SCVP server relays a request to another server, in an 2979 incorrectly configured system of servers, it is possible that the 2980 same request will be relayed back again. Any SCVP server that 2981 relays requests MUST implement the conventions described in this 2982 section to detect and break loops. 2984 When an SCVP server relays a request, the request MUST include the 2985 requestorRef item. If the request to be relayed already contains a 2986 requestorRef item, then the server-generated request MUST contain a 2987 requestorRef item constructed from this value followed by a 2988 GeneralName that contains an identifier of the SCVP server. If the 2989 request to be relayed does not contain a requestorRef item, then the 2990 server-generated request MUST contain a requestorRef item that 2991 includes a GeneralName that contains an identifier of the SCVP 2992 server. 2994 To prevent false loop detection, servers should use identifiers that 2995 are unique within their network of cooperating SCVP servers. SCVP 2996 servers that support relay SHOULD populate this item with the DNS 2997 name of the server or the distinguished name in the server's 2998 certificate. SCVP servers MAY choose other procedures for 2999 generating identifiers that are unique within their community. 3001 When an SVCP server receives a request that contains a requestorRef 3002 item, the server MUST check the sequence of names in the 3003 requestorRef item for its own identifier. If the server discovers 3004 its own identifier in the requestor item, it MUST respond with an 3005 error, setting the cvResponseStatus to 40. 3007 When an SCVP server generates a non-cached response to a relayed 3008 request, the server MUST include the requestorRef item from the 3009 request in the response. 3011 8 SCVP ASN.1 Module 3013 This section defines the syntax for SCVP request-response pairs. 3014 The semantics for the messages are defined in sections 3, 4, 5, and 3015 6. The SCVP ASN.1 module follows. 3017 SCVP 3019 { iso(1) identified-organization(3) dod(6) internet(1) 3020 security(5) mechanisms(5) pkix(7) id-mod(0) 21 } 3022 DEFINITIONS IMPLICIT TAGS ::= BEGIN 3024 IMPORTS 3026 AlgorithmIdentifier, Attribute, Certificate, Extensions, 3027 -- Import UTF8String if required by compiler 3028 -- UTF8String, -- CertificateList, CertificateSerialNumber 3029 FROM PKIX1Explicit88 -- RFC 3280 3030 { iso(1) identified-organization(3) dod(6) internet(1) 3031 security(5) mechanisms(5) pkix(7) id-mod(0) 18 } 3033 GeneralNames, GeneralName, KeyUsage, KeyPurposeId 3034 FROM PKIX1Implicit88 -- RFC 3280 3035 { iso(1) identified-organization(3) dod(6) internet(1) 3036 security(5) mechanisms(5) pkix(7) id-mod(0) 19 } 3038 AttributeCertificate 3039 FROM PKIXAttributeCertificate -- RFC 3281 3040 { iso(1) identified-organization(3) dod(6) internet(1) 3041 security(5) mechanisms(5) pkix(7) id-mod(0) 12 } 3043 OCSPResponse 3044 FROM OCSP -- RFC 2560 3045 { iso(1) identified-organization(3) dod(6) internet(1) 3046 security(5) mechanisms(5) pkix(7) id-mod(0) 14 } 3048 ContentInfo 3049 FROM CryptographicMessageSyntax -- RFC 3369 3050 { iso(1) member-body(2) us(840) rsadsi(113549) 3051 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) } ; 3053 -- SCVP Certificate Validation Request 3055 id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3056 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3057 id-smime(16) 1 } 3059 id-ct-scvp-certValRequest OBJECT IDENTIFIER ::= { id-ct 10 } 3061 CVRequest ::= SEQUENCE { 3062 cvRequestVersion INTEGER DEFAULT 1, 3063 query Query, 3064 requestorRef [0] GeneralNames OPTIONAL, 3065 requestNonce [1] OCTET STRING OPTIONAL, 3066 requestorName [2] GeneralName OPTIONAL, 3067 responderName [3] GeneralName OPTIONAL, 3068 reqestExtensions [4] Extensions OPTIONAL, 3069 signatureAlg [5] AlgorithmIdentifier OPTIONAL, 3070 hashAlg [6] OBJECT IDENTIFIER OPTIONAL } 3072 Query ::= SEQUENCE { 3073 queriedCerts CertReferences, 3074 checks CertChecks, 3075 wantBack [1] WantBack OPTIONAL, 3076 validationPolicy ValidationPolicy, 3077 responseFlags ResponseFlags OPTIONAL, 3078 serverContextInfo [2] OCTET STRING OPTIONAL, 3079 validationTime [3] GeneralizedTime OPTIONAL, 3080 intermediateCerts [4] CertBundle OPTIONAL, 3081 revInfos [5] RevocationInfos OPTIONAL, 3082 producedAt [6] GeneralizedTime OPTIONAL, 3083 queryExtensions [7] Extensions OPTIONAL } 3085 CertReferences ::= CHOICE { 3086 pkcRefs [0] SEQUENCE SIZE (1..MAX) OF PKCReference, 3087 acRefs [1] SEQUENCE SIZE (1..MAX) OF ACReference } 3089 CertReference::= CHOICE { 3090 pkc PKCReference, 3091 ac ACReference } 3093 PKCReference ::= CHOICE { 3094 cert [0] Certificate, 3095 pkcRef [1] CertID } 3097 ACReference ::= CHOICE { 3098 attrCert [2] AttributeCertificate, 3099 acRef [3] CertID } 3101 CertID ::= SEQUENCE { 3102 certHash OCTET STRING, 3103 issuerSerial IssuerSerial, 3104 hashAlgorithm AlgorithmIdentifier DEFAULT { sha-1 } } 3106 IssuerSerial ::= SEQUENCE { 3107 issuer GeneralNames, 3108 serialNumber CertificateSerialNumber 3109 } 3111 ValidationPolicy ::= SEQUENCE { 3112 validationPolRef ValidationPolRef, 3113 validationAlg [0] ValidationAlg OPTIONAL, 3114 userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT 3115 IDENTIFIER OPTIONAL, 3116 inhibitPolicyMapping [2] BOOLEAN OPTIONAL, 3117 requireExplicitPolicy [3] BOOLEAN OPTIONAL, 3118 inhibitAnyPolicy [4] BOOLEAN OPTIONAL, 3119 trustAnchors [5] TrustAnchors OPTIONAL, 3120 keyUsages [6] SEQUENCE OF KeyUsage OPTIONAL, 3121 extendedKeyUsages [7] SEQUENCE OF KeyPurposeId OPTIONAL } 3123 CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 3125 WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 3127 ValidationPolRef ::= SEQUENCE { 3128 valPolId OBJECT IDENTIFIER, 3129 valPolParams ANY DEFINED BY valPolId OPTIONAL } 3131 ValidationAlg ::= SEQUENCE { 3132 valAlgId OBJECT IDENTIFIER, 3133 parameters ANY DEFINED BY valAlgId OPTIONAL } 3135 NameValidationAlgParms ::= SEQUENCE { 3136 nameCompAlgId OBJECT IDENTIFIER, 3137 validationNames GeneralNames } 3139 TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF PKCReference 3141 KeyAgreePublicKey ::= SEQUENCE { 3142 algorithm AlgorithmIdentifier, 3143 publicKey BIT STRING, 3144 macAlgorithm AlgorithmIdentifier, 3145 kDF AlgorithmIdentifier OPTIONAL } 3147 ResponseFlags ::= SEQUENCE { 3148 fullRequestInResponse [0] BOOLEAN DEFAULT FALSE, 3149 responseValidationPolByRef [1] BOOLEAN DEFAULT TRUE, 3150 protectResponse [2] BOOLEAN DEFAULT TRUE, 3151 cachedResponse [3] BOOLEAN DEFAULT TRUE } 3153 CertBundle ::= SEQUENCE SIZE (1..MAX) OF Certificate 3155 RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo 3157 RevocationInfo ::= CHOICE { 3158 crl [0] CertificateList, 3159 delta-crl [1] CertificateList, 3160 ocsp [2] OCSPResponse, 3161 other [3] OtherRevInfo } 3163 OtherRevInfo ::= SEQUENCE { 3164 riType OBJECT IDENTIFIER, 3165 riValue ANY DEFINED BY riType } 3167 -- SCVP Certificate Validation Response 3169 id-ct-scvp-certValResponse OBJECT IDENTIFIER ::= { id-ct 11 } 3171 CVResponse ::= SEQUENCE { 3172 cvResponseVersion INTEGER, 3173 serverConfigurationID INTEGER, 3174 producedAt GeneralizedTime, 3175 responseStatus ResponseStatus, 3176 respValidationPolicy [0] RespValidationPolicy OPTIONAL, 3177 requestRef [1] RequestReference OPTIONAL, 3178 requestorRef [2] GeneralNames OPTIONAL, 3179 requestorName [3] GeneralNames OPTIONAL, 3180 replyObjects [4] ReplyObjects OPTIONAL, 3181 respNonce [5] OCTET STRING OPTIONAL, 3182 serverContextInfo [6] OCTET STRING OPTIONAL, 3183 cvResponseExtensions [7] Extensions OPTIONAL } 3185 ResponseStatus ::= SEQUENCE { 3186 statusCode CVStatusCode DEFAULT okay, 3187 errorMessage UTF8String OPTIONAL } 3189 CVStatusCode ::= ENUMERATED { 3190 okay (0), 3191 skipUnrecognizedItems (1), 3192 tooBusy (10), 3193 invalidRequest (11), 3194 internalError (12), 3195 badStructure (20), 3196 unsupportedVersion (21), 3197 abortUnrecognizedItems (22), 3198 unrecognizedSigKey (23), 3199 badSignatureOrMAC (24), 3200 unableToDecode (25), 3201 notAuthorized (26), 3202 unsupportedChecks (27), 3203 unsupportedWantBacks (28), 3204 unsupportedSignatureOrMAC (29), 3205 invalidSignatureOrMAC (30), 3206 protectedResponseUnsupported (31), 3207 unrecognizedResponderName (32), 3208 relayingLoop (40), 3209 unrecognizedValPol (50), 3210 unrecognizedValAlg (51), 3211 fullRequestInResponseUnsupported (52), 3212 fullPolResponseUnsupported (53), 3213 inhibitPolicyMappingUnsuported (54), 3214 requireExplicitPolicyUnsupported (55), 3215 inhibitAnyPolicyUnsupported (56), 3216 validityTimeUnsupported (57), 3217 unrecognizedCritQueryExt (63), 3218 unrecognizedCritRequestExt (64) } 3220 RespValidationPolicy ::= ValidationPolicy 3222 RequestReference ::= CHOICE { 3223 requestHash [0] HashValue, -- hash of CVRequest 3224 fullRequest [1] CVRequest } 3226 HashValue ::= SEQUENCE { 3227 algorithm AlgorithmIdentifier DEFAULT { sha-1 }, 3228 value OCTET STRING } 3230 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3231 oiw(14) secsig(3) algorithm(2) 26 } 3233 ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply 3235 CertReply ::= SEQUENCE { 3236 cert CertReference, 3237 replyStatus ReplyStatus DEFAULT success, 3238 replyValTime GeneralizedTime, 3239 replyChecks ReplyChecks, 3240 replyWantBacks ReplyWantBacks, 3241 validationErrors [0] SEQUENCE SIZE (1..MAX) OF 3242 OBJECT IDENTIFIER OPTIONAL, 3243 nextUpdate [1] GeneralizedTime OPTIONAL, 3244 certReplyExtensions [2] Extensions OPTIONAL } 3246 ReplyStatus ::= ENUMERATED { 3247 success (0), 3248 malformedPKC (1), 3249 malformedAC (2), 3250 unavailableValidityTime (3), 3251 referenceCertHashFail (4), 3252 certPathConstructFail (5), 3253 certPathNotValid (6), 3254 certPathNotValidNow (7), 3255 wantBackUnsatisfied (8) } 3257 ReplyChecks ::= SEQUENCE OF ReplyCheck 3259 ReplyCheck ::= SEQUENCE { 3260 check OBJECT IDENTIFIER, 3261 status INTEGER DEFAULT 0 } 3263 ReplyWantBacks ::= SEQUENCE OF ReplyWantBack 3265 ReplyWantBack::= SEQUENCE { 3266 wb OBJECT IDENTIFIER, 3267 value OCTET STRING } 3269 CertBundles ::= SEQUENCE SIZE (1..MAX) OF CertBundle 3271 RevInfoWantBack ::= SEQUENCE { 3272 revocationInfo RevocationInfos, 3273 extraCerts CertBundle OPTIONAL } 3275 SCVPResponses ::= SEQUENCE OF ContentInfo 3277 -- SCVP Validation Policies Request 3278 id-ct-scvp-valPolRequest OBJECT IDENTIFIER ::= { id-ct 12 } 3280 ValPolRequest ::= SEQUENCE { 3281 vpRequestVersion INTEGER DEFAULT 1, 3282 requestNonce OCTET STRING } 3284 -- SCVP Validation Policies Response 3286 id-ct-scvp-valPolResponse OBJECT IDENTIFIER ::= { id-ct 13 } 3288 ValPolResponse ::= SEQUENCE { 3289 vpResponseVersion INTEGER, 3290 maxCVResponseVersion INTEGER, 3291 maxVPResponseVersion INTEGER, 3292 serverConfigurationID INTEGER, 3293 thisUpdate GeneralizedTime, 3294 nextUpdate GeneralizedTime OPTIONAL, 3295 validationPolices SEQUENCE OF OBJECT IDENTIFIER, 3296 validationAlgs SEQUENCE OF OBJECT IDENTIFIER, 3297 authPolicies SEQUENCE OF AuthPolicy, 3298 responseTypes ResponseTypes, 3299 defaultPolicyValues RespValidationPolicy, 3300 revocationInfoTypes RevocationInfoTypes, 3301 signatureGeneration SEQUENCE OF AlgorithmIdentifier, 3302 signatureVerification SEQUENCE OF AlgorithmIdentifier, 3303 hashAlgorithms SEQUENCE SIZE (1..MAX) OF 3304 OBJECT IDENTIFIER, 3305 serverPublicKeys SEQUENCE OF KeyAgreePublicKey 3306 OPTIONAL, 3307 clockSkew INTEGER DEFAULT 10, 3308 requestNonce OCTET STRING OPTIONAL } 3310 ResponseTypes ::= ENUMERATED { 3311 cached-only (0), 3312 non-cached-only (1), 3313 cached-and-non-cached (2) } 3315 RevocationInfoTypes ::= BIT STRING { 3316 fullCRLs (0), 3317 deltaCRLs (1), 3318 indirectCRLs (2), 3319 oCSPResponses (3) } 3321 AuthPolicy ::= OBJECT IDENTIFIER 3323 -- SCVP Check Identifiers 3325 id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3326 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 } 3328 id-stc-build-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 } 3329 id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 2 } 3330 id-stc-build-status-checked-pkc-path 3331 OBJECT IDENTIFIER ::= { id-stc 3 } 3332 id-stc-build-aa-path OBJECT IDENTIFIER ::= { id-stc 4 } 3333 id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 5 } 3334 id-stc-build-status-checked-aa-path 3335 OBJECT IDENTIFIER ::= { id-stc 6 } 3336 id-stc-status-check-ac-and-build-status-checked-aa-path 3337 OBJECT IDENTIFIER ::= { id-stc 7 } 3339 -- SCVP WantBack Identifiers 3341 id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3342 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 } 3344 id-swb-pkc-best-cert-path OBJECT IDENTIFIER ::= { id-swb 1 } 3345 id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 } 3346 id-swb-pkc-public-key-info OBJECT IDENTIFIER ::= { id-swb 4 } 3347 id-swb-aa-cert-path OBJECT IDENTIFIER ::= { id-swb 5 } 3348 id-swb-aa-revocation-info OBJECT IDENTIFIER ::= { id-swb 6 } 3349 id-swb-ac-revocation-info OBJECT IDENTIFIER ::= { id-swb 7 } 3350 id-swb-relayed-responses OBJECT IDENTIFIER ::= { id-swb 9 } 3351 id-swb-pkc-cert OBJECT IDENTIFIER ::= { id-swb 10} 3352 id-swb-ac-cert OBJECT IDENTIFIER ::= { id-swb 11} 3353 id-swb-pkc-all-cert-paths OBJECT IDENTIFIER ::= { id-swb 12} 3355 -- SCVP Validation Policy and Algorithm Identifiers 3357 id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3358 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 } 3360 id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 } 3362 -- SCVP Basic Validation Algorithm Identifier 3364 id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 } 3366 -- SCVP Basic Validation Algorithm Errors 3368 id-bvae OBJECT IDENTIFIER ::= id-svp-basicValAlg 3370 id-bvae-expired OBJECT IDENTIFIER ::= { id-bvae 1 } 3371 id-bvae-not-yet-valid OBJECT IDENTIFIER ::= { id-bvae 2 } 3372 id-bvae-wrongTrustAnchor OBJECT IDENTIFIER ::= { id-bvae 3 } 3373 id-bvae-noValidCertPath OBJECT IDENTIFIER ::= { id-bvae 4 } 3374 id-bvae-revoked OBJECT IDENTIFIER ::= { id-bvae 5 } 3375 id-bvae-invalidKeyPurpose OBJECT IDENTIFIER ::= { id-bvae 9 } 3376 id-bvae-invalidKeyUsage OBJECT IDENTIFIER ::= { id-bvae 10 } 3377 id-bvae-invalidCertPolicy OBJECT IDENTIFIER ::= { id-bvae 11 } 3379 -- SCVP Name Validation Algorithm Identifier 3381 id-svp-nameValAlg OBJECT IDENTIFIER ::= { id-svp 2 } 3383 -- SCVP Name Validation Algorithm DN comparison algorithm 3385 id-nva-dnCompAlg OBJECT IDENTIFIER ::= { id-svp 4 } 3387 -- SCVP Name Validation Algorithm Errors 3389 id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg 3391 id-nvae-name-mismatch OBJECT IDENTIFIER ::= { id-nvae 1 } 3392 id-nvae-no-name OBJECT IDENTIFIER ::= { id-nvae 2 } 3393 id-nvae-unknown-alg OBJECT IDENTIFIER ::= { id-nvae 3 } 3394 id-nvae-bad-name OBJECT IDENTIFIER ::= { id-nvae 4 } 3395 id-nvae-bad-name-type OBJECT IDENTIFIER ::= { id-nvae 5 } 3396 id-nvae-mixed-names OBJECT IDENTIFIER ::= { id-nvae 6 } 3398 -- SCVP Extended Key Usage Key Purpose Identifiers 3400 id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3401 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } 3403 id-kp-scvpServer OBJECT IDENTIFIER ::= { id-kp 15 } 3405 id-kp-scvpClient OBJECT IDENTIFIER ::= { id-kp 16 } 3407 END 3409 9 Security Considerations 3411 For security considerations specific to the Cryptographic Message 3412 Syntax message formats, see [CMS]. For security considerations 3413 specific to the process of PKI certificate path validation, see 3414 [PKIX-1]. 3416 A client that trusts a server's response for validation of a 3417 certificate inherently trusts that server as much as it would trust 3418 its own validation software. This means that if an attacker 3419 compromises a trusted SCVP server, the attacker can change the 3420 validation processing for every client that relies on that server. 3421 Thus, an SCVP server must be protected at least as well as the trust 3422 anchors that the SCVP server trusts. 3424 Clients MUST verify that the response matches their original 3425 request. Clients need to ensure that the server has performed the 3426 appropriate checks for the correct certificates under the requested 3427 validation policy for the specified validation time, and that the 3428 response includes the requested want backs and meets the client's 3429 freshness requirements. 3431 When the SCVP response is used to determine the validity of a 3432 certificate, the client MUST validate the digital signature or MAC 3433 on the response to ensure that the expected SCVP server generated 3434 it. If the client does not check the digital signature or MAC on 3435 the response, a man-in-the-middle attack could fool the client into 3436 believing modified responses from the server, or responses to 3437 questions the client did not ask. 3439 If the client does not include a requestNonce item, or if the client 3440 does not check that the requestNonce in the response matches the 3441 value in the request, an attacker can replay previous responses from 3442 the SCVP server. 3444 If the server does not require some sort of authorization (such as 3445 signed requests), an attacker can get the server to respond to 3446 arbitrary requests. Such responses may give the attacker 3447 information about weaknesses in the server or about the timeliness 3448 of the server's checking. This information may be valuable for a 3449 future attack. 3451 If the server uses the serverContextInfo item to indicate some 3452 server state associated with a requestor, implementers must take 3453 appropriate measures against denial of service attacks where an 3454 attacker sends in a lot of requests at one time to force the server 3455 to keep a lot of state information. 3457 SCVP does not include any confidentiality mechanisms. If 3458 confidentiality is needed, it can be achieved with a lower-layer 3459 security protocol. 3461 If an SCVP client is not operating on a network with good physical 3462 protection, it must ensure that there is integrity over the SCVP 3463 request-response pair. The client can ensure integrity by using a 3464 protected transport such as TLS. It can ensure integrity by using 3465 MACs or digital signatures to individually protect the request and 3466 response messages. 3468 If an SCVP client populates the userPolicySet in a request with a 3469 value other than anyPolicy, but does not set the 3470 requireExplicitPolicy flag, the server may return an affirmative 3471 answer for paths that do not satisfy any of the specified policies. 3472 In general, when a client populates the userPolicySet in a request 3473 with a value other than anyPolicy, the requireExplicitPolicy flag 3474 should also be set. This guarantees that all valid paths satisfy at 3475 least one of the requested policies. 3477 In SCVP, historical validation of a certificate returns the known 3478 status of the certificate at the time specified in validationTime. 3479 This may be used to demonstrate due diligence, but does not 3480 necessarily provide the most complete information. A certificate 3481 may have been revoked after the time specified in validationTime, 3482 but the revocation notice may specify an invalidity date that 3483 precedes the validationTime. The SCVP server would provide an 3484 affirmative response even though the most current information 3485 available indicates the certificate should not be trusted at that 3486 time. SCVP clients may wish to specify a validationTime later than 3487 the actual time of interest to mitigate this risk. 3489 10 References 3491 Normative and informative references are provided. 3493 10.1 Normative References 3495 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 3496 Requirement Levels", BCP 14, RFC 2119, March 1997. 3497 http://www.ietf.org/rfc/rfc2119.txt 3499 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 3369,August 3500 2002. 3501 http://www.ietf.org/rfc/rfc3369.txt 3503 [OCSP] Myers, M., R. Ankney, A. Malpani, S. Galperin and C. 3504 Adams, "X.509 Internet Public Key Infrastructure - Online 3505 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 3506 http://www.ietf.org/rfc/rfc2560.txt 3508 [PKIX-1] Housley, R., T. Polk, W. Ford and D. Solo, "Internet 3509 X.509 Public Key Infrastructure Certificate and 3510 Certificate Revocation List (CRL) Profile", RFC 3280, 3511 April 2002. 3512 http://www.ietf.org/rfc/rfc3280.txt 3514 [PKIX-AC] Farrell, S. and R. Housley, "An Internet Attribute 3515 Certificate Profile for Authorization", RFC 3281, April 3516 2002. 3517 http://www.ietf.org/rfc/rfc3281.txt 3519 [PKIX-ALG] Polk, W., R. Housley and L. Bassham, "Algorithms and 3520 Identifiers for the Internet X.509 Public Key 3521 Infrastructure Certificate and Certificate Revocation 3522 List (CRL) Profile", RFC 3279, April 2002. 3523 http://www.ietf.org/rfc/rfc3279.txt 3525 [PKIX-ALG2] Schaad, J., B. Kaliski and R. Housley, "Additional 3526 Algorithms and Identifiers for RSA Cryptography for use 3527 in the Internet X.509 Public Key Infrastructure 3528 Certificate and Certificate Revocation List (CRL) 3529 Profile", RFC 4055, June 2005. 3530 http://www.ietf.org/rfc/rfc4055.txt 3532 [SHA] National Institute of Standards and Technology, "Secure 3533 Hash Standard", NIST FIPS Pub 180-2, August 2002. 3535 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 3536 10646", RFC 2279, January 1998. 3537 http://www.ietf.org/rfc/rfc2279.txt 3539 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 3540 2634, June 1999. 3541 http://www.ietf.org/rfc/rfc2634.txt 3543 [HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC2818, May 2000. 3544 http://www.ietf.org/rfc/rfc2818.txt 3546 [SMIME-CERT] B. Ramsdell, Ed. "Secure/Multipurpose Internet Mail 3547 Extensions (S/MIME) Version 3.1 Certificate Handling" 3548 RFC3850, July 2004. 3549 http://www.ietf.org/rfc/rfc3850.txt 3551 [IKE] Harkins, D. and D. Carrel. "The Internet Key Exchange 3552 (IKE)", RFC2409, November 1998. 3553 http://www.ietf.org/rfc/rfc2409.txt 3555 10.2 Informative References 3557 [HTTP] Fielding, R., J. Gettys, J. Mogul, H. Frystyk, L. 3558 Masinter, P. Leach and T. Berners-Lee, "Hypertext 3559 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3560 http://www.ietf.org/rfc/rfc2616.txt 3562 [IKE-GROUPS] Kivinen, T. and M. Kojo "More Modular Exponential (MODP) 3563 Diffie-Hellman groups for Internet Key Exchange (IKE)", 3564 RFC3526, May 2003. 3565 http://www.ietf.org/rfc/rfc3526.txt 3567 [RQMTS] Pinkas, D. and R. Housley, "Delegated Path Validation and 3568 Delegated Path Discovery Protocol Requirements", RFC 3569 3379, September 2002. 3570 http://www.ietf.org/rfc/rfc3379.txt 3572 11 Intellectual Property Rights 3574 The IETF takes no position regarding the validity or scope of any 3575 Intellectual Property Rights or other rights that might be claimed 3576 to pertain to the implementation or use of the technology described 3577 in this document or the extent to which any license under such 3578 rights might or might not be available; nor does it represent that 3579 it has made any independent effort to identify any such rights. 3580 Information on the procedures with respect to rights in RFC 3581 documents can be found in BCP 78 and BCP 79. 3583 Copies of IPR disclosures made to the IETF Secretariat and any 3584 assurances of licenses to be made available, or the result of an 3585 attempt made to obtain a general license or permission for the use 3586 of such proprietary rights by implementers or users of this 3587 specification can be obtained from the IETF on-line IPR repository 3588 at http://www.ietf.org/ipr. 3590 The IETF invites any interested party to bring to its attention any 3591 copyrights, patents or patent applications, or other proprietary 3592 rights that may cover technology that may be required to implement 3593 this standard. Please address the information to the IETF at ietf- 3594 ipr@ietf.org. 3596 12 Acknowledgments 3598 The lively debate in the PKIX Working Group has made a significant 3599 impact on this protocol. Special thanks to the following for their 3600 contributions to this standard and diligence in greatly improving 3601 this document. 3603 Paul Hoffman 3604 Phillip Hallam-Baker 3605 Mike Myers 3606 Frank Balluffi 3607 Ameya Talwalkar 3608 John Thielens 3609 Peter Sylvester 3610 Yuriy Dzambasow 3611 Sean P. Turner 3612 Wen-Cheng Wang 3613 Francis Dupont 3614 Dave Engberg 3615 Faisal Maqsood 3617 Thanks also to working group chair Steve Kent for his support and 3618 help. 3620 Appendix A -- MIME Registrations 3622 Four MIME type registrations are provided in this appendix. 3624 A.1 application/cv-request 3626 To: ietf-types@iana.org 3627 Subject: Registration of MIME media type application/cv-request 3629 MIME media type name: application 3631 MIME subtype name: cv-request 3633 Required parameters: format 3635 Optional parameters: None 3637 Encoding considerations: binary 3639 Security considerations: Carries a request for information. This 3640 request may optionally be cryptographically protected. 3642 Interoperability considerations: None 3644 Published specification: IETF PKIX Working Group Draft on Standard 3645 Certificate Validation Protocol (SCVP) 3647 Applications that use this media type: SCVP clients 3649 Additional information: 3650 Magic number(s): None 3651 File extension(s): .SCQ 3652 Macintosh File Type Code(s): none 3654 Person & email address to contact for further information: 3655 Ambarish Malpani 3657 Intended usage: COMMON 3659 Author/Change controller: 3660 Ambarish Malpani 3662 A.2 application/cv-response 3664 To: ietf-types@iana.org 3665 Subject: Registration of MIME media type application/cv-response 3667 MIME media type name: application 3668 MIME subtype name: cv-response 3670 Required parameters: format 3672 Optional parameters: None 3674 Encoding considerations: binary 3676 Security considerations: The client may require that this response 3677 be cryptographically protected, or may choose to use secure 3678 transport mechanism. DPD responses may be unprotected, but the 3679 client validates the information provided in the request. 3681 Interoperability considerations: None 3683 Published specification: IETF PKIX Working Group Draft on Standard 3684 Certificate Validation Protocol (SCVP) 3686 Applications that use this media type: SCVP servers 3688 Additional information: 3690 Magic number(s): None 3691 File extension(s): .SCS 3692 Macintosh File Type Code(s): none 3694 Person & email address to contact for further information: 3695 Ambarish Malpani 3697 Intended usage: COMMON 3699 Author/Change controller: Ambarish Malpani 3701 A.3 application/vp-request 3703 To: ietf-types@iana.org 3704 Subject: Registration of MIME media type application/vp-request 3706 MIME media type name: application 3708 MIME subtype name: vp-request 3710 Required parameters: format 3712 Optional parameters: None 3714 Encoding considerations: binary 3715 Security considerations: Carries a request for information. 3717 Interoperability considerations: None 3719 Published specification: IETF PKIX Working Group Draft on Standard 3720 Certificate Validation Protocol (SCVP) 3722 Applications that use this media type: SCVP clients 3724 Additional information: 3726 Magic number(s): None 3727 File extension(s): .SPQ 3728 Macintosh File Type Code(s): none 3730 Person & email address to contact for further information: 3731 Ambarish Malpani 3733 Intended usage: COMMON 3735 Author/Change controller: Ambarish Malpani 3737 A.4 application/vp-response 3739 To: ietf-types@iana.org 3740 Subject: Registration of MIME media type application/vp-response 3742 MIME media type name: application 3744 MIME subtype name: vp-response 3746 Required parameters: format 3748 Optional parameters: None 3750 Encoding considerations: Binary 3752 Security considerations: None 3754 Interoperability considerations: None 3756 Published specification: IETF PKIX Working Group Draft on Standard 3757 Certificate Validation Protocol (SCVP) 3759 Applications that use this media type: SCVP servers 3761 Additional information: 3762 Magic number(s): None 3763 File extension(s): .SPP 3764 Macintosh File Type Code(s): none 3766 Person & email address to contact for further information: 3767 Ambarish Malpani 3769 Intended usage: COMMON 3771 Author/Change controller: 3772 Ambarish Malpani 3774 Appendix B -- SCVP over HTTP 3776 This appendix describes the formatting conventions for the SCVP 3777 request and response when carried by HTTP. 3779 B.1 SCVP Request 3781 HTTP based SCVP requests can use the POST method to submit their 3782 requests. Where privacy is a requirement, SCVP transactions 3783 exchanged using HTTP MAY be protected using either TLS/SSL or some 3784 other lower layer protocol. 3786 An SCVP request using the POST method is constructed as follows: 3788 The Content-Type header MUST have the value "application/cv- 3789 request". 3791 The Content-Length header MUST be present and have the exact 3792 length of the request. 3794 The body of the message is the binary value of the DER encoding 3795 of the CVRequest, wrapped in a CMS body as described in 3796 Section 3. Other HTTP headers MAY be present and MAY be 3797 ignored if not understood by the requestor. 3799 Sample Content-Type headers are: 3800 Content-Type: application/cv- request 3802 B.2 SCVP Response 3804 An HTTP-based SCVP response is composed of the appropriate HTTP 3805 headers, followed by the binary value of the BER encoding of the 3806 CVResponse, wrapped in a CMS body as described in Section 4. 3808 The Content-Type header MUST have the value "application/cv- 3809 response". 3811 The Content-Length header MUST be present and specify the length of 3812 the response. 3814 Other HTTP headers MAY be present and MAY be ignored if not 3815 understood by the requestor. 3817 B.3 SCVP Policy Request 3819 HTTP based SCVP policy requests can use the POST method to submit 3820 their requests. Where privacy is a requirement, SCVP transactions 3821 exchanged using HTTP MAY be protected using either TLS/SSL or some 3822 other lower layer protocol. 3824 An SCVP request using the POST method is constructed as follows: 3826 The Content-Type header MUST have the value "application/vp- 3827 request". 3829 The Content-Length header MUST be present and have the exact 3830 length of the request. 3832 The body of the message is the binary value of the BER encoding 3833 of the ValPolRequest, wrapped in a CMS body as described in 3834 Section 5. Other HTTP headers MAY be present and 3835 MAY be ignored if not understood by the requestor. 3837 Sample Content-Type headers are: 3838 Content-Type: application/vp-request 3840 B.4 SCVP Policy Response 3842 An HTTP-based SCVP policy response is composed of the appropriate 3843 HTTP headers, followed by the binary value of the DER encoding of 3844 the ValPolResponse, wrapped in a CMS body as described in Section 6. 3846 The Content-Type header MUST have the value "application/vp- 3847 response". 3849 The Content-Length header MUST be present and specify the length of 3850 the response. 3852 Other HTTP headers MAY be present and MAY be ignored if not 3853 understood by the requestor. 3855 Appendix C -- Authors' Addresses 3857 Trevor Freeman 3858 Microsoft Corporation, 3859 One Microsoft way. 3860 Redmond, WA 98052 3861 USA. 3862 trevorf@microsoft.com 3864 Russell Housley 3865 Vigil Security, LLC 3866 918 Spring Knoll Drive 3867 Herndon, VA 20170 3868 USA 3869 housley@Vigilsec.com 3871 Ambarish Malpani 3872 Malpani Consulting Services 3873 ambarish@malpani.biz 3875 David Cooper 3876 National Institute of Standards and Technology 3877 100 Bureau Drive, Mail Stop 8930 3878 Gaithersburg, MD 20899-8930 3879 david.cooper@nist.gov 3881 Tim Polk 3882 National Institute of Standards and Technology 3883 100 Bureau Drive, Mail Stop 8930 3884 Gaithersburg, MD 20899-8930 3885 tim.polk@nist.gov 3887 Full Copyright Statement 3889 Copyright (C) The Internet Society (2006). This document is subject 3890 to the rights, licenses and restrictions contained in BCP 78, and 3891 except as set forth therein, the authors retain all their rights. 3893 This document and the information contained herein are provided on 3894 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 3895 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 3896 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 3897 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3898 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3899 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3901 This document and translations of it may be copied and furnished to 3902 others, and derivative works that comment on or otherwise explain it 3903 or assist in its implementation may be prepared, copied, published 3904 and distributed, in whole or in part, without restriction of any 3905 kind, provided that the above copyright notice and this paragraph 3906 are included on all such copies and derivative works. In addition, 3907 the ASN.1 modules presented may be used in whole or in part without 3908 inclusion of the copyright notice. However, this document itself 3909 may not be modified in any way, such as by removing the copyright 3910 notice or references to the Internet Society or other Internet 3911 organizations, except as needed for the purpose of developing 3912 Internet standards in which case the procedures for copyrights 3913 defined in the Internet Standards process shall be followed, or as 3914 required to translate it into languages other than English.