idnits 2.17.1 draft-ietf-pkix-scvp-33.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, updated by RFC 4748 on line 4071. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3744. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3751. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3757. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 IETF Trust 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 3394 -- Looks like a reference, but probably isn't: '1' on line 3396 -- Looks like a reference, but probably isn't: '2' on line 3397 -- Looks like a reference, but probably isn't: '3' on line 3331 -- Looks like a reference, but probably isn't: '4' on line 3332 -- Looks like a reference, but probably isn't: '5' on line 3333 -- Looks like a reference, but probably isn't: '6' on line 3334 -- Looks like a reference, but probably isn't: '7' on line 3335 -- Looks like a reference, but probably isn't: '8' on line 3336 ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) ** 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) ** Obsolete normative reference: RFC 3850 (ref. 'SMIME-CERT') (Obsoleted by RFC 5750) ** Obsolete normative reference: RFC 4306 (ref. 'IKE') (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) Summary: 8 errors (**), 0 flaws (~~), 3 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-33.txt Microsoft Corp 4 September 2007 R. Housley 5 Expires: March 2008 Vigil Security 6 A. Malpani 7 Malpani Consulting Services 8 D. Cooper 9 NIST 10 W. Polk 11 NIST 13 Server-based 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 months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 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 IETF Trust (2007). 42 Abstract 44 SCVP allows a client to delegate certification path construction and 45 certification 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 Terminology . . . . . . . . . . . . . . . . . . . . . . 5 56 1.2 SCVP overview . . . . . . . . . . . . . . . . . . . . . 5 57 1.3 SCVP Requirements . . . . . . . . . . . . . . . . . . . 6 58 1.4 Validation Policies . . . . . . . . . . . . . . . . . . 7 59 1.5 Validation Algorithm . . . . . . . . . . . . . . . . . . 8 60 1.6 Validation Requirements . . . . . . . . . . . . . . . . 8 61 2 Protocol Overview . . . . . . . . . . . . . . . . . . . . 9 62 3 Validation Request . . . . . . . . . . . . . . . . . . . . 9 63 3.1 cvRequestVersion . . . . . . . . . . . . . . . . . . . . 12 64 3.2 query . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 3.2.1 queriedCerts . . . . . . . . . . . . . . . . . . . . . 13 66 3.2.2 checks . . . . . . . . . . . . . . . . . . . . . . . . 15 67 3.2.3 wantBack . . . . . . . . . . . . . . . . . . . . . . . 16 68 3.2.4 validationPolicy . . . . . . . . . . . . . . . . . . . 19 69 3.2.4.1 validationPolRef . . . . . . . . . . . . . . . . . . 21 70 3.2.4.1.1 Default Validation Policy . . . . . . . . . . . . 21 71 3.2.4.2 validationAlg . . . . . . . . . . . . . . . . . . . 22 72 3.2.4.2.1 Basic Validation Algorithm . . . . . . . . . . . . 22 73 3.2.4.2.2 Basic Validation Algorithm Errors . . . . . . . . 23 74 3.2.4.2.3 Name Validation Algorithm . . . . . . . . . . . . 24 75 3.2.4.2.4 Name Validation Algorithm Errors . . . . . . . . . 25 76 3.2.4.3 userPolicySet . . . . . . . . . . . . . . . . . . . 26 77 3.2.4.4 inhibitPolicyMapping . . . . . . . . . . . . . . . . 26 78 3.2.4.5 requireExplicitPolicy . . . . . . . . . . . . . . . 27 79 3.2.4.6 inhibitAnyPolicy . . . . . . . . . . . . . . . . . . 27 80 3.2.4.7 trustAnchors . . . . . . . . . . . . . . . . . . . . 27 81 3.2.4.8 keyUsages . . . . . . . . . . . . . . . . . . . . . 28 82 3.2.4.9 extendedKeyUsages . . . . . . . . . . . . . . . . . 28 83 3.2.4.10 specifiedKeyUsages . . . . . . . . . . . . . . . . 29 84 3.2.5 responseFlags . . . . . . . . . . . . . . . . . . . . 30 85 3.2.5.1 fullRequestInResponse . . . . . . . . . . . . . . . 30 86 3.2.5.2 responseValidationPolByRef . . . . . . . . . . . . . 30 87 3.2.5.3 protectResponse . . . . . . . . . . . . . . . . . . 31 88 3.2.5.4 cachedResponse . . . . . . . . . . . . . . . . . . . 31 89 3.2.6 serverContextInfo . . . . . . . . . . . . . . . . . . 32 90 3.2.7 validationTime . . . . . . . . . . . . . . . . . . . . 32 91 3.2.8 intermediateCerts . . . . . . . . . . . . . . . . . . 33 92 3.2.9 revInfos . . . . . . . . . . . . . . . . . . . . . . . 34 93 3.2.10 producedAt . . . . . . . . . . . . . . . . . . . . . 35 94 3.2.11 queryExtensions . . . . . . . . . . . . . . . . . . . 35 95 3.2.11.1 extnID . . . . . . . . . . . . . . . . . . . . . . 35 96 3.2.11.2 critical . . . . . . . . . . . . . . . . . . . . . 35 97 3.2.11.3 extnValue . . . . . . . . . . . . . . . . . . . . . 36 98 3.3 requestorRef . . . . . . . . . . . . . . . . . . . . . . 36 99 3.4 requestNonce . . . . . . . . . . . . . . . . . . . . . . 36 100 3.5 requestorName . . . . . . . . . . . . . . . . . . . . . 37 101 3.6 responderName . . . . . . . . . . . . . . . . . . . . . 37 102 3.7 requestExtensions . . . . . . . . . . . . . . . . . . . 37 103 3.7.1 extnID . . . . . . . . . . . . . . . . . . . . . . . . 38 104 3.7.2 critical . . . . . . . . . . . . . . . . . . . . . . . 38 105 3.7.3 extnValue . . . . . . . . . . . . . . . . . . . . . . 38 106 3.8 signatureAlg . . . . . . . . . . . . . . . . . . . . . . 38 107 3.9 hashAlg . . . . . . . . . . . . . . . . . . . . . . . . 39 108 3.10 requestorText . . . . . . . . . . . . . . . . . . . . . 39 109 3.11 SCVP Request Authentication . . . . . . . . . . . . . . 40 110 4 Validation Response . . . . . . . . . . . . . . . . . . . 40 111 4.1 cvResponseVersion . . . . . . . . . . . . . . . . . . . 43 112 4.2 serverConfigurationID . . . . . . . . . . . . . . . . . 43 113 4.3 producedAt . . . . . . . . . . . . . . . . . . . . . . . 43 114 4.4 responseStatus . . . . . . . . . . . . . . . . . . . . . 43 115 4.5 respValidationPolicy . . . . . . . . . . . . . . . . . . 46 116 4.6 requestRef . . . . . . . . . . . . . . . . . . . . . . . 46 117 4.6.1 requestHash . . . . . . . . . . . . . . . . . . . . . 47 118 4.6.2 fullRequest . . . . . . . . . . . . . . . . . . . . . 47 119 4.7 requestorRef . . . . . . . . . . . . . . . . . . . . . . 48 120 4.8 requestorName . . . . . . . . . . . . . . . . . . . . . 48 121 4.9 replyObjects . . . . . . . . . . . . . . . . . . . . . . 48 122 4.9.1 cert . . . . . . . . . . . . . . . . . . . . . . . . . 49 123 4.9.2 replyStatus . . . . . . . . . . . . . . . . . . . . . 49 124 4.9.3 replyValTime . . . . . . . . . . . . . . . . . . . . . 51 125 4.9.4 replyChecks . . . . . . . . . . . . . . . . . . . . . 51 126 4.9.5 replyWantBacks . . . . . . . . . . . . . . . . . . . . 53 127 4.9.6 validationErrors . . . . . . . . . . . . . . . . . . . 55 128 4.9.7 nextUpdate . . . . . . . . . . . . . . . . . . . . . . 55 129 4.9.8 certReplyExtensions . . . . . . . . . . . . . . . . . 56 130 4.10 respNonce . . . . . . . . . . . . . . . . . . . . . . . 56 131 4.11 serverContextInfo . . . . . . . . . . . . . . . . . . . 57 132 4.12 cvResponseExtensions . . . . . . . . . . . . . . . . . 57 133 4.13 requestorText . . . . . . . . . . . . . . . . . . . . . 58 134 4.14 SCVP Response Validation . . . . . . . . . . . . . . . 58 135 4.14.1 Simple Key Validation . . . . . . . . . . . . . . . . 58 136 4.14.2 SCVP Server Certificate Validation . . . . . . . . . 58 137 5 Server Policy Request . . . . . . . . . . . . . . . . . . 59 138 5.1 vpRequestVersion . . . . . . . . . . . . . . . . . . . . 60 139 5.2 requestNonce . . . . . . . . . . . . . . . . . . . . . . 60 140 6 Validation Policy Response . . . . . . . . . . . . . . . . 60 141 6.1 vpResponseVersion . . . . . . . . . . . . . . . . . . . 61 142 6.2 maxCVRequestVersion . . . . . . . . . . . . . . . . . . 61 143 6.3 maxVPRequestVersion . . . . . . . . . . . . . . . . . . 62 144 6.4 serverConfigurationID . . . . . . . . . . . . . . . . . 62 145 6.5 thisUpdate . . . . . . . . . . . . . . . . . . . . . . . 62 146 6.6 nextUpdate and requestNonce . . . . . . . . . . . . . . 62 147 6.7 supportedChecks . . . . . . . . . . . . . . . . . . . . 63 148 6.8 supportedWantBacks . . . . . . . . . . . . . . . . . . . 63 149 6.9 validationPolicies . . . . . . . . . . . . . . . . . . . 63 150 6.10 validationAlgs . . . . . . . . . . . . . . . . . . . . 63 151 6.11 authPolicies . . . . . . . . . . . . . . . . . . . . . 63 152 6.12 responseTypes . . . . . . . . . . . . . . . . . . . . . 63 153 6.13 revocationInfoTypes . . . . . . . . . . . . . . . . . . 64 154 6.14 defaultPolicyValues . . . . . . . . . . . . . . . . . . 64 155 6.15 signatureGeneration . . . . . . . . . . . . . . . . . . 64 156 6.16 signatureVerification . . . . . . . . . . . . . . . . . 64 157 6.17 hashAlgorithms . . . . . . . . . . . . . . . . . . . . 65 158 6.18 serverPublicKeys . . . . . . . . . . . . . . . . . . . 65 159 6.19 clockSkew . . . . . . . . . . . . . . . . . . . . . . . 66 160 7 SCVP Server Relay . . . . . . . . . . . . . . . . . . . . 66 161 8 SCVP ASN.1 Module . . . . . . . . . . . . . . . . . . . . 67 162 9 Security Considerations . . . . . . . . . . . . . . . . . 75 163 10 IANA Considerations . . . . . . . . . . . . . . . . . . . 77 164 11 References . . . . . . . . . . . . . . . . . . . . . . . 77 165 11.1 Normative References . . . . . . . . . . . . . . . . . 77 166 11.2 Informative References . . . . . . . . . . . . . . . . 78 167 12 Intellectual Property Rights . . . . . . . . . . . . . . 79 168 13 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 79 169 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . 80 170 Appendix A. MIME Registrations . . . . . . . . . . . . . . . 81 171 A.1 application/scvp-cv-request . . . . . . . . . . . . . . 81 172 A.2 application/scvp-cv-response . . . . . . . . . . . . . . 82 173 A.3 application/scvp-vp-request . . . . . . . . . . . . . . 83 174 A.4 application/scvp-vp-response . . . . . . . . . . . . . . 83 175 Appendix B. SCVP over HTTP . . . . . . . . . . . . . . . . . 84 176 B.1 SCVP Request . . . . . . . . . . . . . . . . . . . . . . 85 177 B.2 SCVP Response . . . . . . . . . . . . . . . . . . . . . 85 178 B.3 SCVP Policy Request . . . . . . . . . . . . . . . . . . 85 179 B.4 SCVP Policy Response . . . . . . . . . . . . . . . . . . 85 180 Full Copyright Statement . . . . . . . . . . . . . . . . . . 86 182 1 Introduction 184 Certificate validation is complex. If certificate handling is to be 185 widely deployed in a variety of applications and environments, the 186 amount of processing an application needs to perform before it can 187 accept a certificate needs to be reduced. There are a variety of 188 applications that can make use of public key certificates, but these 189 applications are burdened with the overhead of constructing and 190 validating the certification paths. SCVP reduces this overhead for 191 two classes of certificate-using applications. 193 The first class of applications wants just two things: confirmation 194 that the public key belongs to the identity named in the certificate 195 and confirmation that the public key can be used for the intended 196 purpose. Such clients can completely delegate certification path 197 construction and validation to the SCVP server. This is often 198 referred to as delegated path validation (DPV). 200 The second class of applications can perform certification path 201 validation, but they lack a reliable or efficient method of 202 constructing a valid certification path. Such clients delegate 203 certification path construction to the SCVP server, but not 204 validation of the returned certification path. This is often 205 referred to as delegated path discovery (DPD). 207 1.1 Terminology 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 211 document are to be interpreted as described in [STDWORDS]. 213 1.2 SCVP overview 215 The primary goals of SCVP are to make it easier to deploy PKI-enabled 216 applications by delegating path discovery and/or validation 217 processing to a server, and to allow central administration of 218 validation policies within an organization. SCVP can be used by 219 clients that do much of the certificate processing themselves but 220 simply want an untrusted server to collect information for them. 221 However, when the client has complete trust in the SCVP server, SCVP 222 can be used to delegate the work of certification path construction 223 and validation, and SCVP can be used to ensure that policies are 224 consistently enforced throughout an organization. 226 Untrusted SCVP servers can provide clients the certification paths. 227 They can also provide clients the revocation information, such as 228 CRLs and OCSP responses, that the clients need to validate the 229 certification paths constructed by the SCVP server. These services 230 can be valuable to clients that do not implement the protocols needed 231 to find and download intermediate certificates, CRLs, and OCSP 232 responses. 234 Trusted SCVP servers can perform certification path construction and 235 validation for the client. For a client that uses these services, 236 the client inherently trusts the SCVP server as much as it would its 237 own certification path validation software (if it contained such 238 software). There are two main reasons that a client may want to 239 trust such an SCVP server: 241 1. The client does not want to incur the overhead of including 242 certification path validation software and running it for each 243 certificate it receives. 245 2. The client is in an organization or community that wants to 246 centralize management of validation policies. These policies 247 might dictate that particular trust anchors are to be used and 248 the types of policy checking that are to be performed during 249 certification path validation. 251 1.3 SCVP Requirements 253 SCVP meets the mandatory requirements documented in [RQMTS] for DPV 254 and DPD. 256 Note that RFC 3379 states the following requirement: 257 "The DPD response MUST indicate one of the following status 258 alternatives: 259 1) one or more certification paths was found according to the 260 path discovery policy, with all of the requested revocation 261 information present. 262 2) one or more certification paths was found according to the 263 path discovery policy, with a subset of the requested 264 revocation information present. 265 3) one or more certification paths was found according to the 266 path discovery policy, with none of the requested revocation 267 information present. 268 4) no certification path was found according to the path 269 discovery policy. 270 5) path construction could not be performed due to an error." 272 DPD responses constructed by SCVP servers do not differentiate 273 between states 2) and 3). This property was discussed on list and 274 determined to be conformant with the intent of [RQMTS]. 276 1.4 Validation Policies 278 A validation policy (as defined in RFC 3379 [RQMTS]) specifies the 279 rules and parameters to be used by the SCVP server when validating a 280 certificate. In SCVP, the validation policy to be used by the server 281 can either be fully referenced in the request by the client (and thus 282 no additional parameters are necessary) or it can be referenced in 283 the request by the client with additional parameters. 285 Policy definitions can be quite long and complex, and some policies 286 may allow for the setting of a few parameters. The request can 287 therefore be very simple if an OBJECT IDENTIFIER (OID) is used to 288 specify both the algorithm to be used and all the associated 289 parameters of the validation policy. The request can be more complex 290 if the validation policy fixes many of the parameters but allows the 291 client to specify some of them. When the validation policy defines 292 every parameter necessary, an SCVP request needs only to contain the 293 certificate to be validated, the referenced validation policy, and 294 any run-time parameters for the request. 296 A server publishes the references of the validation policies it 297 supports. When these policies have parameters that may be 298 overridden, the server communicates the default values for these 299 parameters as well. The client can simplify the request by omitting 300 a parameter from a request if the default value published by the 301 server for a given validation policy reference is acceptable. 302 However, if there is a desire to demonstrate to someone else that a 303 specific validation policy with all its parameters has been used, the 304 client will need to ask the server for the inclusion of the full 305 validation policy with all the parameters in the response. 307 The inputs to the basic certification path processing algorithm used 308 by SCVP are defined by [PKIX-1] in section 6.1.1 and comprise: 310 Certificate to be validated (by value or by reference); 312 Validation time; 314 The initial policy set; 316 Initial inhibit policy mapping setting; 318 Initial inhibit anyPolicy setting; and 320 Initial require explicit policy setting. 322 The basic certification path processing algorithm also supports 323 specification of one or more Trust Anchors (by value or reference) as 324 an input. Where the client demands a certification path originating 325 with a specific CA, a single Trust Anchor is specified. Where the 326 client is willing to accept paths beginning with any of several CAs, 327 a set of Trust anchors is specified. 329 The basic certification path processing algorithm also supports the 330 following parameters, which are defined in [PKIX-1] section 4: 332 The usage of the key contained in the certificate (e.g., key 333 encipherment, key agreement, signature); and 335 Other application-specific purposes for which the certified public 336 key may be used. 338 1.5 Validation Algorithm 340 The validation algorithm is determined by agreement between the 341 client and the server and is represented as an OID. The algorithm 342 defines the checking that will be performed by the server to 343 determine whether the certificate is valid. A validation algorithm 344 is one of the parameters to a validation policy. SCVP defines a 345 basic validation algorithm that implements the basic path validation 346 algorithm as defined in [PKIX-1], and permits the client to request 347 additional information about the certificate to be validated. New 348 validation algorithms can be specified that define additional checks 349 if needed. These new validation algorithms may specify additional 350 parameters. The values for these parameters may be defined by any 351 validation policy that uses the algorithm or may be included by the 352 client in the request. 354 Application-specific validation algorithms in addition to those 355 defined in this document can be defined to meet specific requirements 356 not covered by the basic validation algorithm. The validation 357 algorithms documented here should serve as a guide for the 358 development of further application-specific validation algorithms. 359 For example, a new application-specific validation algorithm might 360 require the presence of a particular name form in the subject 361 alternative name extension of the certificate. 363 1.6 Validation Requirements 365 For a certification path to be considered valid under a particular 366 validation policy it MUST be a valid certification path as defined in 367 [PKIX-1] and all validation policy constraints that apply to the 368 certification path MUST be verified. 370 Revocation checking is one aspect of certification path validation 371 defined in [PKIX-1]. However, revocation checking is an optional 372 feature in [PKIX-1], and revocation information is distributed in 373 multiple formats. Clients specify in requests whether revocation 374 checking should be performed and whether revocation information 375 should be returned in the response. 377 Servers MUST be capable of indicating the sources of revocation 378 information that they are capable of processing: 380 1. full CRLs (or full Authority Revocation Lists); 382 2. OCSP responses, using [OCSP]; 384 3. delta CRLs; and 386 4. indirect CRLs. 388 2 Protocol Overview 390 SCVP uses a simple request-response model. That is, the SCVP client 391 creates a request and sends it to the SCVP server, and then the SCVP 392 server creates a single response and sends it to the client. The 393 typical use of SCVP is expected to be over HTTP [HTTP], but it can 394 also be used with email or any other protocol that can transport 395 digitally signed objects. Appendices A and B provide the details 396 necessary to use SCVP with HTTP. 398 SCVP includes two request-response pairs. The primary request- 399 response pair handles certificate validation. The secondary request- 400 response pair is used to determine the list of validation policies 401 and default parameters supported by a specific SCVP server. 403 Section 3 defines the certificate validation request. 405 Section 4 defines the corresponding certificate validation response. 407 Section 5 defines the validation policies request. 409 Section 6 defines the corresponding validation policies response. 411 Appendix A registers MIME types for SCVP requests and responses, and 412 Appendix B describes the use of these MIME types with HTTP. 414 3 Validation Request 416 An SCVP client request to the server MUST be a single CVRequest item. 417 When a CVRequest is encapsulated in a MIME body part, 418 application/scvp-cv-request MUST be used. 420 There are two forms of SCVP request: unprotected and protected. A 421 protected request is used to authenticate the client to the server or 422 to provide anonymous client integrity over the request-response pair. 423 The protection is provided by a digital signature or message 424 authentication code (MAC). In the later case, the MAC key is derived 425 using a key agreement algorithm, such as Diffie-Hellman. If the 426 client's public key is contained in a certificate, then it may be 427 used to authenticate the client. More commonly, the client's key 428 agreement public key will be ephemeral, supporting anonymous client 429 integrity. 431 A server MAY require all requests to be protected, and a server MAY 432 discard all unprotected requests. Alternatively, a server MAY choose 433 to process unprotected requests. 435 The unprotected request consists of a CVRequest encapsulated in a CMS 436 ContentInfo [CMS]. An overview of this structure is provided below 437 and is only intended as illustrative. The definitive ASN.1 is found 438 in [CMS]. Many details are not shown, but the way that SCVP makes 439 use of CMS is clearly illustrated. 441 ContentInfo { 442 contentType id-ct-scvp-certValRequest, 443 -- (1.2.840.113549.1.9.16.1.10) 444 content CVRequest } 446 The protected request consists of a CVRequest encapsulated in either 447 a SignedData or AuthenticatedData, which is in turn encapsulated in a 448 ContentInfo. That is, the EncapsulatedContentInfo field of either 449 SignedData or AuthenticatedData consists of an eContentType field 450 with a value of id-ct-scvp-certValRequest and an eContent field that 451 contains a DER encoded CVRequest. SignedData is used when the 452 request is digitally signed. AuthenticatedData is used with a 453 message authentication code (MAC). 455 All SCVP clients and servers MUST support SignedData for signed 456 requests and responses. SCVP clients and servers SHOULD support 457 AuthenticatedData for MAC protected requests and responses. 459 If the client uses SignedData it MUST have a public key that has been 460 bound to a subject identity by a certificate that conforms to the 461 PKIX profile [PKIX-1] and that certificate MUST be suitable for 462 signing the SCVP request. That is: 464 1. If the key usage extension is present, either the digital 465 signature or the non-repudiation bit MUST be asserted. 467 2. If the extended key usage extension is present, it MUST 468 contain either the SCVP client OID (see Section 3.11), the 469 anyExtendedKeyUsage OID, or another OID acceptable to the SCVP 470 server. 472 The client MUST put an unambiguous reference to its certificate in 473 the SignedData that encapsulates the request. The client SHOULD 474 include its certificate in the request, but MAY omit the certificate 475 to reduce the size of the request. The client MAY include other 476 certificates in the request to aid the validation of its certificates 477 by the SCVP server. The signerInfos field of SignedData MUST include 478 exactly one SignerInfo. The SignedData MUST NOT include the 479 unsignedAttrs field. 481 The client MUST put its key agreement public key or an unambiguous 482 reference to a certificate that contains its key agreement public key 483 in the AuthenticatedData that encapsulates the request. If an 484 ephemeral key agreement key pair is used, then the ephemeral key 485 agreement public key is carried in the originatorKey field of 486 KeyAgreeRecipientInfo, which requires the client to obtain the 487 server's key agreement public key before computing the message 488 authentication code (MAC). An SCVP server's key agreement key is 489 included in its validation policy response message (see Section 6). 490 The recipientInfos field of AuthenticatedData MUST include exactly 491 one RecipientInfo, which contains information for the SCVP server. 492 The AuthenticatedData MUST NOT include the unauthAttrs field. 494 The syntax and semantics for SignedData, AuthenticatedData, and 495 ContentInfo are defined in [CMS]. The syntax and semantics for 496 CVRequest are defined below. The CVRequest item contains the client 497 request. The CVRequest contains the cvRequestVersion and query 498 items; the CVRequest MAY also contain the requestorRef, requestNonce, 499 requestorName, responderName, requestExtensions, signatureAlg, and 500 hashAlg items. 502 The CVRequest MUST have the following syntax: 504 CVRequest ::= SEQUENCE { 505 cvRequestVersion INTEGER DEFAULT 1, 506 query Query, 507 requestorRef [0] GeneralNames OPTIONAL, 508 requestNonce [1] OCTET STRING OPTIONAL, 509 requestorName [2] GeneralName OPTIONAL, 510 responderName [3] GeneralName OPTIONAL, 511 requestExtensions [4] Extensions OPTIONAL, 512 signatureAlg [5] AlgorithmIdentifier OPTIONAL, 513 hashAlg [6] OBJECT IDENTIFIER OPTIONAL, 514 requestorText [7] UTF8String (SIZE (1..256)) OPTIONAL } 516 Conforming clients MUST be able to construct requests with 517 cvRequestVersion and query. Conforming clients MUST DER-encode the 518 CVRequest in both protected and unprotected messages to facilitate 519 unambiguous hash-based referencing in the corresponding response 520 message. SCVP clients that insist on creation of a fresh response 521 (e.g., to protect against a replay attack or ensure information is up 522 to date) MUST support requestNonce. Support for the remaining items 523 is optional in client implementations. 525 Conforming servers MUST be able to parse CVRequests that contain any 526 or all of the optional items. 528 Each of the items within the CVRequest is described in the following 529 sections. 531 3.1 cvRequestVersion 533 The cvRequestVersion item defines the version of the SCVP CVRequest 534 used in a request. The subsequent response MUST use the same version 535 number. The value of the cvRequestVersion item MUST be one (1) for a 536 client implementing this specification. Future updates to this 537 specification must specify other values if there are any changes to 538 syntax or semantics. However, new extensions may be defined without 539 changing the version number. 541 SCVP clients MUST support asserting this value and SCVP servers MUST 542 be capable of processing this value. 544 3.2 query 546 The query item specifies one or more certificates that are the 547 subject of the request; the certificates can be either public key 548 certificates [PKIX-1] or attribute certificates [PKIX-AC]. A query 549 MUST contain a queriedCerts item as well as one checks item, and one 550 validationPolicy item; a query MAY also contain wantBack, 551 responseFlags, serverContextInfo, validationTime, intermediateCerts, 552 revInfos, producedAt, and queryExtensions items. 554 Query MUST have the following syntax: 556 Query ::= SEQUENCE { 557 queriedCerts CertReferences, 558 checks CertChecks, 559 -- Note: tag [0] not used -- 560 wantBack [1] WantBack OPTIONAL, 561 validationPolicy ValidationPolicy, 562 responseFlags ResponseFlags OPTIONAL, 563 serverContextInfo [2] OCTET STRING OPTIONAL, 564 validationTime [3] GeneralizedTime OPTIONAL, 565 intermediateCerts [4] CertBundle OPTIONAL, 566 revInfos [5] RevocationInfos OPTIONAL, 567 producedAt [6] GeneralizedTime OPTIONAL, 568 queryExtensions [7] Extensions OPTIONAL } 570 The list of certificate references in the queriedCerts item tells the 571 server the certificate(s) for which the client wants information. 572 The checks item specifies the checking that the client wants 573 performed. The wantBack item specifies the objects that the client 574 wants the server to return in the response. The validationPolicy 575 item specifies the validation policy that the client wants the server 576 to employ. The responseFlags item allows the client to request 577 optional features for the response. The serverContextInfo item tells 578 the server that additional information from a previous request- 579 response is desired. The validationTime item tells the date and time 580 relative to which the client wants the server to perform the checks. 581 The intermediateCerts and revInfos items provide context for the 582 client request. The queryExtensions item provides for future 583 expansion of the query syntax. The syntax and semantics of each of 584 these items is discussed in the following sections. 586 Conforming clients MUST be able to construct a Query with a 587 queriedCerts item that specifies at least one certificate, checks, 588 and validationPolicy. Conforming SCVP clients MAY support 589 specification of multiple certificates and MAY support the optional 590 items in the Query structure. 592 SCVP clients that support delegated path discovery (DPD) as defined 593 in [RQMTS] MUST support wantBack and responseFlags. SCVP clients 594 that insist on creation of a fresh response (e.g., to protect against 595 a replay attack or ensure information is up to date) MUST support 596 responseFlags. 598 Conforming servers MUST be able to process a Query that contains any 599 of the optional items, and MUST be able to process a Query that 600 specifies multiple certificates. 602 3.2.1 queriedCerts 604 The queriedCerts item is a SEQUENCE of one or more certificates, each 605 of which is a subject of the request. The specified certificates are 606 either public key certificates or attribute certificates; if more 607 than one certificate is specified, all must be of the same type. 608 Each certificate is either directly included or it is referenced. 609 When referenced, a hash value of the referenced item is included to 610 ensure that the SCVP client and the SCVP server both obtain the same 611 certificate when the referenced certificate is fetched. Certificate 612 references use the SCVPCertID type, which is described below. A 613 single request MAY contain both directly included and referenced 614 certificates. 616 CertReferences has the following syntax: 618 CertReferences ::= CHOICE { 619 pkcRefs [0] SEQUENCE SIZE (1..MAX) OF PKCReference, 620 acRefs [1] SEQUENCE SIZE (1..MAX) OF ACReference } 622 PKCReference ::= CHOICE { 623 cert [0] Certificate, 624 pkcRef [1] SCVPCertID } 626 ACReference ::= CHOICE { 627 attrCert [2] AttributeCertificate, 628 acRef [3] SCVPCertID } 630 SCVPCertID ::= SEQUENCE { 631 certHash OCTET STRING, 632 issuerSerial SCVPIssuerSerial, 633 hashAlgorithm AlgorithmIdentifier DEFAULT { algorithm sha-1 } } 635 The ASN.1 definition of Certificate is imported from [PKIX-1] and the 636 definition of AttributeCertificate is imported from [PKIX-AC]. 638 When creating a SCVPCertID, the certHash is computed over the entire 639 DER encoded certificate including the signature. The hash algorithm 640 used to compute certHash is specified in hashAlgorithm. The hash 641 algorithm used to compute certHash SHOULD be one of the hash 642 algorithms specified in the hashAlgorithms item of the server's 643 validation policy response message. 645 When encoding SCVPIssuerSerial, serialNumber is the serial number 646 that uniquely identifies the certificate. For public key 647 certificates, the issuer MUST contain only the issuer name from the 648 certificate encoded in the directoryName choice of GeneralNames. For 649 attribute certificates, the issuer MUST contain the issuer name field 650 from the attribute certificate. 652 Conforming clients MUST be able to reference a certificate by direct 653 inclusion. Clients SHOULD be able to specify a certificate using the 654 SCVPCertID. Conforming clients MAY be able to reference multiple 655 certificates and MAY be able to reference both public key and 656 attribute certificates. 658 Conforming SCVP Server implementations MUST be able to process 659 CertReferences with multiple certificates. Conforming SCVP Server 660 implementations MUST be able to parse CertReferences that contain 661 either public key or attribute certificates. Conforming SCVP Server 662 implementations MUST be able to parse both the cert and pkcRef 663 choices in PKCReference. Conforming SCVP Server implementations that 664 process attribute certificates MUST be able to parse both the 665 attrCert and acRef choices in ACReference. 667 3.2.2 checks 669 The checks item describes the checking that the SCVP client wants the 670 SCVP server to perform on the certificate(s) in the queriedCerts 671 item. The checks item contains a sequence of object identifiers 672 (OIDs). Each OID tells the SCVP server what checking the client 673 expects the server to perform. For each check specified in the 674 request, the SCVP server MUST perform the requested check, or return 675 an error. A server may choose to perform additional checks (e.g., a 676 server that is only asked to build a validated certification path may 677 choose to also perform revocation status checks), although the server 678 cannot indicate in the response that the additional checks have been 679 performed, except in the case of an error response. 681 The checks item uses the CertChecks type, which has the following 682 syntax: 684 CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 686 For public key certificates, the following checks are defined in this 687 document: 689 - id-stc-build-pkc-path: Build a prospective certification path to a 690 trust anchor (as defined in section 6.1 of [PKIX-1]); 692 - id-stc-build-valid-pkc-path: Build a validated certification path 693 to a trust anchor (revocation checking not required); 695 - id-stc-build-status-checked-pkc-path: Build a validated 696 certification path to a trust anchor and perform revocation 697 status checks on the certification path. 699 Conforming SCVP server implementations that support delegated path 700 discovery (DPD) as defined in [RQMTS] MUST support the id-stc-build- 701 pkc-path check. Conforming SCVP server implementations that support 702 delegated path validation (DPV) as defined in [RQMTS] MUST support 703 the id-stc-build-valid-pkc-path and id-stc-build-status-checked-pkc- 704 path checks. 706 For attribute certificates, the following checks are defined in this 707 document: 709 - id-stc-build-aa-path: Build a prospective certification path to a 710 trust anchor for the AC issuer; 712 - id-stc-build-valid-aa-path: Build a validated certification path 713 to a trust anchor for the AC issuer; 715 - id-stc-build-status-checked-aa-path: Build a validated 716 certification path to a trust anchor for the AC issuer and 717 perform revocation status checks on the certification path for 718 the AC issuer; 720 - id-stc-status-check-ac-and-build-status-checked-aa-path: Build a 721 validated certification path to a trust anchor for the AC issuer 722 and perform revocation status checks on the AC as well as the 723 certification path for the AC issuer. 725 Conforming SCVP server implementations MAY support the attribute 726 certificates checks. 728 For these purposes, the following OIDs are defined: 730 id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 731 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 } 733 id-stc-build-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 } 734 id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 2 } 735 id-stc-build-status-checked-pkc-path 736 OBJECT IDENTIFIER ::= { id-stc 3 } 737 id-stc-build-aa-path OBJECT IDENTIFIER ::= { id-stc 4 } 738 id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 5 } 739 id-stc-build-status-checked-aa-path 740 OBJECT IDENTIFIER ::= { id-stc 6 } 741 id-stc-status-check-ac-and-build-status-checked-aa-path 742 OBJECT IDENTIFIER ::= { id-stc 7 } 744 Other specifications may define additional checks. 746 Conforming client implementations MUST support assertion of at least 747 one of the standard checks. Conforming clients MAY support assertion 748 of multiple checks. Conforming clients need not support all of the 749 checks defined in this section. 751 3.2.3 wantBack 753 The optional wantBack item describes any information the SCVP client 754 wants from the SCVP server for the certificate(s) in the queriedCerts 755 item in addition to the results of the checks specified in the checks 756 item. If present, the wantBack item MUST contain a sequence of 757 object identifiers (OIDs). Each OID tells the SCVP server what the 758 client wants to know about the queriedCerts item. For each type of 759 information specified in the request, the server MUST return 760 information regarding its finding (in a successful response). 762 For example, a request might include a checks item that only 763 specifies certification path building and include a wantBack item 764 that requests the return of the certification path built by the 765 server. In this case, the response would not include a status for 766 the validation of the certification path, but it would include a 767 prospective certification path. A client that wants to perform its 768 own certification path validation might use a request of this form. 770 Alternatively, a request might include a checks item that requests 771 the server to build a certification path and validate it, including 772 revocation checking, and not include a wantBack item. In this case, 773 the response would include only a status for the validation of the 774 certification path. A client that completely delegates certification 775 path validation might use a request of this form. 777 The wantBack item uses the WantBack type, which has the following 778 syntax: 780 WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 782 For public key certificates, the following wantBacks are defined in 783 this document: 785 - id-swb-pkc-cert: The certificate that was the subject of the 786 request; 788 - id-swb-pkc-best-cert-path: The certification path built for the 789 certificate including the certificate that was validated; 791 - id-swb-pkc-revocation-info: Proof of revocation status for each 792 certificate in the certification path; 794 - id-swb-pkc-public-key-info: The public key from the certificate 795 that was the subject of the request; 797 - id-swb-pkc-all-cert-paths: A set of certification paths for the 798 certificate that was the subject of the request; 800 - id-swb-pkc-ee-revocation-info: Proof of revocation status for the 801 end entity certificate in the certification path; and 803 - id-swb-pkc-CAs-revocation-info: Proof of revocation status for 804 each CA certificate in the certification path. 806 All conforming SCVP server implementations MUST support the id-swb- 807 pkc-cert and id-swb-pkc-public-key-info wantBacks. Conforming SCVP 808 server implementations that support delegated path discovery (DPD) as 809 defined in [RQMTS] MUST support the id-swb-pkc-best-cert-path and id- 810 swb-pkc-revocation-info wantBacks. 812 The SCVP protocol provides two methods for a client to obtain 813 multiple certification paths for a certificate. The client could use 814 serverContextInfo to request one path at a time (see section 3.2.6). 815 After obtaining each path, the client could submit the 816 serverContextInfo from the previous request to obtain another path 817 until the client either found a suitable path or the server indicated 818 (by not returning a serverContextInfo) that no more paths were 819 available. Alternatively, the client could send a single request 820 with an id-swb-pkc-all-cert-paths wantBack, in which case the server 821 would return all of the available paths in a single response. 823 The server may, at its discretion, limit the number of paths that it 824 returns in response to the id-swb-pkc-all-cert-paths. When the 825 request includes an id-swb-pkc-all-cert-paths wantBack, the response 826 SHOULD NOT include a serverContextInfo. 828 For attribute certificates, the following wantBacks are defined in 829 this document: 831 - id-swb-ac-cert: The attribute certificate that was the subject of 832 the request; 834 - id-swb-aa-cert-path: The certification path built for the AC 835 issuer certificate; 837 - id-swb-ac-revocation-info: Proof of revocation status for each 838 certificate in the AC issuer certification path; and 840 - id-swb-aa-revocation-info: Proof of revocation status for the 841 attribute certificate. 843 Conforming SCVP server implementations MAY support the attribute 844 certificate wantBacks. 846 The following wantBack can be used for either public key or attribute 847 certificates: 849 - id-swb-relayed-responses: Any SCVP responses received by the 850 server that were used to generate the response to this query. 852 Conforming SCVP servers MAY support the id-swb-relayed-responses 853 wantBack. 855 For these purposes, the following OIDs are defined: 857 id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 858 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 } 860 id-swb-pkc-best-cert-path OBJECT IDENTIFIER ::= { id-swb 1 } 861 id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 } 862 id-swb-pkc-public-key-info OBJECT IDENTIFIER ::= { id-swb 4 } 863 id-swb-aa-cert-path OBJECT IDENTIFIER ::= { id-swb 5 } 864 id-swb-aa-revocation-info OBJECT IDENTIFIER ::= { id-swb 6 } 865 id-swb-ac-revocation-info OBJECT IDENTIFIER ::= { id-swb 7 } 866 id-swb-relayed-responses OBJECT IDENTIFIER ::= { id-swb 9 } 867 id-swb-pkc-cert OBJECT IDENTIFIER ::= { id-swb 10} 868 id-swb-ac-cert OBJECT IDENTIFIER ::= { id-swb 11} 869 id-swb-pkc-all-cert-paths OBJECT IDENTIFIER ::= { id-swb 12} 870 id-swb-pkc-ee-revocation-info OBJECT IDENTIFIER ::= { id-swb 13} 871 id-swb-pkc-CAs-revocation-info OBJECT IDENTIFIER ::= { id-swb 14} 873 Other specifications may define additional wantBacks. 875 Conforming client implementations that support delegated path 876 validation (DPV) as defined in [RQMTS] SHOULD support assertion of at 877 least one wantBack. Conforming client implementations that support 878 delegated path discovery (DPD) as defined in [RQMTS] MUST support 879 assertion of at least one wantBack. Conforming clients MAY support 880 assertion of multiple wantBacks. Conforming clients need not support 881 all of the wantBacks defined in this section. 883 3.2.4 validationPolicy 885 The validationPolicy item defines the validation policy that the 886 client wants the SCVP server to use during certificate validation. 887 If this policy cannot be used for any reason, then the server MUST 888 return an error response. 890 A validation policy MUST define default values for all parameters 891 necessary for processing an SCVP request. For each parameter, a 892 validation policy may either allow the client to specify a non- 893 default value or forbid the use of a non-default value. If the 894 client wishes to use the default values for all of the parameters, 895 then the client need only supply a reference to the policy in this 896 item. If the client wishes to use non-default values for one or more 897 parameters, then the client supplies a reference to the policy plus 898 whatever parameters are necessary to complete the request in this 899 item. If there are any conflicts between the policy referenced in 900 the request and any supplied parameter values in the request, then 901 the server MUST return an error response. 903 The syntax of the validationPolicy item is: 905 ValidationPolicy ::= SEQUENCE { 906 validationPolRef ValidationPolRef, 907 validationAlg [0] ValidationAlg OPTIONAL, 908 userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT 909 IDENTIFIER OPTIONAL, 910 inhibitPolicyMapping [2] BOOLEAN OPTIONAL, 911 requireExplicitPolicy [3] BOOLEAN OPTIONAL, 912 inhibitAnyPolicy [4] BOOLEAN OPTIONAL, 913 trustAnchors [5] TrustAnchors OPTIONAL, 914 keyUsages [6] SEQUENCE OF KeyUsage OPTIONAL, 915 extendedKeyUsages [7] SEQUENCE OF KeyPurposeId OPTIONAL, 916 specifiedKeyUsages [8] SEQUENCE OF KeyPurposeId OPTIONAL } 918 The validationPolRef item is required, but the remaining items are 919 optional. The optional items are used to provide validation policy 920 parameters. When the client uses the validation policy's default 921 values for all parameters, all of the optional items are absent. 923 At a minimum, conforming SCVP client implementations MUST support the 924 ValidationPolRef item. Conforming client implementations MAY support 925 any or all of the optional items in ValidationPolicy. 927 Conforming SCVP servers MUST support processing of a ValidationPolicy 928 that contains any or all of the optional items. 930 The validationAlg item specifies the validation algorithm. The 931 userPolicySet item provides an acceptable set of certificate 932 policies. The inhibitPolicyMapping item inhibits certificate policy 933 mapping during certification path validation. The 934 requireExplicitPolicy item requires at least one valid certificate 935 policy in the certificate policies extension. The inhibitAnyPolicy 936 item indicates whether the anyPolicy certificate policy OID is 937 processed or ignored when evaluating certificate policy. The 938 trustAnchors item indicates the trust anchors that are acceptable to 939 the client. The keyUsages item indicates the technical usage of the 940 public key that is to be confirmed by the server as acceptable. The 941 extendedKeyUsages item indicates the application-specific usage of 942 the public key that is to be confirmed by the server as acceptable. 943 The syntax and semantics of each of these items is discussed in the 944 following sections. 946 3.2.4.1 validationPolRef 948 The reference to the validation policy is an OID that the client and 949 server have agreed represents a particular validation policy. 951 The syntax of the ValidationPolRef item is: 953 ValidationPolRef::= SEQUENCE { 954 valPolId OBJECT IDENTIFIER, 955 valPolParams ANY DEFINED BY valPolId OPTIONAL } 957 Where a validation policy supports additional policy-specific 958 parameter settings, these values are specified using the 959 valPolParams item. The syntax and semantics of the parameters 960 structure is defined by the object identifier encoded as the 961 valPolId. Where a validation policy has no parameters, such as the 962 default validation policy (see 3.2.4.1.1), this item MUST be 963 omitted. 965 Parameters specified in this item are independent of the validation 966 algorithm and the validation algorithm's parameters (see Section 967 3.2.4.2). For example, a server may support a validation policy 968 where it validates a certificate using the name validation algorithm 969 and also makes a determination regarding the creditworthiness of the 970 subject. In this case, the validation policy parameters could be 971 used to specify the value of the transaction. The validation 972 algorithm parameters are used to specify the application identifier 973 and name for the name validation algorithm. 975 Conforming SCVP client implementations MUST support specification of 976 a validation policy. Conforming SCVP client implementations MAY be 977 able to specify parameters for a validation policy. Conforming SCVP 978 server implementations MUST be able to process valPolId and MAY be 979 able to process valPolParams. 981 3.2.4.1.1 Default Validation Policy 983 The client can request the SCVP server's default validation policy 984 or another validation policy. The default validation policy 985 corresponds to standard certification path processing as defined in 986 [PKIX-1] with server chosen default values (e.g., with a server 987 determined policy set and trust anchors). The default values can be 988 distributed out of band or using the policy request mechanism (see 989 Section 5). This mechanism permits the deployment of an SCVP server 990 without obtaining a new object identifier. 992 The object identifier that identifies the default validation policy 993 is: 995 id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 996 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 } 998 id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 } 1000 The default validation policy MUST use the basic validation 1001 algorithm as its default validation algorithm (see section 1002 3.2.4.2.1), and has no validation policy parameters (see section 1003 3.2.4.1). 1005 When using the default validation policy, the client can override 1006 any of the default parameter values by supplying a specific value in 1007 the request. The SCVP server MUST make use of the provided 1008 parameter values or return an error response. 1010 Conforming implementations of SCVP servers MUST support the default 1011 policy. However, an SCVP server may be configured to send an error 1012 response to all requests using the default policy to meet local 1013 security requirements. 1015 3.2.4.2 validationAlg 1017 The optional validationAlg item defines the validation algorithm to 1018 be used by the SCVP server during certificate validation. The value 1019 of this item can be determined by agreement between the client and 1020 the server. The validation algorithm is represented by an object 1021 identifier. 1023 The syntax of the validationAlg is: 1025 ValidationAlg ::= SEQUENCE { 1026 valAlgId OBJECT IDENTIFIER, 1027 parameters ANY DEFINED BY valAlgId OPTIONAL } 1029 The following section specifies the basic validation algorithm and 1030 the name validation algorithm. 1032 SCVP servers MUST recognize and support both validation algorithms 1033 defined in this section. SCVP clients that support explicit 1034 assertion of the validation algorithm MUST support the basic 1035 validation algorithm and SHOULD support the name validation 1036 algorithm. Other validation algorithms can be specified in other 1037 documents for use with specific applications. SCVP clients and 1038 servers MAY support any such validation algorithms. 1040 3.2.4.2.1 Basic Validation Algorithm 1042 The client can request use of the SCVP basic validation algorithm or 1043 another algorithm. For identity certificates, the basic validation 1044 algorithm MUST implement the certification path validation algorithm 1045 as defined in section 6 of [PKIX-1]. For attribute certificates, 1046 the basic validation algorithm MUST implement certification path 1047 validation as defined in section 5 of [PKIX-AC]. Other validation 1048 algorithms MAY implement functions over and above those in the basic 1049 algorithm, but validation algorithms MUST generate results compliant 1050 with the basic validation algorithm. That is, none of the 1051 validation requirements in the basic algorithm may be omitted from 1052 any newly defined validation algorithms. However, other validation 1053 algorithms MAY reject paths that are valid using the basic 1054 validation algorithm. The object identifier to identify the basic 1055 validation algorithm is: 1057 id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 } 1059 When id-svp-basicValAlg appears in valAlgId, the parameters item MUST 1060 be absent. 1062 3.2.4.2.2 Basic Validation Algorithm Errors 1064 The following errors are defined for the basic validation algorithm 1065 for inclusion in the validationErrors item in the response (see 1066 section 4.9.6). These errors can be used by any other validation 1067 algorithm since all validation algorithms MUST implement the 1068 functionality of the basic validation algorithm. 1070 id-bvae OBJECT IDENTIFIER ::= id-svp-basicValAlg 1072 id-bvae-expired OBJECT IDENTIFIER ::= { id-bvae 1 } 1073 id-bvae-not-yet-valid OBJECT IDENTIFIER ::= { id-bvae 2 } 1074 id-bvae-wrongTrustAnchor OBJECT IDENTIFIER ::= { id-bvae 3 } 1075 id-bvae-noValidCertPath OBJECT IDENTIFIER ::= { id-bvae 4 } 1076 id-bvae-revoked OBJECT IDENTIFIER ::= { id-bvae 5 } 1077 id-bvae-invalidKeyPurpose OBJECT IDENTIFIER ::= { id-bvae 9 } 1078 id-bvae-invalidKeyUsage OBJECT IDENTIFIER ::= { id-bvae 10 } 1079 id-bvae-invalidCertPolicy OBJECT IDENTIFIER ::= { id-bvae 11 } 1081 The id-bvae-expired value means that the validation time used for the 1082 request was later than the notAfter time in the end certificate (the 1083 certificate specified in the queriedCerts item). 1085 The id-bvae-not-yet-valid value means that the validation time used 1086 for the request was before the notBefore time in the end certificate. 1088 The id-bvae-wrongTrustAnchor value means that a certification path 1089 could not be constructed for the client specified trust anchor(s), 1090 but a path exists for one of the trust anchors specified in the 1091 server's default validation policy. 1093 The id-bvae-noValidCertPath value means that the server could not 1094 construct a sequence of intermediate certificates between the trust 1095 anchor and the target certificate that satisfied the request. 1097 The id-bvae-revoked value means that the end certificate has been 1098 revoked. 1100 The id-bvae-invalidKeyUsage value means that the keyUsage extension 1101 (PKIX-1 section 4.2.1.3) in the end certificate does not satisfy the 1102 validation policy. For example, the keyUsage extension in the 1103 certificate may assert only the keyEncipherment bit, but the 1104 validation policy specifies in the keyUsages item that 1105 digitalSignature is required. 1107 The id-bvae-invalidCertPolicy value means that the path is not valid 1108 under any of the policies specified in the user policy set and 1109 explicit policies are required. That is, the valid_policy_tree is 1110 NULL and the explicit_policy variable is zero (PKIX-1 section 6.1.5). 1112 The id-bvae-invalidKeyPurpose value means that the extended key usage 1113 extension (PKIX-1 section 4.2.1.13) in the end certificate does not 1114 satisfy the validation policy. 1116 3.2.4.2.3 Name Validation Algorithm 1118 The name validation algorithm allows the client to specify one or 1119 more subject names that MUST appear in the end certificate in 1120 addition to the requirements specified for the basic validation 1121 algorithm. The name validation algorithm allows the client to supply 1122 an application identifier and a name to the server. The application 1123 identifier defines the name matching rules to use in comparing the 1124 name supplied in the request with the names in the certificate. 1126 id-svp-nameValAlg OBJECT IDENTIFIER ::= { id-svp 2 } 1128 When the id-svp-nameValAlg appears as a valAlgId, the parameters MUST 1129 use the NameValidationAlgParms syntax: 1131 NameValidationAlgParms ::= SEQUENCE { 1132 nameCompAlgId OBJECT IDENTIFIER, 1133 validationNames GeneralNames } 1135 GeneralNames is defined in [PKIX-1]. 1137 If more than one name is supplied in the validationNames value, all 1138 names MUST be of the same type. The certificate must contain a 1139 matching name for each of the names supplied in validationNames 1140 according to the name matching rules associated with the 1141 nameCompAlgId. This specification defines three sets of name 1142 matching rules. 1144 If the nameCompAlgId supplied in the request is id-nva-dnCompAlg, 1145 then GeneralNames supplied in the request MUST be a directoryName, 1146 and the matching rules to be used are defined in [PKIX-1]. The 1147 certificate must contain a matching name in either the subject field 1148 or a directoryName in the subjectAltName extension. This 1149 specification defines the OID for id-nva-dnCompAlg as follows: 1151 id-nva-dnCompAlg OBJECT IDENTIFIER ::= { id-svp 4 } 1153 If the nameCompAlgId supplied in the request is id-kp-serverAuth 1154 [PKIX-1], then GeneralNames supplied in the request MUST be a 1155 dNSName, and the matching rules to be used are defined in [PKIX-1]. 1157 If a subjectAltName extension is present and includes one or more 1158 names of type dNSName, a match in any one of the set is considered 1159 acceptable. If the subjectAltName extension is omitted, or does not 1160 include any names of type dNSName, the (most specific) Common Name 1161 field in the Subject field of the certificate MUST be used. 1163 Names may contain the wildcard character * which is considered to 1164 match any single domain name component. That is, *.a.com matches 1165 foo.a.com but not bar.foo.a.com. 1167 If the nameCompAlgId supplied in the request is id-kp-mailProtection 1168 [PKIX-1], then GeneralNames supplied in the request MUST be an 1169 rfc822Name, and the matching rules are defined in [SMIME-CERT]. 1171 Conforming SCVP servers MUST support the name validation algorithm 1172 and the matching rules associated with id-nva-dnCompAlg, id-kp- 1173 serverAuth, id-kp-mailProtection. SCVP server MAY support other name 1174 matching rules. 1176 3.2.4.2.4 Name Validation Algorithm Errors 1178 The following errors are defined for the Name Validation Algorithm: 1180 id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg 1182 id-nvae-name-mismatch OBJECT IDENTIFIER ::= { id-nvae 1 } 1183 id-nvae-no-name OBJECT IDENTIFIER ::= { id-nvae 2 } 1184 id-nvae-unknown-alg OBJECT IDENTIFIER ::= { id-nvae 3 } 1185 id-nvae-bad-name OBJECT IDENTIFIER ::= { id-nvae 4 } 1186 id-nvae-bad-name-type OBJECT IDENTIFIER ::= { id-nvae 5 } 1187 id-nvae-mixed-names OBJECT IDENTIFIER ::= { id-nvae 6 } 1189 The id-nvae-name-mismatch value means the client supplied a name with 1190 the request, which the server recognized and the server found a 1191 corresponding name type in the certificate, but was unable to find a 1192 match to the name supplied. For example, the client supplied a DNS 1193 name of example1.com, the certificate contained a DNS name of 1194 example.com. 1196 The id-nvae-no-name value means the client supplied a name with the 1197 request, which the server recognized, but the server could not find 1198 the corresponding name type in the certificate. For example, the 1199 client supplied a DNS name of example1.com, the certificate only 1200 contained a rfc822Name of user@example.com. 1202 The id-nvae-unknown-alg value means the client supplied a 1203 nameCompAlgId which the server does not recognize. 1205 The id-nvae-bad-name value means the client supplied either an empty 1206 or malformed name in the request. 1208 The id-nvae-bad-name-type value means the client supplied an 1209 inappropriate name type for the application identifier. For example, 1210 the client specified a nameCompAlgId of id-kp-serverAuth, and an 1211 rfc822Name of user@example.com. 1213 The id-nvae-mixed-names value means the client supplied multiple 1214 names in the request of different types. 1216 3.2.4.3 userPolicySet 1218 The userPolicySet item specifies a list of certificate policy 1219 identifiers that the SCVP server MUST use when constructing and 1220 validating a certification path. The userPolicySet item specifies 1221 the user-initial-policy-set as defined in Section 6 of [PKIX-1]. A 1222 userPolicySet containing the anyPolicy OID indicates a user-initial- 1223 policy-set of any-policy. 1225 SCVP clients SHOULD support userPolicySet item in requests, and SCVP 1226 servers MUST support userPolicySet item in requests. 1228 3.2.4.4 inhibitPolicyMapping 1230 The inhibitPolicyMapping item specifies an input to the certification 1231 path validation algorithm, and it controls whether policy mapping is 1232 allowed during certification path validation (see [PKIX-1], section 1233 6.1.1). If the client wants the server to inhibit policy mapping, 1234 inhibitPolicyMapping is set to TRUE in the request. 1236 SCVP clients MAY support inhibiting policy mapping. SCVP servers 1237 SHOULD support inhibiting policy mapping. 1239 3.2.4.5 requireExplicitPolicy 1241 The requireExplicitPolicy item specifies an input to the 1242 certification path validation algorithm, and it controls whether 1243 there must be at least one valid policy in the certificate policies 1244 extension (see [PKIX-1], section 6.1.1). If the client wants the 1245 server to require at least one policy, requireExplicitPolicy is set 1246 to TRUE in the request. 1248 SCVP clients MAY support requiring explicit policies. SCVP servers 1249 SHOULD support requiring explicit policies. 1251 3.2.4.6 inhibitAnyPolicy 1253 The inhibitAnyPolicy item specifies an input to the certification 1254 path validation algorithm (see [PKIX-1], section 6.1.1), and it 1255 controls whether the anyPolicy OID is processed or ignored when 1256 evaluating certificate policy. If the client wants the server to 1257 ignore the anyPolicy OID, inhibitAnyPolicy MUST be set to TRUE in the 1258 request. 1260 SCVP clients MAY support ignoring the anyPolicy OID. SCVP servers 1261 SHOULD support ignoring the anyPolicy OID. 1263 3.2.4.7 trustAnchors 1265 The trustAnchors item specifies the trust anchors at which the 1266 certification path must terminate if the path is to be considered 1267 valid by the SCVP server for the request. If a trustAnchors item is 1268 present, the server MUST NOT consider any certification paths ending 1269 in other trust anchors as valid. 1271 The TrustAnchors type contains one or more trust anchor 1272 specifications. A certificate reference can be used to identify the 1273 trust anchor by certificate hash and distinguished name with serial 1274 number. Alternatively, trust anchors can be provided directly. The 1275 order of trust anchor specifications within the sequence is not 1276 important. Any CA certificate that meets the requirements of 1277 [PKIX-1] for signing certificates can be provided as a trust anchor. 1278 If a trust anchor is supplied that does not meet these requirements, 1279 the server MUST return an error response. 1281 The trust anchor itself, regardless of its form, MUST NOT be included 1282 in any certification path returned by the SCVP server. 1284 TrustAnchors has the following syntax: 1286 TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF PKCReference 1288 SCVP server MUST support trustAnchors. SCVP clients SHOULD support 1289 trustAnchors. 1291 3.2.4.8 keyUsages 1293 The key usage extension [PKIX-1, section 4.2.1.3] in the certificate 1294 defines the technical purpose (such as encipherment, signature, and 1295 CRL signing) of the key contained in the certificate. If the client 1296 wishes to confirm the technical usage, then it can communicate the 1297 usage it wants to validate by the same structure using the same 1298 semantics as defined in [PKIX-1]. For example, if the client 1299 obtained the certificate in the context of a digital signature, it 1300 can confirm this use by including a keyUsage structure with the 1301 digital signature bit set. 1303 If the keyUsages item is present and contains an empty sequence, it 1304 indicates that the client does not require any particular key usage. 1306 If the keyUsages item contains one or more keyUsage definitions, then 1307 the certificate MUST satisfy at least one of the specified keyUsage 1308 definitions. If the client is willing to accept multiple 1309 possibilities then the client passes in a sequence of possible 1310 patterns. Each keyUsage can contain a set of one or more bits set in 1311 the request, all bits MUST be set in the certificate to match against 1312 an instance of the keyUsage in the SCVP request. The certificate key 1313 usage extension may contain more usages than requested. For example, 1314 if a client wishes to check for either digital signature or non- 1315 repudiation, then the client provides two keyUsage values, one with 1316 digital signature set and the other with non-repudiation set. If the 1317 key usage extension is absent from the certificate, the certificate 1318 MUST be considered good for all usages and therefore any pattern in 1319 the SCVP request will match. 1321 SCVP clients SHOULD support keyUsages, and SCVP servers MUST support 1322 keyUsages. 1324 3.2.4.9 extendedKeyUsages 1326 The extended key usage extension [PKIX-1, section 4.2.1.13] defines 1327 more specific technical purposes, in addition to or in place of the 1328 purposes indicated in the key usage extension, for which the 1329 certified public key may be used. If the client will accept 1330 certificates that are consistent with a particular value (or values) 1331 in the extended key usage extension, then it can communicate the 1332 appropriate usages using the same semantics as defined in [PKIX-1]. 1333 For example, if the client obtained the certificate in the context of 1334 a TLS server, it can confirm the certificate is consistent with this 1335 usage by including the extended key usage structure with the id-kp- 1336 serverAuth object identifier. 1338 If the extension is absent or is present and asserts the 1339 anyExtendedKeyUsage OID, then all usages specified in the request are 1340 a match. If the extension is present and does not assert the 1341 anyExtendedKeyUsage OID, all usages in the request MUST be present in 1342 the certificate. The certificate extension may contain more usages 1343 than requested. 1345 Where the client does not require any particular extended key usage, 1346 the client can specify an empty SEQUENCE. This may be used to 1347 override extended key usage requirements imposed in the validation 1348 policy specified by valPolId. 1350 SCVP clients SHOULD support extendedKeyUsages, and SCVP servers MUST 1351 support extendedKeyUsages. 1353 3.2.4.10 specifiedKeyUsages 1355 The extended key usage extension [PKIX-1, section 4.2.1.13] defines 1356 more specific technical purposes, in addition to or in place of the 1357 purposes indicated in the key usage extension, for which the 1358 certified public key may be used. If the client requires that a 1359 particular value (or values) appear in the extended key usage 1360 extension, then it can specify the required usage(s) using the same 1361 semantics as defined in [PKIX-1]. For example, if the client 1362 obtained the certificate in the context of a TLS server, it might 1363 require that the server certificate include the extended key usage 1364 structure with the id-kp-serverAuth object identifier. In this case, 1365 the client would include specified key usages item in the request and 1366 assert the id-kp-serverAuth object identifier. 1368 If one or more specified usages are included in the request, the 1369 certificate MUST contain the extended key usage extension, and all 1370 usages specified in the request MUST be present in the certificate 1371 extension. The certificate extension may contain more usages than 1372 specified in the request. Specified key usages are not satisfied by 1373 the presence of the anyExtendedKeyUsage OID. 1375 Where the client does not require any particular extended key usage, 1376 the client can specify an empty SEQUENCE. This may be used to 1377 override specified key usage requirements imposed in the validation 1378 policy specified by valPolId. 1380 SCVP clients SHOULD support specifiedKeyUsages, and SCVP servers MUST 1381 support specifiedKeyUsages. 1383 3.2.5 responseFlags 1385 The optional response flags item allows the client to indicate which 1386 optional features in the CVResponse it wants the server to include. 1387 If the default values for all of the flags are used, then the 1388 response flags item MUST NOT be included in the request. 1390 The syntax of the responseFlags is: 1392 ResponseFlags ::= SEQUENCE { 1393 fullRequestInResponse [0] BOOLEAN DEFAULT FALSE, 1394 responseValidationPolByRef [1] BOOLEAN DEFAULT TRUE, 1395 protectResponse [2] BOOLEAN DEFAULT TRUE, 1396 cachedResponse [3] BOOLEAN DEFAULT TRUE } 1398 Each of the response flags is described in the following sections. 1400 3.2.5.1 fullRequestInResponse 1402 By default, the server includes a hash of the request in non-cached 1403 responses to allow the client to identify the response. If the 1404 client wants the server to include the full request in the non-cached 1405 response, fullRequestInResponse is set to TRUE. The main 1406 reason a client would request the server to include the full request 1407 in the response is to archive the request-response exchange in a 1408 single object. That is, the client wants to archive a single object 1409 that includes both request and response. 1411 SCVP clients and servers MUST support the default behavior. SCVP 1412 clients MAY support requesting and processing the full request. 1413 SCVP servers SHOULD support returning the full request. 1415 3.2.5.2 responseValidationPolByRef 1417 The responseValidationPolByRef item controls whether the response 1418 includes just a reference to the policy or a reference to the policy 1419 plus all the parameters by value of the policy used to process the 1420 request. The response MUST contain a reference to the validation 1421 policy. If the client wants the validation policy parameters to be 1422 also included by value, then responseValidationPolByRef is set to 1423 FALSE. The main reason a client would request the server to include 1424 validation policy to be included by value is to archive the request- 1425 response exchange in a single object. That is, the client wants to 1426 archive the CVResponse and have it include every aspect of the 1427 validation policy. 1429 SCVP clients MUST support requesting and processing the validation 1430 policy by reference and SCVP servers MUST support returning the 1431 validation policy by reference. SCVP 1432 clients MAY support requesting and processing the validation policy 1433 by values. SVCP server SHOULD support returning the validation 1434 policy by values. 1436 3.2.5.3 protectResponse 1438 The protectResponse item indicates whether the client requires the 1439 server to protect the response. If the client is performing full 1440 certification path validation on the response and it is not 1441 concerned about the source of the response, then the client does not 1442 benefit from a digital signature or MAC on the response. In this 1443 case, the client can indicate to the server that protecting the 1444 message is unnecessary. However, the server is always permitted to 1445 return a protected response. 1447 SCVP clients that support delegated path discovery (DPD) as defined 1448 in [RQMTS] MUST support setting this value to FALSE. 1450 SCVP clients that support delegated path validation (DPV) as defined 1451 in [RQMTS] require an authenticated response. Unless a protected 1452 transport mechanism (such a TLS) is used, such clients MUST always 1453 set this value to TRUE or omit the responseFlags item entirely, 1454 which requires the server to return a protected response. 1456 SCVP servers MUST support returning protected responses, and SCVP 1457 servers SHOULD support returning unprotected responses. Based on 1458 local policy, the server can be configured to return protected or 1459 unprotected responses if this value is set to FALSE. If based on 1460 local policy the server is unable to return protected responses, 1461 then the server MUST return an error if this value is set to TRUE. 1463 3.2.5.4 cachedResponse 1465 The cachedResponse item indicates whether the client will accept a 1466 cached response. To enhance performance and limit the exposure of 1467 signing keys, an SCVP service may be designed to cache responses 1468 until new revocation information is expected. Where cachedResponse 1469 is set to TRUE, the client will accept a previously cached response. 1471 Clients may insist on creation of a fresh response to protect 1472 against a replay attack and ensure information is up to date. Where 1473 cachedResponse is FALSE, the client will not accept a cached 1474 response. To ensure that a response is fresh, the client MUST also 1475 include the requestNonce as defined in Section 3.4. 1477 Servers MUST process the cachedResponse flag. Where cachedResponse 1478 is FALSE, servers that cannot produce fresh responses MUST reply 1479 with an error message. Servers MAY choose to provide fresh 1480 responses even where cachedResponse is set to TRUE. 1482 3.2.6 serverContextInfo 1484 The optional serverContextInfo item, if present, contains context 1485 from a previous request-response exchange with the same SCVP server. 1486 It allows the server to return more than one certification path for 1487 the same certificate to the client. For example, if a server 1488 constructs a particular certification path for a certificate, but 1489 the client finds it unacceptable, the client can then send the same 1490 query back to the server with the serverContextInfo from the first 1491 response, and the server will be able to provide a different 1492 certification path (if another one can be found). 1494 Contents of the serverContextInfo are opaque to the SCVP client. 1495 That is, the client only knows that it needs to return the value 1496 provided by the server with the subsequent request to get a 1497 different certification path. Note that the subsequent query needs 1498 to be identical to the previous query with the exception of the 1499 following: 1501 - requestNonce; 1503 - serverContextInfo; and 1505 - the client's digital signature or MAC on the request. 1507 SCVP clients MAY support serverContextInfo, and SCVP servers SHOULD 1508 support serverContextInfo. 1510 3.2.7 validationTime 1512 The optional validationTime item, if present, tells the date and 1513 time relative to which the SCVP client wants the server to perform 1514 the checks. If the validationTime is not present, the server MUST 1515 perform the validation using the date and time at which the server 1516 processes the request. If the validationTime is present, it MUST be 1517 encoded as GeneralizedTime. The validationTime provided MUST be a 1518 retrospective time since the server can only perform a validity 1519 check using the current time (default) or previous time. A server 1520 can ignore the validationTime provided in the request if the time is 1521 within the clock skew of the server's current time. 1523 The revocation status information is obtained with respect to the 1524 validation time. When specifying a validation time other than the 1525 current time, the validation time should not necessarily be 1526 identical to the time when the private key was used. The validation 1527 time specified by the client may be adjusted to compensate for: 1529 1) time for the end-entity to realize that its private key has 1530 been or could possibly be compromised, and/or 1532 2) time for the end-entity to report the key compromise, and/or 1534 3) time for the revocation authority to process the revocation 1535 request from the end-entity, and/or 1537 4) time for the revocation authority to update and distribute 1538 the revocation status information. 1540 GeneralizedTime values MUST be expressed in Universal Coordinated 1541 Time (UTC) (which is also known as Greenwich Mean Time and Zulu 1542 time) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), 1543 even when the number of seconds is zero. GeneralizedTime values 1544 MUST NOT include fractional seconds. 1546 The information in the corresponding CertReply item in the response 1547 MUST be formatted as if the server created the response at the time 1548 indicated in the validationTime. However, if the server does not 1549 have appropriate historical information, the server MUST return an 1550 error response. 1552 SCVP servers MUST apply a clock skew to the validation time to allow 1553 for minor time synchronization errors. The default value is 10 1554 minutes. If the server uses a value other than the default it MUST 1555 include the clock skew value in the validation policy response. 1557 SCVP clients MAY support validationTime other than the current time. 1558 SCVP servers MUST support using its current time, and SHOULD support 1559 the client setting the validationTime in the request. 1561 3.2.8 intermediateCerts 1563 The optional intermediateCerts item may help the SCVP server create 1564 valid certification paths. The intermediateCerts item, when 1565 present, provides certificates that the server MAY use when forming 1566 a certification path. When building certification paths, the server 1567 MAY use the certificates in the intermediateCerts item in addition 1568 to any other certificates that the server can access. When present, 1569 the intermediateCerts item MUST contain at least one certificate, 1570 and the intermediateCerts item MUST be structured as a CertBundle. 1571 The certificates in the intermediateCerts item MUST NOT be 1572 considered as valid by the server just because they are present in 1573 this item. 1575 The CertBundle type contains one or more certificates. The order of 1576 the entries in the bundle is not important. CertBundle has the 1577 following syntax: 1579 CertBundle ::= SEQUENCE SIZE (1..MAX) OF Certificate 1581 SCVP clients SHOULD support intermediateCerts, and SCVP servers MUST 1582 support intermediateCerts. 1584 3.2.9 revInfos 1586 The optional revInfos item specifies revocation information such as 1587 CRLs, delta CRLs [PKIX-1], and OCSP responses [OCSP] that the SCVP 1588 server MAY use when validating certification paths. The purpose of 1589 the revInfos item is to provide revocation information to which the 1590 server might not otherwise have access, such as an OCSP response that 1591 the client received along with the certificate. Note that the 1592 information in the revInfos item might not be used by the server. 1593 For example, the revocation information might be associated with 1594 certificates that the server does not use in the certification path 1595 that it constructs. 1597 Clients SHOULD be courteous to the SCVP server by separating CRLs and 1598 delta CRLs. However, since the two share a common syntax, SCVP 1599 servers SHOULD accept delta CRLs even if they are identified as 1600 regular CRLs by the SCVP client. 1602 CRLs, delta CRLs, and OCSP responses can be provided as revocation 1603 information. If needed, additional object identifiers can be 1604 assigned for additional revocation information types in the future. 1606 The revInfos item uses the RevocationInfos type, which has the 1607 following syntax: 1609 RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo 1611 RevocationInfo ::= CHOICE { 1612 crl [0] CertificateList, 1613 delta-crl [1] CertificateList, 1614 ocsp [2] OCSPResponse, 1615 other [3] OtherRevInfo } 1617 OtherRevInfo ::= SEQUENCE { 1618 riType OBJECT IDENTIFIER, 1619 riValue ANY DEFINED BY riType } 1621 3.2.10 producedAt 1623 The client MAY allow the server to use a cached SCVP response. When 1624 doing so, the client MAY use the producedAt item to express 1625 requirements on the freshness of the cached response. The producedAt 1626 item tells the earliest date and time at which an acceptable cached 1627 response could have been produced. The producedAt item represents 1628 the date and time in UTC, using the GeneralizedTime type. The value 1629 in the producedAt item is independent of the validation time. 1631 GeneralizedTime value MUST be expressed in UTC, as defined in section 1632 3.2.7. 1634 SCVP clients MAY support using producedAt values in the request. 1635 SCVP servers MAY support the producedAt values in the request. SCVP 1636 servers that support cached responses SHOULD support the producedAt 1637 value in requests. 1639 3.2.11 queryExtensions 1641 The optional queryExtensions item contains Extensions. If present, 1642 each extension in the sequence extends the query. This specification 1643 does not define any extensions; the facility is provided to allow 1644 future specifications to extend SCVP. The syntax for extensions is 1645 imported from [PKIX-1]. The queryExtensions item, when present, MUST 1646 contain a sequence of extension items, and each of the extensions 1647 MUST contain extnID, critical, and extnValue items. Each of these is 1648 described in the following sections. 1650 3.2.11.1 extnID 1652 The extnID item is an identifier for the extension. It contains the 1653 object identifier that names the extension. 1655 3.2.11.2 critical 1657 The critical item is a BOOLEAN. Each extension is designated as 1658 either critical (with a value of TRUE) or non-critical (with a value 1659 of FALSE). By default, the extension is non-critical. An SCVP 1660 server MUST reject the query if it encounters a critical extension 1661 that it does not recognize; however, a non-critical extension MAY be 1662 ignored if it is not recognized, but MUST be processed if it is 1663 recognized. 1665 3.2.11.3 extnValue 1667 The extnValue item is an octet string, which contains the extension 1668 value. An ASN.1 type is specified for each extension, identified by 1669 the associated extnID object identifier. 1671 3.3 requestorRef 1673 The optional requestorRef item contains a list of names identifying 1674 SCVP servers, and it is intended for use in environments where SCVP 1675 relay is employed. Although requestorRef is encoded as a SEQUENCE, 1676 no order is implied. The requestorRef item is used to detect looping 1677 in some configurations. The value and use of requestorRef is defined 1678 in section 7. 1680 Conforming SCVP clients MAY support specification of the requestorRef 1681 value. Conforming SCVP server implementations MUST process the 1682 requestorRef value if present. If the SCVP client includes a 1683 requestorRef value in the request, then the SCVP server MUST return 1684 the same value in a non-cached response. The SCVP server MAY omit 1685 the requestorRef value from cached SCVP responses. 1687 The requestorRef item MUST be a sequence of GeneralName. No 1688 provisions are made to ensure uniqueness of the requestorRef 1689 GeneralName values. 1691 3.4 requestNonce 1693 The optional requestNonce item contains a request identifier 1694 generated by the SCVP client. If the client includes a requestNonce 1695 value in the request, it is expressing a preference that the SCVP 1696 server SHOULD return a non-cached response. If the server returns a 1697 non-cached response it MUST include the value of requestNonce from 1698 the request in the response as the respNonce item; however, the 1699 server MAY return a cached response which MUST NOT have a respNonce. 1701 SCVP clients that insist on creation of a fresh response (e.g., to 1702 protect against a replay attack or ensure information is up to date) 1703 MUST support requestNonce. Conforming SCVP server implementations 1704 MUST process the requestNonce value if present. 1706 If the client includes a requestNonce and also sets the 1707 cachedResponse flag to FALSE as defined in section 3.2.5.4, the 1708 client is indicating that the SCVP server MUST return either a non- 1709 cached response including the respNonce or an error response. The 1710 client SHOULD include a requestNonce item in every request to prevent 1711 an attacker from acting as a man-in-the-middle by replaying old 1712 responses from the server. The requestNonce value SHOULD change with 1713 every request sent by the client. 1715 The client MUST NOT set the cachedResponse flag to FALSE without also 1716 including a requestNonce. A server receiving such a request SHOULD 1717 return an invalidRequest error response. 1719 The requestNonce item, if present, MUST be an octet string that was 1720 generated exclusively for this request. 1722 3.5 requestorName 1724 The optional requestorName item is used by the client to include an 1725 identifier in the request. The client MAY include this information 1726 for the DPV server to copy into the response. 1728 Conforming SCVP clients MAY support specification of this item in 1729 requests. SCVP servers MUST be able to process requests that include 1730 this item. 1732 3.6 responderName 1734 The optional responderName item is used by the client to indicate the 1735 identity of the SCVP server that the client expects to sign the SCVP 1736 response if the response is digitally signed. The responderName item 1737 SHOULD only be included if: 1739 1. the request is either unprotected or digitally signed (i.e., is 1740 not protected using a MAC); and 1741 2. the responseFlags item is either absent or present with the 1742 protectResponse set to TRUE. 1744 Conforming SCVP clients MAY support specification of this item in 1745 requests. SCVP servers MUST be able to process requests that include 1746 this item. SCVP servers that maintain a single private key for 1747 signing SCVP responses or that are unable to return digitally signed 1748 responses MAY ignore the value in this item. SCVP servers that 1749 maintain more than one private key for signing SCVP responses SHOULD 1750 either (a) digitally sign the response using a private key that 1751 corresponds to a certificate that includes the name specified in 1752 responderName in either subject field or subjectAltName extension or 1753 (b) return a error indicating that the server does not possess a 1754 certificate that asserts the specified name. 1756 3.7 requestExtensions 1758 The OPTIONAL requestExtensions item contains Extensions. If present, 1759 each Extension in the sequence extends the request. This 1760 specification does not define any extensions; the facility is 1761 provided to allow future specifications to extend SCVP. The syntax 1762 for Extensions is imported from [PKIX-1]. The requestExtensions 1763 item, when present, MUST contain a sequence of extension items, and 1764 each of extension MUST contain extnID, critical, and extnValue items. 1765 Each of these is described in the following sections. 1767 3.7.1 extnID 1769 The extnID item is an identifier for the extension. It contains the 1770 object identifier that names the extension. 1772 3.7.2 critical 1774 The critical item is a BOOLEAN. Each extension is designated as 1775 either critical (with a value of TRUE) or non-critical (with a value 1776 of FALSE). By default, the extension is non-critical. An SCVP 1777 server MUST reject the query if it encounters a critical extension it 1778 does not recognize. A non-critical extension MAY be ignored if it is 1779 not recognized, but MUST be processed if it is recognized. 1781 3.7.3 extnValue 1783 The extnValue item contains an octet string. Within the octet string 1784 is the extension value. An ASN.1 type is specified for each 1785 extension, identified by the associated extnID object identifier. 1787 3.8 signatureAlg 1789 The signatureAlg item contains an AlgorithmIdentifier indicating 1790 which algorithm the server should use to sign the response message. 1791 The signatureAlg item SHOULD only be included if: 1793 1. the request is either unprotected or digitally signed (i.e., is 1794 not protected using a MAC); and 1795 2. the responseFlags item is either absent or present with the 1796 protectResponse set to TRUE. 1798 If included, the signatureAlg item SHOULD specify one of the 1799 signature algorithms specified in the signatureGeneration item of the 1800 server's validation policy response message. 1802 SCVP servers MUST be able to process requests that include this item. 1803 If the server is returning a digitally signed response to this 1804 message, then: 1806 1. If the signatureAlg item is present and specifies an algorithm 1807 that is included in the signatureGeneration item of the server's 1808 validation policy response message, the server MUST sign the 1809 response using the signature algorithm specified in 1810 signatureAlg. 1812 2. Otherwise, if the signatureAlg item is absent or is present but 1813 specifies an algorithm that is not supported by the server, the 1814 server MUST sign the response using the server's default 1815 signature algorithm as specified in the signatureGeneration item 1816 of the server's validation policy response message. 1818 3.9 hashAlg 1820 The hashAlg item contains an OBJECT IDENTIFIER indicating which hash 1821 algorithm the server should use to compute the hash value for the 1822 requestHash item in the response. SCVP clients SHOULD NOT include 1823 this item if fullRequestInResponse is set to TRUE. If included, the 1824 hashAlg item SHOULD specify one of the hash algorithms specified in 1825 the hashAlgorithms item of the server's validation policy response 1826 message. 1828 SCVP servers MUST be able to process requests that include this item. 1829 If the server is returning a response to this message that includes a 1830 requestHash then: 1832 1. If the hashAlg item is present and specifies an algorithm that 1833 is included in the hashAlgorithms item of the server's 1834 validation policy response message, the server MUST use the 1835 algorithm specified in hashAlg to compute the requestHash. 1837 2. Otherwise, if the hashAlg item is absent or is present but 1838 specifies an algorithm that is not supported by the server, the 1839 server MUST compute the requestHash using the server's default 1840 hash algorithm as specified in the hashAlgorithms item of the 1841 server's validation policy response message. 1843 3.10 requestorText 1845 SCVP clients MAY use the requestor Text item to provide text for 1846 inclusion in the corresponding response. For example, this field may 1847 describe the nature or reason for the request. 1849 Conforming SCVP client implementations MAY support inclusion of this 1850 item in requests. Conforming SCVP Server implementations MUST accept 1851 requests that include this item. When generating non-cached 1852 responses, conforming SCVP Server implementations MUST copy the 1853 contents of this item into the requestorText item in the 1854 corresponding response (see Section 4.13). 1856 3.11 SCVP Request Authentication 1858 It is a matter of local policy what validation policy the server uses 1859 when authenticating requests. When authenticating protected SCVP 1860 requests, the SCVP servers SHOULD use the validation algorithm 1861 defined in section 6 of [PKIX-1]. 1863 If the certificate used to validate a SignedData validation request 1864 includes the key usage extension [PKIX-1, section 4.2.1.3], it MUST 1865 have either the digital signature bit set, the non-repudiation bit 1866 set, or both bits set. 1868 If the certificate used to validate an AuthenticatedData validation 1869 request includes the key usage extension, it MUST have the key 1870 agreement bit set. 1872 If the certificate used on a validation request contains the extended 1873 key usage extension [PKIX-1, section 4.2.1.13], the server SHALL 1874 verify that it contains the SCVP client OID, the anyExtendedKeyUsage 1875 OID, or another OID acceptable to the server. The SCVP client OID is 1876 defined as follows: 1878 id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1879 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } 1881 id-kp-scvpClient OBJECT IDENTIFIER ::= { id-kp 16 } 1883 If a protected request fails to meet the validation policy of the 1884 server, it MUST be treated as an unauthenticated request. 1886 4 Validation Response 1888 An SCVP server response to the client MUST be a single CVResponse 1889 item. When a CVResponse is encapsulated in a MIME body part, 1890 application/scvp-cv-response MUST be used. 1892 There are a number of forms of an SCVP response: 1894 1. A success response to a request that has protectResponse set to 1895 FALSE. These responses SHOULD NOT be protected by the server. 1897 2. The server MUST protect all other success responses. If the 1898 server is unable to return a protected success response due to 1899 local policy, then it MUST return an error response. 1901 3. An error response to a request made over a protected transport 1902 such as TLS. These responses SHOULD NOT be protected by the 1903 server. 1905 4. An error response to a request that has protectResponse set to 1906 FALSE. These responses SHOULD NOT be protected by the server. 1908 5. An error response to an authenticated request. The server SHOULD 1909 protect these responses. 1911 6. An error response to an AuthenticatedData request where MAC is 1912 valid. The server MUST protect these responses. 1914 7. All other error responses MUST NOT be protected by the server. 1916 Successful responses are made when the server has fully complied with 1917 the request. That is, the server was able to attempt to build a 1918 certification path using the referenced or supplied validation 1919 policy, and it was able to comply with all the requested parameters. 1920 If the server is unable to perform validations using the required 1921 validation policy or the request contains an unsupported option, then 1922 the server MUST return an error response. 1924 For protected requests and responses, SCVP servers MUST support 1925 SignedData and SHOULD support AuthenticatedData. It is a matter of 1926 local policy which types are used. Where a protected response is 1927 required, SCVP servers MUST use SignedData or AuthenticatedData, even 1928 if the transaction is performed using a protected transport (e.g., 1929 TLS). 1931 If the server is making a protected response to a protected request, 1932 then the server MUST use the same protection mechanism (SignedData or 1933 AuthenticatedData) as in the request. 1935 An overview of the structure used for an unprotected response is 1936 provided below. Many details are not shown, but the way that SCVP 1937 makes use of CMS is clearly illustrated. 1939 ContentInfo { 1940 contentType id-ct-scvp-certValResponse, 1941 -- (1.2.840.113549.1.9.16.1.11) 1942 content CVResponse } 1944 The protected response consists of a CVResponse encapsulated in 1945 either a SignedData or an AuthenticatedData, which is in turn 1946 encapsulated in a ContentInfo. That is, the EncapsulatedContentInfo 1947 field of either SignedData or AuthenticatedData consists of an 1948 eContentType field with a value of id-ct-scvp-certValResponse and an 1949 eContent field that contains a DER encoded CVResponse. 1951 The SCVP server MUST include its own certificate in the certificates 1952 field within SignedData. Other certificates MAY also be included. 1954 The SCVP server MAY also provide one or more CRLs in the crls field 1955 within SignedData. The signerInfos field of SignedData MUST include 1956 exactly one SignerInfo. The SignedData MUST NOT include the 1957 unsignedAttrs field. 1959 The signedAttrs field within SignerInfo MUST include the content-type 1960 and message-digest attributes defined in [CMS], and it SHOULD include 1961 the signing-certificate attribute as defined in [ESS]. Within the 1962 signing-certificate attribute, the first certificate identified in 1963 the sequence of certificate identifiers MUST be the certificate of 1964 the SCVP server. The inclusion of other certificate identifiers in 1965 the signing-certificate attribute is OPTIONAL. The inclusion of 1966 policies in the signing-certificate is OPTIONAL. 1968 The recipientInfos field of AuthenticatedData MUST include exactly 1969 one RecipientInfo, which contains information for the client that 1970 sent the request. The AuthenticatedData MUST NOT include the 1971 unauthAttrs field. 1973 The CVResponse item contains the server's response. The CVResponse 1974 MUST contain the cvResponseVersion, serverConfigurationID, 1975 producedAt, and responseStatus items. The CVResponse MAY also 1976 contain the respValidationPolicy, requestRef, requestorRef, 1977 requestorName, replyObjects, respNonce, serverContextInfo, and 1978 cvResponseExtensions items. The replyObjects item MUST contain 1979 exactly one CertReply item for each certificate requested. The 1980 requestorRef item MUST be included if the request included a 1981 requestorRef item and a non-cached response is provided. The 1982 respNonce item MUST be included if the request included a 1983 requestNonce item and a non-cached response is provided. 1985 The CVResponse MUST have the following syntax: 1987 CVResponse ::= SEQUENCE { 1988 cvResponseVersion INTEGER, 1989 serverConfigurationID INTEGER, 1990 producedAt GeneralizedTime, 1991 responseStatus ResponseStatus, 1992 respValidationPolicy [0] RespValidationPolicy OPTIONAL, 1993 requestRef [1] RequestReference OPTIONAL, 1994 requestorRef [2] GeneralNames OPTIONAL, 1995 requestorName [3] GeneralNames OPTIONAL, 1996 replyObjects [4] ReplyObjects OPTIONAL, 1997 respNonce [5] OCTET STRING OPTIONAL, 1998 serverContextInfo [6] OCTET STRING OPTIONAL, 1999 cvResponseExtensions [7] Extensions OPTIONAL, 2000 requestorText [8] UTF8String (SIZE (1..256)) OPTIONAL } 2002 Conforming SCVP servers MAY be capable of constructing a CVResponse 2003 that includes the serverContextInfo or cvResponseExtensions items. 2004 Conforming SCVP servers MUST be capable of constructing a CVResponse 2005 with any of the remaining optional items. Conforming SCVP clients 2006 MUST be capable of processing a CVResponse with the following 2007 optional items: respValidationPolicy; requestRef; requestorName; 2008 replyObjects; and respNonce. 2010 Conforming SCVP clients that are capable of including requestorRef in 2011 a request MUST be capable of processing a CVResponse that includes 2012 the requestorRef item. Conforming SCVP clients MUST be capable of 2013 processing a CVResponse that includes the serverContextInfo or 2014 cvResponseExtensions items. Conforming clients MUST be able to 2015 determine if critical extensions are present in the 2016 cvResponseExtensions item. 2018 4.1 cvResponseVersion 2020 The syntax and semantics of cvResponseVersion are the same as 2021 cvRequestVersion as described in section 3.1. The cvResponseVersion 2022 MUST match the cvRequestVersion in the request. If the server cannot 2023 generate a response with a matching version number, then the server 2024 MUST return an error response that indicates the highest version 2025 number that the server supports as the version number. 2027 4.2 serverConfigurationID 2029 The server configuration ID represents the version of the SCVP server 2030 configuration when it processed the request. See section 6.4 for 2031 details. 2033 4.3 producedAt 2035 The producedAt item tells the date and time at which the SCVP server 2036 generated the response. The producedAt item MUST be expressed in 2037 UTC, and it MUST be interpreted as defined in section 3.2.7. This 2038 value is independent of the validation time. 2040 4.4 responseStatus 2042 The responseStatus item gives status information to the SCVP client 2043 about its request. The responseStatus item has a numeric status code 2044 and an optional string that is a sequence of characters from the 2045 ISO/IEC 10646-1 character set encoded with the UTF-8 transformation 2046 format defined in [UTF8]. 2048 The string MAY be used to transmit status information. The client 2049 MAY choose to display the string to a human user. However, because 2050 there is often no way to know the languages understood by a human 2051 user, the string may be of little or no assistance. 2053 The responseStatus item uses the ResponseStatus type, which has the 2054 following syntax: 2056 ResponseStatus ::= SEQUENCE { 2057 statusCode CVStatusCode DEFAULT okay, 2058 errorMessage UTF8String OPTIONAL } 2060 CVStatusCode ::= ENUMERATED { 2061 okay (0), 2062 skipUnrecognizedItems (1), 2063 tooBusy (10), 2064 invalidRequest (11), 2065 internalError (12), 2066 badStructure (20), 2067 unsupportedVersion (21), 2068 abortUnrecognizedItems (22), 2069 unrecognizedSigKey (23), 2070 badSignatureOrMAC (24), 2071 unableToDecode (25), 2072 notAuthorized (26), 2073 unsupportedChecks (27), 2074 unsupportedWantBacks (28), 2075 unsupportedSignatureOrMAC (29), 2076 invalidSignatureOrMAC (30), 2077 protectedResponseUnsupported (31), 2078 unrecognizedResponderName (32), 2079 relayingLoop (40), 2080 unrecognizedValPol (50), 2081 unrecognizedValAlg (51), 2082 fullRequestInResponseUnsupported (52), 2083 fullPolResponseUnsupported (53), 2084 inhibitPolicyMappingUnsupported (54), 2085 requireExplicitPolicyUnsupported (55), 2086 inhibitAnyPolicyUnsupported (56), 2087 validationTimeUnsupported (57), 2088 unrecognizedCritQueryExt (63), 2089 unrecognizedCritRequestExt (64) } 2091 The CVStatusCode values have the following meaning: 2093 0 The request was fully processed. 2094 1 The request included some unrecognized non-critical extensions; 2095 however, processing was able to continue ignoring them. 2096 10 Too busy; try again later. 2097 11 The server was able to decode the request, but there was some 2098 other problem with the request. 2099 12 An internal server error occurred. 2100 20 The structure of the request was wrong. 2101 21 The version of request is not supported by this server. 2102 22 The request included unrecognized items, and the server was not 2103 able to continue processing. 2104 23 The server could not validate the key used to protect the 2105 request. 2106 24 The signature or message authentication code did not match the 2107 body of the request. 2108 25 The encoding was not understood. 2109 26 The request was not authorized. 2110 27 The request included unsupported checks items, and the server was 2111 not able to continue processing. 2112 28 The request included unsupported wantBack items, and the server 2113 was not able to continue processing. 2114 29 The server does not support the signature or message 2115 authentication code algorithm used by the client to protect the 2116 request. 2117 30 The server could not validate the client's signature or message 2118 authentication code on the request. 2119 31 The server could not generate a protected response as requested 2120 by the client. 2121 32 The server does not have a certificate matching the requested 2122 responder name. 2123 40 The request was previously relayed by the same server. 2124 50 The request contained an unrecognized validation policy 2125 reference. 2126 51 The request contained an unrecognized validation algorithm OID. 2127 52 The server does not support returning the full request in the 2128 response. 2129 53 The server does not support returning the full validation policy 2130 by value in the response. 2131 54 The server does not support the requested value for inhibit 2132 policy mapping. 2133 55 The server does not support the requested value for require 2134 explicit policy. 2135 56 The server does not support the requested value for inhibit 2136 anyPolicy. 2137 57 The server only validates requests using current time. 2138 63 The query item in the request contains a critical extension whose 2139 OID is not recognized. 2140 64 The request contains a critical request extension whose OID is 2141 not recognized. 2143 Status codes 0-9 are reserved for codes that indicate the request was 2144 processed by the server and therefore MUST be sent in a success 2145 response. Status codes 10 and above indicate an error and MUST 2146 therefore be sent in an error response. 2148 4.5 respValidationPolicy 2150 The respValidationPolicy item contains either a reference to the full 2151 validation policy or the full policy by value used by the server to 2152 validate the request. It MUST be present in success responses and 2153 MUST NOT be present in error responses. The choice between returning 2154 the policy by reference or by value is controlled by the 2155 responseValidationPolByRef item in the request. The resultant 2156 validation policy is the union of the following: 2158 1. Values from the request. 2160 2. For values that are not explicitly included in the request, 2161 values from the validation policy specified by reference in the 2162 request. 2164 The RespValidationPolicy syntax is: 2166 RespValidationPolicy ::= ValidationPolicy 2168 The validationPolicy item is defined in section 3.2.4. When 2169 responseValidationPolByRef is set to FALSE in the request, all items 2170 in the validationPolicy item MUST be populated. When 2171 responseValidationPolByRef is set to TRUE, OPTIONAL items in the 2172 validationPolicy item only need to be populated for items for which 2173 the value in the request differs from the value from the referenced 2174 validation policy. 2176 Conforming SCVP clients MUST be capable of processing the validation 2177 policy by reference. SCVP clients MAY be capable of processing the 2178 optional items in the validation policy. 2180 Conforming SCVP server implementations MUST be capable of asserting 2181 the policy by reference, and MUST be capable of including the 2182 optional items. 2184 4.6 requestRef 2186 The requestRef item allows the SCVP client to identify the request 2187 that corresponds to this response from the server. It associates the 2188 response to a particular request using either a hash of the request 2189 or a copy of CVRequest from the request. 2191 The requestRef item does not provide authentication, but does allow 2192 the client to determine that the request was not maliciously 2193 modified. 2195 The requestRef item allows the client to associate a response with a 2196 request. The requestNonce provides an alternative mechanism for 2197 matching requests and responses. When the fullRequest alternative is 2198 used, the response provides a single data structure that is suitable 2199 for archive of the transaction. 2201 The requestRef item uses the RequestReference type, which has the 2202 following syntax: 2204 RequestReference ::= CHOICE { 2205 requestHash [0] HashValue, -- hash of CVRequest 2206 fullRequest [1] CVRequest } 2208 SCVP clients MUST support requestHash, and they MAY support 2209 fullRequest. SCVP servers MUST support using requestHash, and they 2210 SHOULD support using fullRequest. 2212 4.6.1 requestHash 2214 The requestHash item is the hash of the CVRequest. The one-way hash 2215 function used to compute the hash of the CVRequest is as specified in 2216 section 3.9. The requestHash item serves two purposes. First, it 2217 allows a client to determine that the request was not maliciously 2218 modified. Second, it allows the client to associate a response with 2219 a request when using connectionless protocols. The requestNonce 2220 provides an alternative mechanism for matching requests and 2221 responses. 2223 The requestHash item uses the HashValue type, which has the following 2224 syntax: 2226 HashValue ::= SEQUENCE { 2227 algorithm AlgorithmIdentifier DEFAULT { algorithm sha-1 }, 2228 value OCTET STRING } 2230 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 2231 oiw(14) secsig(3) algorithm(2) 26 } 2233 The algorithm identifier for SHA-1 is imported from [PKIX-ALG]. It 2234 is repeated here for convenience. 2236 4.6.2 fullRequest 2238 Like requestHash, the fullRequest alternative allows a client to 2239 determine that the request was not maliciously modified. It also 2240 provides a single data structure that is suitable for archive of the 2241 transaction. 2243 The fullRequest item uses the CVRequest type. The syntax and 2244 semantics of the CVRequest type are described in section 3. 2246 4.7 requestorRef 2248 The optional requestorRef item is used by the client to identify the 2249 original requestor in cases where SCVP relay is used. The value is 2250 only of local significance to the client. If the SCVP client 2251 includes a requestorRef value in the request, then the SCVP server 2252 MUST return the same value if the server is generating a non-cached 2253 response. 2255 4.8 requestorName 2257 The optional requestorName item is used by the server to return one 2258 or more identities associated with the client in the response. 2260 The SCVP server MAY choose to include any or all of the following: 2262 (1) the identity asserted by the client in the requestorName item 2263 of the request, 2264 (2) an authenticated identity for the client from a certificate or 2265 other credential used to authenticate the request, or 2266 (3) a client identifier from an out-of-band mechanism. 2268 Alternatively, the SCVP server MAY omit this item. 2270 In the case of non-cached responses to authenticated requests, the 2271 SCVP server SHOULD return a requestor name. 2273 SCVP servers that support authenticated requests SHOULD support this 2274 item. 2276 SCVP clients MUST be able to process responses that include this 2277 item, although the item value might not impact the processing in any 2278 manner. 2280 4.9 replyObjects 2282 The replyObjects item returns requested objects to the SCVP client, 2283 each of which tells the client about a single certificate from the 2284 request. The replyObjects item MUST be present in the response, 2285 unless the response is reporting an error. The CertReply item MUST 2286 contain cert, replyStatus, replyValTime, replyChecks, and 2287 replyWantBacks items; and the CertReply item MAY contain the 2288 validationErrors, nextUpdate, and certReplyExtensions items. 2290 A success response MUST contain one CertReply for each certificate 2291 specified in the queriedCerts item in the request. The order is 2292 important. The first CertReply in the sequence MUST correspond to 2293 the first certificate in the request; the second CertReply in the 2294 sequence MUST correspond to the second certificate in the request; 2295 and so on. 2297 The checks item in the request determines the content of the 2298 replyChecks item in the response. The wantBack item in the request 2299 determines the content of the replyWantBacks item in the response. 2300 The queryExtensions items in the request controls the absence or the 2301 presence and content of the certReplyExtensions item in the response. 2303 The replyObjects item uses the ReplyObjects type, which has the 2304 following syntax: 2306 ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply 2308 CertReply ::= SEQUENCE { 2309 cert CertReference, 2310 replyStatus ReplyStatus DEFAULT success, 2311 replyValTime GeneralizedTime, 2312 replyChecks ReplyChecks, 2313 replyWantBacks ReplyWantBacks, 2314 validationErrors [0] SEQUENCE SIZE (1..MAX) OF 2315 OBJECT IDENTIFIER OPTIONAL, 2316 nextUpdate [1] GeneralizedTime OPTIONAL, 2317 certReplyExtensions [2] Extensions OPTIONAL } 2319 4.9.1 cert 2321 The cert item contains either the certificate or a reference to the 2322 certificate about which the client is requesting information. If the 2323 certificate was specified by reference in the request, the request 2324 included either the id-swb-pkc-cert or id-swb-aa-cert wantBack, and 2325 the server was able to obtain the referenced certificate then this 2326 item MUST include the certificate. Otherwise, this item MUST include 2327 the same value as was used in the queriedCerts item in the request. 2329 CertReference has the following syntax: 2331 CertReference ::= CHOICE { 2332 pkc PKCReference, 2333 ac ACReference } 2335 4.9.2 replyStatus 2337 The replyStatus item gives status information to the client about the 2338 request for the specific certificate. Note that the responseStatus 2339 item is different than the replyStatus item. The responseStatus item 2340 is the status of the whole request, while the replyStatus item is the 2341 status for the individual query item. 2343 The replyStatus item uses the ReplyStatus type, which has the 2344 following syntax: 2346 ReplyStatus ::= ENUMERATED { 2347 success (0), 2348 malformedPKC (1), 2349 malformedAC (2), 2350 unavailableValidationTime (3), 2351 referenceCertHashFail (4), 2352 certPathConstructFail (5), 2353 certPathNotValid (6), 2354 certPathNotValidNow (7), 2355 wantBackUnsatisfied (8) } 2357 The meaning of the various ReplyStatus values are: 2359 0 Success: all checks were performed successfully. 2360 1 Failure: the public key certificate was malformed. 2361 2 Failure: the attribute certificate was malformed. 2362 3 Failure: historical data for the requested validation time is not 2363 available. 2364 4 Failure: the server could not locate the reference certificate or 2365 the referenced certificate did not match the hash value provided. 2366 5 Failure: no certification path could be constructed. 2367 6 Failure: the constructed certification path is not valid with 2368 respect to the validation policy. 2369 7 Failure: the constructed certification path is not valid with 2370 respect to the validation policy, but a query at a later time may 2371 be successful. 2372 8 Failure: all checks were performed successfully, however one or 2373 more of the wantBacks could not be satisfied. 2375 Codes 1 and 2 are used to tell the client that the request was 2376 properly formed, but the certificate in question was not. This is 2377 especially useful to clients that do not parse certificates. 2379 Code 7 is used to tell the client that a valid certification path was 2380 found with the exception that a certificate in the path is on hold, 2381 current revocation information is unavailable, or the validation time 2382 precedes the notBefore time in one or more certificates in the path. 2384 For codes 1, 2, 3, and 4, the replyChecks and replyWantBacks items 2385 are not populated (i.e., they MUST be an empty sequence). For codes 2386 5, 6, 7, and 8 replyChecks MUST include an entry corresponding to 2387 each check in the request; the replyWantBacks item is not populated. 2389 4.9.3 replyValTime 2391 The replyValTime item tells the time at which the information in the 2392 CertReply was correct. The replyValTime item represents the date and 2393 time in UTC, using GeneralizedTime type. The encoding rules for 2394 GeneralizedTime in section 3.2.7 MUST be used. 2396 Within the request, the optional validationTime item tells the date 2397 and time relative to which the SCVP client wants the server to 2398 perform the checks. If the validationTime is not present, the server 2399 MUST respond as if the client provided the date and time at which the 2400 server processes the request. 2402 The information in the CertReply item MUST be formatted as if the 2403 server created this portion of the response at the time indicated in 2404 the validationTime item of the query. However, if the server does 2405 not have appropriate historical information, the server MAY either 2406 return an error or return information for a later time. 2408 4.9.4 replyChecks 2410 The replyChecks item contains the responses to the checks item in the 2411 query. The replyChecks item includes the object identifier (OID) 2412 from the query and an integer. The value of the integer indicates 2413 whether the requested check was successful. The OIDs in the checks 2414 item of the query are used to identify the corresponding replyChecks 2415 values. Each OID specified in the checks item in the request MUST be 2416 matched by an OID in the replyChecks item of the response. In the 2417 case of an error response, the server MAY include additional checks 2418 in the response to further explain the error. Clients MUST ignore 2419 any unrecognized ReplyCheck included in the response. 2421 The replyChecks item uses the ReplyChecks type, which has the 2422 following syntax: 2424 ReplyChecks ::= SEQUENCE OF ReplyCheck 2426 ReplyCheck ::= SEQUENCE { 2427 check OBJECT IDENTIFIER, 2428 status INTEGER DEFAULT 0 } 2430 The status value for public key certification path building to a 2431 trusted root, { id-stc 1 }, can be one of the following: 2433 0: Built a path 2434 1: Could not build a path 2436 The status value for public key certification path building to a 2437 trusted root along with simple validation processing, { id-stc 2 }, 2438 can be one of the following: 2440 0: Valid 2441 1: Not valid 2443 The status value for public key certification path building to a 2444 trusted root along with complete status checking, { id-stc 3 }, can 2445 be one of the following: 2447 0: Valid 2448 1: Not valid 2449 2: Revocation Off-line 2450 3: Revocation Unavailable 2451 4: No known source for revocation information 2453 Revocation off-line means that the server or distribution point for 2454 the revocation information was connected to successfully without a 2455 network error but either no data was returned or if data was returned 2456 it was stale. Revocation unavailable means that a network error was 2457 returned when an attempt was made to reach the server or distribution 2458 point. No known source for revocation information means that the 2459 server was able to build a valid certification path but was unable to 2460 locate a source for revocation information for one or more 2461 certificates in the path. 2463 The status value for AC issuer certification path building to a 2464 trusted root, { id-stc 4 }, can be one of the following: 2466 0: Built a path 2467 1: Could not build a path 2469 The status value for AC issuer certification path building to a 2470 trusted root along with simple validation processing, { id-stc 5 }, 2471 can be one of the following: 2473 0: Valid 2474 1: Not valid 2476 The status value for AC issuer certification path building to a 2477 trusted root along with complete status checking, { id-stc 6 }, can 2478 be one of the following: 2480 0: Valid 2481 1: Not Valid 2482 2: Revocation Off-line 2483 3: Revocation Unavailable 2484 4: No known source for revocation information 2486 The status value for revocation status checking of an AC as well as 2487 AC issuer certification path building to a trusted root along with 2488 complete status checking, { id-stc 7 }, can be one of the following: 2490 0: Valid 2491 1: Not Valid 2492 2: Revocation Off-line 2493 3: Revocation Unavailable 2494 4: No known source for revocation information 2496 4.9.5 replyWantBacks 2498 The replyWantBacks item contains the responses to the wantBack item 2499 in the request. The replyWantBacks item includes the object 2500 identifier (OID) from the wantBack item in the request and an octet 2501 string. Within the octet string is the requested value. The OIDs in 2502 the wantBack item in the request are used to identify the 2503 corresponding reply value. The OIDs in the replyWantBacks item MUST 2504 match the OIDs in the wantBack item in the request. For a non-error 2505 response, replyWantBacks MUST include exactly one ReplyWantBack for 2506 each wantBack specified in the request (excluding id-swb-pkc-cert and 2507 id-swb-ac-cert, where the requested information is included in the 2508 cert item). 2510 The replyWantBacks item uses the ReplyWantBacks type, which has the 2511 following syntax: 2513 ReplyWantBacks ::= SEQUENCE OF ReplyWantBack 2515 ReplyWantBack::= SEQUENCE { 2516 wb OBJECT IDENTIFIER, 2517 value OCTET STRING } 2519 The octet string value for the certification path used to verify the 2520 certificate in the request, { id-swb 1 }, contains the CertBundle 2521 type. The syntax and semantics of the CertBundle type are described 2522 in section 3.2.8. This CertBundle includes all the certificates in 2523 the path, starting with the end certificate and ending with the 2524 certificate issued by the trust anchor. 2526 The octet string value for the proof of revocation status, { id-swb 2 2527 }, contains the RevInfoWantBack type. The RevInfoWantBack type is a 2528 SEQUENCE of the RevocationInfos type and an optional CertBundle. The 2529 syntax and semantics of the RevocationInfos type are described in 2530 section 3.2.9. The CertBundle MUST be included if any certificates 2531 required to validate the revocation information were not returned in 2532 the id-swb-pkc-best-cert-path or id-swb-pkc-all-cert-paths wantBack. 2533 The CertBundle MUST include all such certificates but there are no 2534 ordering requirements. 2536 RevInfoWantBack ::= SEQUENCE { 2537 revocationInfo RevocationInfos, 2538 extraCerts CertBundle OPTIONAL } 2540 The octet string value for the public key information, { id-swb 4 }, 2541 contains the SubjectPublicKeyInfo type. The syntax and semantics of 2542 the SubjectPublicKeyInfo type are described in [PKIX-1]. 2544 The octet string value for the AC issuer certification path used to 2545 verify the certificate in the request, { id-swb 5 }, contains the 2546 CertBundle type. The syntax and semantics of the CertBundle type are 2547 described in section 3.2.8. This CertBundle includes all the 2548 certificates in the path, beginning with the AC issuer certificate 2549 and ending with the certificate issued by the trust anchor. 2551 The octet string value for the proof of revocation status of the AC 2552 issuer certification path, { id-swb 6 }, contains the RevInfoWantBack 2553 type. The RevInfoWantBack type is a SEQUENCE of the RevocationInfos 2554 type and an optional CertBundle. The syntax and semantics of the 2555 RevocationInfos type are described in section 3.2.9. The CertBundle 2556 MUST be included if any certificates required to validate the 2557 revocation information were not returned in the id-aa-cert-path 2558 wantBack. The CertBundle MUST include all such certificates but 2559 there are no ordering requirements. 2561 The octet string value for the proof of revocation status of the 2562 attribute certificate, { id-swb 7 }, contains the RevInfoWantBack 2563 type. The RevInfoWantBack type is a SEQUENCE of the RevocationInfos 2564 type and an optional CertBundle. The syntax and semantics of the 2565 RevocationInfos type are described in section 3.2.9. The CertBundle 2566 MUST be included if any certificates required to validate the 2567 revocation information were not returned in the id-swb-aa-cert-path 2568 wantBack. The CertBundle MUST include all such certificates but 2569 there are no ordering requirements. 2571 The octet string value for returning all paths, { id-swb 12 }, 2572 contains an ASN.1 type CertBundles, as defined below. The syntax and 2573 semantics of the CertBundle type are described in section 3.2.8. 2574 Each CertBundle includes all the certificates in one path, starting 2575 with the end certificate and ending with the certificate issued by 2576 the trust anchor. 2578 CertBundles ::= SEQUENCE SIZE (1..MAX) OF CertBundle 2580 The octet string value for relayed responses, { id-swb 9 }, contains 2581 an ASN.1 type SCVPResponses, as defined below. If the SCVP server 2582 used information obtained from other SCVP servers when generating 2583 this response, then SCVPResponses MUST include each of the SCVP 2584 responses received from those servers. If the SCVP server did not 2585 use information obtained from other SCVP servers when generating the 2586 response, then SCVPResponses MUST be an empty sequence. 2588 SCVPResponses ::= SEQUENCE OF ContentInfo 2590 The octet string value for the proof of revocation status of the 2591 path's target certificate, { id-swb-13 }, contains the 2592 RevInfoWantBack type. The RevInfoWantBack type is a SEQUENCE of the 2593 RevocationInfos type and an optional CertBundle. The syntax and 2594 semantics of the RevocationInfos type are described in section 3.2.9. 2595 The CertBundle MUST be included if any certificates required to 2596 validate the revocation information were not returned in the id-swb- 2597 pkc-best-cert-path or id-swb-pkc-all-cert-paths wantBack. The 2598 CertBundle MUST include all such certificates but there are no 2599 ordering requirements. 2601 The octet string value for the proof of revocation status of the 2602 intermediate certificates in the path, { id-swb 14 }, contains the 2603 RevInfoWantBack type. The RevInfoWantBack type is a SEQUENCE of the 2604 RevocationInfos type and an optional CertBundle. The syntax and 2605 semantics of the RevocationInfos type are described in section 3.2.9. 2606 The CertBundle MUST be included if any certificates required to 2607 validate the revocation information were not returned in the id-swb- 2608 pkc-best-cert-path or id-swb-pkc-all-cert-paths wantBack. The 2609 CertBundle MUST include all such certificates but there are no 2610 ordering requirements. 2612 4.9.6 validationErrors 2614 The validationErrors item MUST only be present in failure responses. 2615 If present, it MUST contain one or more OIDs representing the reason 2616 the validation failed (validation errors for the basic validation 2617 algorithm and name validation algorithm are defined in sections 2618 3.2.4.2.2 and 3.2.4.2.4). The validationErrors item SHOULD only be 2619 included when the replyStatus is 3, 5, 6, 7, or 8. SCVP servers are 2620 not required to specify all of the reasons that validation failed. 2621 SCVP clients MUST NOT assume that the OIDs included in 2622 validationErrors represent all of the validation errors for the 2623 certification path. 2625 4.9.7 nextUpdate 2627 The nextUpdate item tells the time at which the server expects a 2628 refresh of information regarding the validity of the certificate to 2629 become available. The nextUpdate item is especially interesting if 2630 the certificate revocation status information is not available or the 2631 certificate is suspended. The nextUpdate item represents the date 2632 and time in UTC, using the GeneralizedTime type. The encoding rules 2633 for GeneralizedTime in section 3.2.7 MUST be used. 2635 4.9.8 certReplyExtensions 2637 The certReplyExtensions contains the responses to the queryExtensions 2638 item in the request. The certReplyExtensions item uses the 2639 Extensions type defined in [PKIX-1]. The object identifiers (OIDs) 2640 in the queryExtensions item in the request are used to identify the 2641 corresponding reply values. The certReplyExtensions item, when 2642 present, contains a sequence of Extension items, each of which 2643 contains an extnID item, a critical item, and an extnValue item. 2645 The extnID item is an identifier for the extension. It contains the 2646 OID that names the extension, and it MUST match one of the OIDs in 2647 the queryExtensions item in the request. 2649 The critical item is a BOOLEAN, and it MUST be set to FALSE. 2651 The extnValue item contains an OCTET STRING. Within the OCTET STRING 2652 is the extension value. An ASN.1 type is specified for each 2653 extension, identified by the associated extnID object identifier. 2655 4.10 respNonce 2657 The respNonce item contains an identifier to bind the request to the 2658 response. 2660 If the client includes a requestNonce value in the request and the 2661 server is generating a specific non-cached response to the request 2662 then the server MUST return the same value in the response. 2664 If the server is using a cached response to the request then it MUST 2665 omit the respNonce item. 2667 If the server is returning a specific non-cached response to a 2668 request without a nonce, then the server MAY include a message 2669 specific nonce. For digitally signed messages, the server MAY use 2670 the value of the message-digest attribute in the signedAttrs within 2671 SignerInfo of the request as the value in the respNonce item. 2673 The requestNonce item uses the octet string type. 2675 Conforming client implementations MUST be able to process a response 2676 that includes this item. Conforming servers MUST support respNonce. 2678 4.11 serverContextInfo 2680 The serverContextInfo item in a response is a mechanism for the 2681 server to pass some opaque context information to the client. If the 2682 client does not like the certification path returned, it can make a 2683 new query and pass along this context information. 2685 Section 3.2.6 contains information about the client's usage of this 2686 item. 2688 The context information is opaque to the client, but it provides 2689 information to the server that ensures that a different certification 2690 path will be returned (if another one can be found). The context 2691 information could indicate state of the server or it could contain a 2692 sequence of hashes of certification paths that have already been 2693 returned to the client. The protocol does not dictate any structure 2694 or requirements for this item. However, implementers should review 2695 the Security Considerations section of this document before selecting 2696 a structure. 2698 Servers that are incapable of returning additional paths MUST NOT 2699 include the serverContextInfo item in the response. 2701 4.12 cvResponseExtensions 2703 If present, the cvResponseExtensions item contains a sequence of 2704 Extensions that extend the response. This specification does not 2705 define any extensions. The facility is provided to allow future 2706 specifications to extend SCVP. The syntax for Extensions is imported 2707 from [PKIX-1]. The cvResponseExtensions item, when present, contains 2708 a sequence of Extension items, each of which contains an extnID item, 2709 a critical item, and an extnValue item. 2711 The extnID item is an identifier for the extension. It contains the 2712 object identifier (OID) that names the extension. 2714 The critical item is a BOOLEAN. Each extension is designated as 2715 either critical (with a value of TRUE) or non-critical (with a value 2716 of FALSE). An SCVP client MUST reject the response if it encounters 2717 a critical extension it does not recognize; however, a non-critical 2718 extension MAY be ignored if it is not recognized. 2720 The extnValue item contains an OCTET STRING. Within the OCTET STRING 2721 is the extension value. An ASN.1 type is specified for each 2722 extension, identified by the associated extnID object identifier. 2724 4.13 requestorText 2726 The requestorText item contains a text field supplied by the client. 2728 If the client includes a requestorText value in the request and the 2729 server is generating a specific non-cached response to the request 2730 then the server MUST return the same value in the response. 2732 If the server is using a cached response to the request then it MUST 2733 omit the requestorText item. 2735 The requestNonce item uses the UTF8 string type. 2737 Conforming client implementations that support the requestorText item 2738 in requests (see Section 3.10) MUST be able to process a response 2739 that includes this item. Conforming servers MUST support 2740 requestorText in responses. 2742 4.14 SCVP Response Validation 2744 There are two mechanisms for validation of SCVP responses, one based 2745 on the client's knowledge of a specific SCVP server key and the other 2746 based on validation of the certificate corresponding to the private 2747 key used to protect the SCVP response. 2749 4.14.1 Simple Key Validation 2751 The simple key validation method is where the SCVP client has a local 2752 policy of one or more SCVP server keys that directly identify the set 2753 of valid SCVP servers. Mechanisms for storage of server keys or 2754 identifiers are a local matter. For example, a client could store 2755 cryptographic hashes of public keys used to verify SignedData 2756 responses. Alternatively, a client could store shared symmetric keys 2757 used to verify MACs in AuthenticatedData responses. 2759 Simple key validation MUST be used by SCVP clients that cannot 2760 validate PKIX-1 certificates and are therefore making delegated path 2761 validation requests to the SCVP server [RQMTS]. It is a matter of 2762 local policy with these clients whether to use SignedData or 2763 AuthenticatedData. Simple key validation MAY be used by other SCVP 2764 clients for other reasons. 2766 4.14.2 SCVP Server Certificate Validation 2768 It is a matter of local policy what validation policy the client uses 2769 when validating responses. When validating protected SCVP responses, 2770 SCVP clients SHOULD use the validation algorithm defined in section 6 2771 of [PKIX-1]. SCVP clients may impose additional limitations on the 2772 algorithm, such as limiting the number of certificates in the path or 2773 establishing initial name constraints, as specified in section 6.2 of 2774 [PKIX-1]. 2776 If the certificate used to sign the validation policy responses and 2777 SignedData validation responses contains the key usage extension 2778 [PKIX-1 section 4.2.1.3] it MUST have either the digital signature 2779 bit set, the non-repudiation bit set, or both bits set. 2781 If the certificate for AuthenticatedData validation responses 2782 contains the key usage extension it MUST have the key agreement bit 2783 set. 2785 If the certificate used on a validation policy response or a 2786 validation response contains the extended key usage extension [PKIX-1 2787 section 4.2.1.13] it MUST contain either the anyExtendedKeyUsage OID 2788 or the following OID: 2790 id-kp-scvpServer OBJECT IDENTIFIER ::= { id-kp 15 } 2792 5 Server Policy Request 2794 An SCVP client uses the ValPolRequest item to request information 2795 about an SCVP server's policies and configuration information, 2796 including the list of validation policies supported by the SCVP 2797 server. When a ValPolRequest is encapsulated in a MIME body part, it 2798 MUST be carried in an application/scvp-vp-request MIME body part. 2800 The request consists of a ValPolRequest encapsulated in a 2801 ContentInfo. The client does not sign the request. 2803 ContentInfo { 2804 contentType id-ct-scvp-valPolRequest, 2805 -- (1.2.840.113549.1.9.16.1.12) 2806 content ValPolRequest } 2808 The ValPolRequest type has the following syntax: 2810 ValPolRequest ::= SEQUENCE { 2811 vpRequestVersion INTEGER DEFAULT 1, 2812 requestNonce OCTET STRING } 2814 Conforming SCVP server implementations MUST recognize and process the 2815 server policy request. Conforming clients SHOULD support the server 2816 policy request. 2818 5.1 vpRequestVersion 2820 The syntax and semantics of vpRequestVersion are the same as 2821 cvRequestVersion as described in section 3.1. 2823 5.2 requestNonce 2825 The requestNonce item contains a request identifier generated by the 2826 SCVP client. If the server returns a specific response it MUST 2827 include the requestNonce from the request in the response, but the 2828 server MAY return a cached response which MUST NOT include a 2829 requestNonce. 2831 6 Validation Policy Response 2833 In response to a ValPolRequest, the SCVP server provides a 2834 ValPolResponse. The ValPolResponse may not be unique to any 2835 ValPolRequest, so may be reused by the server in response to multiple 2836 ValPolRequests. The ValPolResponse also has an indication of how 2837 frequently the ValPolResponse may be reissued. The server MUST sign 2838 the response using its digital signature certificate. When a 2839 ValPolResponse is encapsulated in a MIME body part, it MUST be 2840 carried in an application/scvp-vp-response MIME body part. 2842 The response consists of a ValPolResponse encapsulated in a 2843 SignedData, which is in turn encapsulated in a ContentInfo. That is, 2844 the EncapsulatedContentInfo field of SignedData consists of an 2845 eContentType field with a value of id-ct-scvp-valPolResponse 2846 (1.2.840.113549.1.9.16.1.13) and an eContent field that contains a 2847 DER encoded ValPolResponse. The SCVP server MUST include it's own 2848 certificate in the certificates field within SignedData and the 2849 signerInfos field of SignedData MUST include exactly one SignerInfo. 2850 The SignedData MUST NOT include the unsignedAttrs field. 2852 The ValPolResponse type has the following syntax: 2854 ValPolResponse ::= SEQUENCE { 2855 vpResponseVersion INTEGER, 2856 maxCVRequestVersion INTEGER, 2857 maxVPRequestVersion INTEGER, 2858 serverConfigurationID INTEGER, 2859 thisUpdate GeneralizedTime, 2860 nextUpdate GeneralizedTime OPTIONAL, 2861 supportedChecks CertChecks, 2862 supportedWantBacks WantBack, 2863 validationPolicies SEQUENCE OF OBJECT IDENTIFIER, 2864 validationAlgs SEQUENCE OF OBJECT IDENTIFIER, 2865 authPolicies SEQUENCE OF AuthPolicy, 2866 responseTypes ResponseTypes, 2867 defaultPolicyValues RespValidationPolicy, 2868 revocationInfoTypes RevocationInfoTypes, 2869 signatureGeneration SEQUENCE OF AlgorithmIdentifier, 2870 signatureVerification SEQUENCE OF AlgorithmIdentifier, 2871 hashAlgorithms SEQUENCE SIZE (1..MAX) OF 2872 OBJECT IDENTIFIER, 2873 serverPublicKeys SEQUENCE OF KeyAgreePublicKey 2874 OPTIONAL, 2875 clockSkew INTEGER DEFAULT 10, 2876 requestNonce OCTET STRING OPTIONAL } 2878 ResponseTypes ::= ENUMERATED { 2879 cached-only (0), 2880 non-cached-only (1), 2881 cached-and-non-cached (2) } 2883 RevocationInfoTypes ::= BIT STRING { 2884 fullCRLs (0), 2885 deltaCRLs (1), 2886 indirectCRLs (2), 2887 oCSPResponses (3) } 2889 SCVP clients that support validation policy requests MUST support 2890 validation policy responses. SCVP servers MUST support validation 2891 policy responses. 2893 SCVP servers MUST support cached policy responses and MAY support 2894 specific responses to policy requests. 2896 6.1 vpResponseVersion 2898 The syntax and semantics of the vpResponseVersion item are the same 2899 as cvRequestVersion as described in section 3.1. The 2900 vpResponseVersion used MUST be the same as the vpRequestVersion 2901 unless the client has used a value greater than the values the server 2902 supports. If the client submits a vpRequestVersion greater than the 2903 version supported by the server, the server MUST return a 2904 vpResponseVersion using the highest version number the server 2905 supports as the version number. 2907 6.2 maxCVRequestVersion 2909 The maxCVRequestVersion defines the maximum version number for CV 2910 requests that the server supports. 2912 6.3 maxVPRequestVersion 2914 The maxVPRequestVersion defines the maximum version number for VP 2915 requests that the server supports. 2917 6.4 serverConfigurationID 2919 An integer that uniquely represents the version of the server 2920 configuration as represented by the validationPolicies, 2921 validationAlgs, authPolicies, defaultPolicyValues, and clockSkew. If 2922 any of these values change, the server MUST create a new 2923 ValPolResponse with a new serverConfigurationID. If the 2924 configuration has not changed, then the server may reuse 2925 serverConfigurationID across multiple ValPolResponse messages. 2926 However if the server reverts to an earlier configuration, the server 2927 MUST NOT revert the configuration ID as well, but MUST select another 2928 unique value. 2930 6.5 thisUpdate 2932 This item indicates the signing date and time of this policy 2933 response. 2935 GeneralizedTime values MUST be expressed Greenwich Mean Time (Zulu) 2936 and interpreted as defined in section 3.2.7. 2938 6.6 nextUpdate and requestNonce 2940 These items are used to indicate whether policy responses are 2941 specific to policy requests. Where policy responses are cached, 2942 these items indicate when the information will be updated. The 2943 optional nextUpdate item indicates the time by which the next policy 2944 response will be published. The optional requestNonce item links the 2945 response to a specific request by returning the nonce provided in the 2946 request. 2948 If the nextUpdate item is omitted it indicates a non-cached response 2949 generated in response to a specific request (i.e., the ValPolResponse 2950 is bound to a specific request). If this item is omitted the 2951 requestNonce item MUST be present and MUST include the requestNonce 2952 value from the request. 2954 If the nextUpdate item is present it indicates a cached response that 2955 is not bound to a specific request. An SCVP server MUST periodically 2956 generate a new response as defined by the next update time, but MAY 2957 use the same ValPolResponse to respond to multiple requests. The 2958 requestNonce is omitted if the nextUpdate item is present. 2960 It is a matter of local server policy to return a cached or non- 2961 cached specific response. 2963 GeneralizedTime values in nextUpdate MUST be expressed Greenwich Mean 2964 Time (Zulu) as specified in section 3.2.7. 2966 6.7 supportedChecks 2968 The supportedChecks item contains a sequence of object identifiers 2969 representing the checks supported by the server. 2971 6.8 supportedWantBacks 2973 The supportedWantBacks item contains a sequence of object identifiers 2974 representing the wantBacks supported by the server. 2976 6.9 validationPolicies 2978 The validationPolicies item contains a sequence of object identifiers 2979 representing the validation policies supported by the server. It is 2980 a matter of local policy if the server wishes to process requests 2981 using the default validation policy, and if it does not, then it MUST 2982 NOT include the id-svp-defaultValPolicy in this list. 2984 6.10 validationAlgs 2986 The validationAlgs item contains a sequence of OIDs. Each OID 2987 identifies a validation algorithm supported by the server. 2989 6.11 authPolicies 2991 The authPolicies item contains a sequence of policy references for 2992 authenticating to the SCVP server. 2994 The reference to the authentication policy is an OID that the client 2995 and server have agreed represents an authentication policy. The list 2996 of policies is intended to document to the client if authentication 2997 is required for some requests and if so how. 2999 AuthPolicy ::= OBJECT IDENTIFIER 3001 6.12 responseTypes 3003 responseTypes allows the server to publish the range of response 3004 types it supports. Cached only means the server will only return 3005 cached responses to requests. Non-cached only means the server will 3006 return a specific response to the request, i.e., containing the 3007 requestor's nonce. Both means that the server supports both cached 3008 and non-cached response types and will return either a cached or non- 3009 cached response, depending on the request. 3011 6.13 revocationInfoTypes 3013 revocationInfoTypes allows the server to indicate the sources of 3014 revocation information that it is capable of processing. For each 3015 bit in the RevocationInfoTypes bit string, the server MUST set the 3016 bit to one if it is capable of processing the corresponding 3017 revocation information type and to zero if it can not. 3019 6.14 defaultPolicyValues 3021 This is the default validation policy used by the server. It 3022 contains a RespValidationPolicy, which is defined in section 4.5. 3023 All OPTIONAL items in the validationPolicy item MUST be populated. A 3024 server will use these default values when the request references the 3025 default validation policy and the client does not override the 3026 default values by supplying other values in the request. 3028 This allows the client to optimize the request by omitting parameters 3029 that match the server default values. 3031 6.15 signatureGeneration 3033 This sequence specifies the set of digital signature algorithms 3034 supported by an SCVP server for signing CVResponse messages. Each 3035 digital signature algorithm is specified as an AlgorithmIdentifier, 3036 using the encoding rules associated with the signatureAlgorithm field 3037 in a public key certificate [PKIX-1]. Supported algorithms are 3038 defined in [PKIX-ALG] and [PKIX-ALG2], but other signature algorithms 3039 may also be supported. 3041 By including an algorithm (e.g., RSA with SHA-1) in this list, the 3042 server states that it has a private key and corresponding certified 3043 public key for that asymmetric algorithm, and supports the specified 3044 hash algorithm. The list is ordered; the first digital signature 3045 algorithm is the server's default algorithm. The default algorithm 3046 will be used by the server to protect signed messages unless the 3047 client specifies another algorithm. 3049 For servers that do not have an on-line private key, and cannot sign 3050 CVResponse messages, the signatureGeneration item is encoded as an 3051 empty sequence. 3053 6.16 signatureVerification 3055 This sequence specifies the set of digital signature algorithms that 3056 can be verified by this SCVP server. Each digital signature 3057 algorithm is specified as an AlgorithmIdentifier, using the encoding 3058 rules associated with the signatureAlgorithm field in a public key 3059 certificate [PKIX-1]. Supported algorithms are defined in [PKIX-ALG] 3060 and [PKIX-ALG2], but other signature algorithms may also be 3061 supported. 3063 For servers that do not verify signatures on CVRequest messages, the 3064 signatureVerification item is encoded as an empty sequence. 3066 6.17 hashAlgorithms 3068 This sequence specifies the set of hash algorithms that the server 3069 can use to hash certificates and requests. The list is ordered; the 3070 first hash algorithm is the server's default algorithm. The default 3071 algorithm will be used by the server to compute hashes included in 3072 responses unless the client specifies another algorithm. Each hash 3073 algorithm is specified as an object identifier. [PKIX-ALG2] 3074 specifies object identifiers for SHA-1, SHA-224, SHA-256, SHA-384, 3075 and SHA-512. Other hash algorithms may also be supported. 3077 6.18 serverPublicKeys 3079 The serverPublicKeys item is a sequence of one or more key agreement 3080 public keys and associated parameters. It is used by clients making 3081 AuthenticatedData requests to the server. Each item in the 3082 serverPublicKeys sequence is of the KeyAgreePublicKey type: 3084 KeyAgreePublicKey ::= SEQUENCE { 3085 algorithm AlgorithmIdentifier, 3086 publicKey BIT STRING, 3087 macAlgorithm AlgorithmIdentifier, 3088 kDF AlgorithmIdentifier OPTIONAL } 3090 The KeyAgreePublicKey includes the algorithm identifier and the 3091 server's public key. SCVP servers that support the key agreement 3092 mode of AuthenticatedData for SCVP requests MUST support 3093 serverPublicKeys and the Diffie-Hellman key agreement algorithm as 3094 specified in [PKIX-ALG]. SCVP servers that support serverPublicKeys 3095 MUST support the 1024-bit MODP group key (group 2) as defined in 3096 [IKE]. SCVP servers that support serverPublicKeys MAY support other 3097 Diffie-Hellman groups [IKE-GROUPS], as well as other key agreement 3098 algorithms. 3100 The macAlgorithm item specifies the symmetric algorithm the server 3101 expects the client to use with the result of the key agreement 3102 algorithm. A key derivation function (KDF), which derives symmetric 3103 key material from the key agreement result, may be implied by the 3104 macAlgorithm. Alternatively, the KDF may be explicitly specified 3105 using the optional kDF item. 3107 6.19 clockSkew 3109 The clockSkew item is the number of minutes the server will allow for 3110 clock skew. The default value of 10 minutes. 3112 7 SCVP Server Relay 3114 In some network environments, especially ones that include firewalls, 3115 an SCVP server might not be able to obtain all of the information 3116 that it needs to process a request. However, the server might be 3117 configured to use the services of one or more other SCVP servers to 3118 fulfill all requests. In such cases, the SCVP client is unaware that 3119 the initial SCVP server is using the services of other SCVP servers. 3120 The initial SCVP server acts as a client to another SCVP server. 3121 Unlike the original client, the SCVP server is expected to have 3122 moderate computing and memory resources. This section describes 3123 SCVP server-to-SCVP server exchanges. This section does not impose 3124 any requirements on SCVP clients that are not also SCVP servers. 3125 Further, this section does not impose any requirements on SCVP 3126 servers that do not relay requests to other SCVP servers. 3128 When one SCVP server relays a request to another server, in an 3129 incorrectly configured system of servers, it is possible that the 3130 same request will be relayed back again. Any SCVP server that relays 3131 requests MUST implement the conventions described in this section to 3132 detect and break loops. 3134 When an SCVP server relays a request, the request MUST include the 3135 requestorRef item. If the request to be relayed already contains a 3136 requestorRef item, then the server-generated request MUST contain a 3137 requestorRef item constructed from this value and an additional 3138 GeneralName that contains an identifier of the SCVP server. If the 3139 request to be relayed does not contain a requestorRef item, then the 3140 server-generated request MUST contain a requestorRef item that 3141 includes a GeneralName that contains an identifier of the SCVP 3142 server. 3144 To prevent false loop detection, servers should use identifiers that 3145 are unique within their network of cooperating SCVP servers. SCVP 3146 servers that support relay SHOULD populate this item with the DNS 3147 name of the server or the distinguished name in the server's 3148 certificate. SCVP servers MAY choose other procedures for generating 3149 identifiers that are unique within their community. 3151 When an SVCP server receives a request that contains a requestorRef 3152 item, the server MUST check the sequence of names in the requestorRef 3153 item for its own identifier. If the server discovers its own 3154 identifier in the requestorRef item, it MUST respond with an error, 3155 setting the statusCode in the responseStatus item to 40. 3157 When an SCVP server generates a non-cached response to a relayed 3158 request, the server MUST include the requestorRef item from the 3159 request in the response. 3161 8 SCVP ASN.1 Module 3163 This section defines the syntax for SCVP request-response pairs. The 3164 semantics for the messages are defined in sections 3, 4, 5, and 6. 3165 The SCVP ASN.1 module follows. 3167 SCVP 3169 { iso(1) identified-organization(3) dod(6) internet(1) 3170 security(5) mechanisms(5) pkix(7) id-mod(0) 21 } 3172 DEFINITIONS IMPLICIT TAGS ::= BEGIN 3174 IMPORTS 3176 AlgorithmIdentifier, Attribute, Certificate, Extensions, 3177 -- Import UTF8String if required by compiler 3178 -- UTF8String, -- CertificateList, CertificateSerialNumber 3179 FROM PKIX1Explicit88 -- RFC 3280 3180 { iso(1) identified-organization(3) dod(6) internet(1) 3181 security(5) mechanisms(5) pkix(7) id-mod(0) 18 } 3183 GeneralNames, GeneralName, KeyUsage, KeyPurposeId 3184 FROM PKIX1Implicit88 -- RFC 3280 3185 { iso(1) identified-organization(3) dod(6) internet(1) 3186 security(5) mechanisms(5) pkix(7) id-mod(0) 19 } 3188 AttributeCertificate 3189 FROM PKIXAttributeCertificate -- RFC 3281 3190 { iso(1) identified-organization(3) dod(6) internet(1) 3191 security(5) mechanisms(5) pkix(7) id-mod(0) 12 } 3193 OCSPResponse 3194 FROM OCSP -- RFC 2560 3195 { iso(1) identified-organization(3) dod(6) internet(1) 3196 security(5) mechanisms(5) pkix(7) id-mod(0) 14 } 3198 ContentInfo 3199 FROM CryptographicMessageSyntax2004 -- RFC 3852 3200 { iso(1) member-body(2) us(840) rsadsi(113549) 3201 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } ; 3203 -- SCVP Certificate Validation Request 3205 id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3206 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3207 id-smime(16) 1 } 3209 id-ct-scvp-certValRequest OBJECT IDENTIFIER ::= { id-ct 10 } 3211 CVRequest ::= SEQUENCE { 3212 cvRequestVersion INTEGER DEFAULT 1, 3213 query Query, 3214 requestorRef [0] GeneralNames OPTIONAL, 3215 requestNonce [1] OCTET STRING OPTIONAL, 3216 requestorName [2] GeneralName OPTIONAL, 3217 responderName [3] GeneralName OPTIONAL, 3218 requestExtensions [4] Extensions OPTIONAL, 3219 signatureAlg [5] AlgorithmIdentifier OPTIONAL, 3220 hashAlg [6] OBJECT IDENTIFIER OPTIONAL, 3221 requestorText [7] UTF8String (SIZE (1..256)) OPTIONAL } 3223 Query ::= SEQUENCE { 3224 queriedCerts CertReferences, 3225 checks CertChecks, 3226 wantBack [1] WantBack OPTIONAL, 3227 validationPolicy ValidationPolicy, 3228 responseFlags ResponseFlags OPTIONAL, 3229 serverContextInfo [2] OCTET STRING OPTIONAL, 3230 validationTime [3] GeneralizedTime OPTIONAL, 3231 intermediateCerts [4] CertBundle OPTIONAL, 3232 revInfos [5] RevocationInfos OPTIONAL, 3233 producedAt [6] GeneralizedTime OPTIONAL, 3234 queryExtensions [7] Extensions OPTIONAL } 3236 CertReferences ::= CHOICE { 3237 pkcRefs [0] SEQUENCE SIZE (1..MAX) OF PKCReference, 3238 acRefs [1] SEQUENCE SIZE (1..MAX) OF ACReference } 3240 CertReference::= CHOICE { 3241 pkc PKCReference, 3242 ac ACReference } 3244 PKCReference ::= CHOICE { 3245 cert [0] Certificate, 3246 pkcRef [1] SCVPCertID } 3248 ACReference ::= CHOICE { 3249 attrCert [2] AttributeCertificate, 3250 acRef [3] SCVPCertID } 3252 SCVPCertID ::= SEQUENCE { 3253 certHash OCTET STRING, 3254 issuerSerial SCVPIssuerSerial, 3255 hashAlgorithm AlgorithmIdentifier DEFAULT { algorithm sha-1 } } 3257 SCVPIssuerSerial ::= SEQUENCE { 3258 issuer GeneralNames, 3259 serialNumber CertificateSerialNumber 3260 } 3262 ValidationPolicy ::= SEQUENCE { 3263 validationPolRef ValidationPolRef, 3264 validationAlg [0] ValidationAlg OPTIONAL, 3265 userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT 3266 IDENTIFIER OPTIONAL, 3267 inhibitPolicyMapping [2] BOOLEAN OPTIONAL, 3268 requireExplicitPolicy [3] BOOLEAN OPTIONAL, 3269 inhibitAnyPolicy [4] BOOLEAN OPTIONAL, 3270 trustAnchors [5] TrustAnchors OPTIONAL, 3271 keyUsages [6] SEQUENCE OF KeyUsage OPTIONAL, 3272 extendedKeyUsages [7] SEQUENCE OF KeyPurposeId OPTIONAL, 3273 specifiedKeyUsages [8] SEQUENCE OF KeyPurposeId OPTIONAL } 3275 CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 3277 WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 3279 ValidationPolRef ::= SEQUENCE { 3280 valPolId OBJECT IDENTIFIER, 3281 valPolParams ANY DEFINED BY valPolId OPTIONAL } 3283 ValidationAlg ::= SEQUENCE { 3284 valAlgId OBJECT IDENTIFIER, 3285 parameters ANY DEFINED BY valAlgId OPTIONAL } 3287 NameValidationAlgParms ::= SEQUENCE { 3288 nameCompAlgId OBJECT IDENTIFIER, 3289 validationNames GeneralNames } 3291 TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF PKCReference 3293 KeyAgreePublicKey ::= SEQUENCE { 3294 algorithm AlgorithmIdentifier, 3295 publicKey BIT STRING, 3296 macAlgorithm AlgorithmIdentifier, 3297 kDF AlgorithmIdentifier OPTIONAL } 3299 ResponseFlags ::= SEQUENCE { 3300 fullRequestInResponse [0] BOOLEAN DEFAULT FALSE, 3301 responseValidationPolByRef [1] BOOLEAN DEFAULT TRUE, 3302 protectResponse [2] BOOLEAN DEFAULT TRUE, 3303 cachedResponse [3] BOOLEAN DEFAULT TRUE } 3305 CertBundle ::= SEQUENCE SIZE (1..MAX) OF Certificate 3307 RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo 3309 RevocationInfo ::= CHOICE { 3310 crl [0] CertificateList, 3311 delta-crl [1] CertificateList, 3312 ocsp [2] OCSPResponse, 3313 other [3] OtherRevInfo } 3315 OtherRevInfo ::= SEQUENCE { 3316 riType OBJECT IDENTIFIER, 3317 riValue ANY DEFINED BY riType } 3319 -- SCVP Certificate Validation Response 3321 id-ct-scvp-certValResponse OBJECT IDENTIFIER ::= { id-ct 11 } 3323 CVResponse ::= SEQUENCE { 3324 cvResponseVersion INTEGER, 3325 serverConfigurationID INTEGER, 3326 producedAt GeneralizedTime, 3327 responseStatus ResponseStatus, 3328 respValidationPolicy [0] RespValidationPolicy OPTIONAL, 3329 requestRef [1] RequestReference OPTIONAL, 3330 requestorRef [2] GeneralNames OPTIONAL, 3331 requestorName [3] GeneralNames OPTIONAL, 3332 replyObjects [4] ReplyObjects OPTIONAL, 3333 respNonce [5] OCTET STRING OPTIONAL, 3334 serverContextInfo [6] OCTET STRING OPTIONAL, 3335 cvResponseExtensions [7] Extensions OPTIONAL, 3336 requestorText [8] UTF8String (SIZE (1..256)) OPTIONAL } 3338 ResponseStatus ::= SEQUENCE { 3339 statusCode CVStatusCode DEFAULT okay, 3340 errorMessage UTF8String OPTIONAL } 3342 CVStatusCode ::= ENUMERATED { 3343 okay (0), 3344 skipUnrecognizedItems (1), 3345 tooBusy (10), 3346 invalidRequest (11), 3347 internalError (12), 3348 badStructure (20), 3349 unsupportedVersion (21), 3350 abortUnrecognizedItems (22), 3351 unrecognizedSigKey (23), 3352 badSignatureOrMAC (24), 3353 unableToDecode (25), 3354 notAuthorized (26), 3355 unsupportedChecks (27), 3356 unsupportedWantBacks (28), 3357 unsupportedSignatureOrMAC (29), 3358 invalidSignatureOrMAC (30), 3359 protectedResponseUnsupported (31), 3360 unrecognizedResponderName (32), 3361 relayingLoop (40), 3362 unrecognizedValPol (50), 3363 unrecognizedValAlg (51), 3364 fullRequestInResponseUnsupported (52), 3365 fullPolResponseUnsupported (53), 3366 inhibitPolicyMappingUnsupported (54), 3367 requireExplicitPolicyUnsupported (55), 3368 inhibitAnyPolicyUnsupported (56), 3369 validationTimeUnsupported (57), 3370 unrecognizedCritQueryExt (63), 3371 unrecognizedCritRequestExt (64) } 3373 RespValidationPolicy ::= ValidationPolicy 3375 RequestReference ::= CHOICE { 3376 requestHash [0] HashValue, -- hash of CVRequest 3377 fullRequest [1] CVRequest } 3379 HashValue ::= SEQUENCE { 3380 algorithm AlgorithmIdentifier DEFAULT { algorithm sha-1 }, 3381 value OCTET STRING } 3383 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3384 oiw(14) secsig(3) algorithm(2) 26 } 3386 ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply 3388 CertReply ::= SEQUENCE { 3389 cert CertReference, 3390 replyStatus ReplyStatus DEFAULT success, 3391 replyValTime GeneralizedTime, 3392 replyChecks ReplyChecks, 3393 replyWantBacks ReplyWantBacks, 3394 validationErrors [0] SEQUENCE SIZE (1..MAX) OF 3395 OBJECT IDENTIFIER OPTIONAL, 3396 nextUpdate [1] GeneralizedTime OPTIONAL, 3397 certReplyExtensions [2] Extensions OPTIONAL } 3399 ReplyStatus ::= ENUMERATED { 3400 success (0), 3401 malformedPKC (1), 3402 malformedAC (2), 3403 unavailableValidationTime (3), 3404 referenceCertHashFail (4), 3405 certPathConstructFail (5), 3406 certPathNotValid (6), 3407 certPathNotValidNow (7), 3408 wantBackUnsatisfied (8) } 3410 ReplyChecks ::= SEQUENCE OF ReplyCheck 3412 ReplyCheck ::= SEQUENCE { 3413 check OBJECT IDENTIFIER, 3414 status INTEGER DEFAULT 0 } 3416 ReplyWantBacks ::= SEQUENCE OF ReplyWantBack 3418 ReplyWantBack::= SEQUENCE { 3419 wb OBJECT IDENTIFIER, 3420 value OCTET STRING } 3422 CertBundles ::= SEQUENCE SIZE (1..MAX) OF CertBundle 3424 RevInfoWantBack ::= SEQUENCE { 3425 revocationInfo RevocationInfos, 3426 extraCerts CertBundle OPTIONAL } 3428 SCVPResponses ::= SEQUENCE OF ContentInfo 3430 -- SCVP Validation Policies Request 3432 id-ct-scvp-valPolRequest OBJECT IDENTIFIER ::= { id-ct 12 } 3434 ValPolRequest ::= SEQUENCE { 3435 vpRequestVersion INTEGER DEFAULT 1, 3436 requestNonce OCTET STRING } 3438 -- SCVP Validation Policies Response 3439 id-ct-scvp-valPolResponse OBJECT IDENTIFIER ::= { id-ct 13 } 3441 ValPolResponse ::= SEQUENCE { 3442 vpResponseVersion INTEGER, 3443 maxCVRequestVersion INTEGER, 3444 maxVPRequestVersion INTEGER, 3445 serverConfigurationID INTEGER, 3446 thisUpdate GeneralizedTime, 3447 nextUpdate GeneralizedTime OPTIONAL, 3448 supportedChecks CertChecks, 3449 supportedWantBacks WantBack, 3450 validationPolicies SEQUENCE OF OBJECT IDENTIFIER, 3451 validationAlgs SEQUENCE OF OBJECT IDENTIFIER, 3452 authPolicies SEQUENCE OF AuthPolicy, 3453 responseTypes ResponseTypes, 3454 defaultPolicyValues RespValidationPolicy, 3455 revocationInfoTypes RevocationInfoTypes, 3456 signatureGeneration SEQUENCE OF AlgorithmIdentifier, 3457 signatureVerification SEQUENCE OF AlgorithmIdentifier, 3458 hashAlgorithms SEQUENCE SIZE (1..MAX) OF 3459 OBJECT IDENTIFIER, 3460 serverPublicKeys SEQUENCE OF KeyAgreePublicKey 3461 OPTIONAL, 3462 clockSkew INTEGER DEFAULT 10, 3463 requestNonce OCTET STRING OPTIONAL } 3465 ResponseTypes ::= ENUMERATED { 3466 cached-only (0), 3467 non-cached-only (1), 3468 cached-and-non-cached (2) } 3470 RevocationInfoTypes ::= BIT STRING { 3471 fullCRLs (0), 3472 deltaCRLs (1), 3473 indirectCRLs (2), 3474 oCSPResponses (3) } 3476 AuthPolicy ::= OBJECT IDENTIFIER 3478 -- SCVP Check Identifiers 3480 id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3481 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 } 3483 id-stc-build-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 } 3484 id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 2 } 3485 id-stc-build-status-checked-pkc-path 3486 OBJECT IDENTIFIER ::= { id-stc 3 } 3488 id-stc-build-aa-path OBJECT IDENTIFIER ::= { id-stc 4 } 3489 id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 5 } 3490 id-stc-build-status-checked-aa-path 3491 OBJECT IDENTIFIER ::= { id-stc 6 } 3492 id-stc-status-check-ac-and-build-status-checked-aa-path 3493 OBJECT IDENTIFIER ::= { id-stc 7 } 3495 -- SCVP WantBack Identifiers 3497 id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3498 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 } 3500 id-swb-pkc-best-cert-path OBJECT IDENTIFIER ::= { id-swb 1 } 3501 id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 } 3502 id-swb-pkc-public-key-info OBJECT IDENTIFIER ::= { id-swb 4 } 3503 id-swb-aa-cert-path OBJECT IDENTIFIER ::= { id-swb 5 } 3504 id-swb-aa-revocation-info OBJECT IDENTIFIER ::= { id-swb 6 } 3505 id-swb-ac-revocation-info OBJECT IDENTIFIER ::= { id-swb 7 } 3506 id-swb-relayed-responses OBJECT IDENTIFIER ::= { id-swb 9 } 3507 id-swb-pkc-cert OBJECT IDENTIFIER ::= { id-swb 10} 3508 id-swb-ac-cert OBJECT IDENTIFIER ::= { id-swb 11} 3509 id-swb-pkc-all-cert-paths OBJECT IDENTIFIER ::= { id-swb 12} 3510 id-swb-pkc-ee-revocation-info OBJECT IDENTIFIER ::= { id-swb 13} 3511 id-swb-pkc-CAs-revocation-info OBJECT IDENTIFIER ::= { id-swb 14} 3513 -- SCVP Validation Policy and Algorithm Identifiers 3515 id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3516 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 } 3518 id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 } 3520 -- SCVP Basic Validation Algorithm Identifier 3522 id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 } 3524 -- SCVP Basic Validation Algorithm Errors 3526 id-bvae OBJECT IDENTIFIER ::= id-svp-basicValAlg 3528 id-bvae-expired OBJECT IDENTIFIER ::= { id-bvae 1 } 3529 id-bvae-not-yet-valid OBJECT IDENTIFIER ::= { id-bvae 2 } 3530 id-bvae-wrongTrustAnchor OBJECT IDENTIFIER ::= { id-bvae 3 } 3531 id-bvae-noValidCertPath OBJECT IDENTIFIER ::= { id-bvae 4 } 3532 id-bvae-revoked OBJECT IDENTIFIER ::= { id-bvae 5 } 3533 id-bvae-invalidKeyPurpose OBJECT IDENTIFIER ::= { id-bvae 9 } 3534 id-bvae-invalidKeyUsage OBJECT IDENTIFIER ::= { id-bvae 10 } 3535 id-bvae-invalidCertPolicy OBJECT IDENTIFIER ::= { id-bvae 11 } 3536 -- SCVP Name Validation Algorithm Identifier 3538 id-svp-nameValAlg OBJECT IDENTIFIER ::= { id-svp 2 } 3540 -- SCVP Name Validation Algorithm DN comparison algorithm 3542 id-nva-dnCompAlg OBJECT IDENTIFIER ::= { id-svp 4 } 3544 -- SCVP Name Validation Algorithm Errors 3546 id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg 3548 id-nvae-name-mismatch OBJECT IDENTIFIER ::= { id-nvae 1 } 3549 id-nvae-no-name OBJECT IDENTIFIER ::= { id-nvae 2 } 3550 id-nvae-unknown-alg OBJECT IDENTIFIER ::= { id-nvae 3 } 3551 id-nvae-bad-name OBJECT IDENTIFIER ::= { id-nvae 4 } 3552 id-nvae-bad-name-type OBJECT IDENTIFIER ::= { id-nvae 5 } 3553 id-nvae-mixed-names OBJECT IDENTIFIER ::= { id-nvae 6 } 3555 -- SCVP Extended Key Usage Key Purpose Identifiers 3557 id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3558 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } 3560 id-kp-scvpServer OBJECT IDENTIFIER ::= { id-kp 15 } 3562 id-kp-scvpClient OBJECT IDENTIFIER ::= { id-kp 16 } 3564 END 3566 9 Security Considerations 3568 For security considerations specific to the Cryptographic Message 3569 Syntax message formats, see [CMS]. For security considerations 3570 specific to the process of PKI certification path validation, see 3571 [PKIX-1]. 3573 A client that trusts a server's response for validation of a 3574 certificate inherently trusts that server as much as it would trust 3575 its own validation software. This means that if an attacker 3576 compromises a trusted SCVP server, the attacker can change the 3577 validation processing for every client that relies on that server. 3578 Thus, an SCVP server must be protected at least as well as the trust 3579 anchors that the SCVP server trusts. 3581 Clients MUST verify that the response matches their original request. 3582 Clients need to ensure that the server has performed the appropriate 3583 checks for the correct certificates under the requested validation 3584 policy for the specified validation time, and that the response 3585 includes the requested wantBacks and meets the client's freshness 3586 requirements. 3588 When the SCVP response is used to determine the validity of a 3589 certificate, the client MUST validate the digital signature or MAC on 3590 the response to ensure that the expected SCVP server generated it. 3591 If the client does not check the digital signature or MAC on the 3592 response, a man-in-the-middle attack could fool the client into 3593 believing modified responses from the server, or responses to 3594 questions the client did not ask. 3596 If the client does not include a requestNonce item, or if the client 3597 does not check that the requestNonce in the response matches the 3598 value in the request, an attacker can replay previous responses from 3599 the SCVP server. 3601 If the server does not require some sort of authorization (such as 3602 signed requests), an attacker can get the server to respond to 3603 arbitrary requests. Such responses may give the attacker information 3604 about weaknesses in the server or about the timeliness of the 3605 server's checking. This information may be valuable for a future 3606 attack. 3608 If the server uses the serverContextInfo item to indicate some server 3609 state associated with a requestor, implementers must take appropriate 3610 measures against denial of service attacks where an attacker sends in 3611 a lot of requests at one time to force the server to keep a lot of 3612 state information. 3614 SCVP does not include any confidentiality mechanisms. If 3615 confidentiality is needed, it can be achieved with a lower-layer 3616 security protocol such as TLS [TLS]. 3618 If an SCVP client is not operating on a network with good physical 3619 protection, it must ensure that there is integrity over the SCVP 3620 request-response pair. The client can ensure integrity by using a 3621 protected transport such as TLS. It can ensure integrity by using 3622 MACs or digital signatures to individually protect the request and 3623 response messages. 3625 If an SCVP client populates the userPolicySet in a request with a 3626 value other than anyPolicy, but does not set the 3627 requireExplicitPolicy flag, the server may return an affirmative 3628 answer for paths that do not satisfy any of the specified policies. 3629 In general, when a client populates the userPolicySet in a request 3630 with a value other than anyPolicy, the requireExplicitPolicy flag 3631 should also be set. This guarantees that all valid paths satisfy at 3632 least one of the requested policies. 3634 In SCVP, historical validation of a certificate returns the known 3635 status of the certificate at the time specified in validationTime. 3636 This may be used to demonstrate due diligence, but does not 3637 necessarily provide the most complete information. A certificate may 3638 have been revoked after the time specified in validationTime, but the 3639 revocation notice may specify an invalidity date that precedes the 3640 validationTime. The SCVP server would provide an affirmative 3641 response even though the most current information available indicates 3642 the certificate should not be trusted at that time. SCVP clients may 3643 wish to specify a validationTime later than the actual time of 3644 interest to mitigate this risk. 3646 10 IANA Considerations 3648 The details of SCVP requests and responses are communicated using 3649 Object Identifiers (OIDs). The objects are defined in an arc 3650 delegated by IANA to the PKIX Working Group. This document also 3651 includes four MIME type registrations in Appendix A. No further 3652 action by IANA is necessary for this document or any anticipated 3653 updates. 3655 11 References 3657 Normative and informative references are provided. 3659 11.1 Normative References 3661 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 3662 Requirement Levels", BCP 14, RFC 2119, March 1997. 3663 http://www.ietf.org/rfc/rfc2119.txt 3665 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 3666 RFC 3852, July 2004. 3667 http://www.ietf.org/rfc/rfc3852.txt 3669 [OCSP] Myers, M., R. Ankney, A. Malpani, S. Galperin and C. 3670 Adams, "X.509 Internet Public Key Infrastructure - Online 3671 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 3672 http://www.ietf.org/rfc/rfc2560.txt 3674 [PKIX-1] Housley, R., W. Polk, W. Ford and D. Solo, "Internet 3675 X.509 Public Key Infrastructure Certificate and 3676 Certificate Revocation List (CRL) Profile", RFC 3280, 3677 April 2002. 3678 http://www.ietf.org/rfc/rfc3280.txt 3680 [PKIX-AC] Farrell, S. and R. Housley, "An Internet Attribute 3681 Certificate Profile for Authorization", RFC 3281, 3682 April 2002. 3683 http://www.ietf.org/rfc/rfc3281.txt 3685 [PKIX-ALG] Polk, W., R. Housley and L. Bassham, "Algorithms and 3686 Identifiers for the Internet X.509 Public Key 3687 Infrastructure Certificate and Certificate Revocation 3688 List (CRL) Profile", RFC 3279, April 2002. 3689 http://www.ietf.org/rfc/rfc3279.txt 3691 [PKIX-ALG2] Schaad, J., B. Kaliski and R. Housley, "Additional 3692 Algorithms and Identifiers for RSA Cryptography for use 3693 in the Internet X.509 Public Key Infrastructure 3694 Certificate and Certificate Revocation List (CRL) 3695 Profile", RFC 4055, June 2005. 3696 http://www.ietf.org/rfc/rfc4055.txt 3698 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 3699 10646", RFC 3629, November 2003 3700 http://www.ietf.org/rfc/rfc3629.txt 3702 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", 3703 RFC 2634, June 1999. 3704 http://www.ietf.org/rfc/rfc2634.txt 3706 [SMIME-CERT] Ramsdell, B., "Secure/Multipurpose Internet Mail 3707 Extensions (S/MIME) Version 3.1 Certificate Handling", 3708 RFC 3850, July 2004. 3709 http://www.ietf.org/rfc/rfc3850.txt 3711 [IKE] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 3712 RFC 4306, December 2005. 3713 http://www.ietf.org/rfc/rfc4306.txt 3715 [HTTP] Fielding, R., J. Gettys, J. Mogul, H. Frystyk, L. 3716 Masinter, P. Leach and T. Berners-Lee, "Hypertext 3717 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3718 http://www.ietf.org/rfc/rfc2616.txt 3720 11.2 Informative References 3722 [IKE-GROUPS] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 3723 Diffie-Hellman groups for Internet Key Exchange (IKE)", 3724 RFC 3526, May 2003. 3725 http://www.ietf.org/rfc/rfc3526.txt 3727 [RQMTS] Pinkas, D. and R. Housley, "Delegated Path Validation and 3728 Delegated Path Discovery Protocol Requirements", 3729 RFC 3379, September 2002. 3730 http://www.ietf.org/rfc/rfc3379.txt 3732 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 3733 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 3735 12 Intellectual Property Rights 3737 The IETF takes no position regarding the validity or scope of any 3738 Intellectual Property Rights or other rights that might be claimed to 3739 pertain to the implementation or use of the technology described in 3740 this document or the extent to which any license under such rights 3741 might or might not be available; nor does it represent that it has 3742 made any independent effort to identify any such rights. Information 3743 on the procedures with respect to rights in RFC documents can be 3744 found in BCP 78 and BCP 79. 3746 Copies of IPR disclosures made to the IETF Secretariat and any 3747 assurances of licenses to be made available, or the result of an 3748 attempt made to obtain a general license or permission for the use of 3749 such proprietary rights by implementers or users of this 3750 specification can be obtained from the IETF on-line IPR repository at 3751 http://www.ietf.org/ipr. 3753 The IETF invites any interested party to bring to its attention any 3754 copyrights, patents or patent applications, or other proprietary 3755 rights that may cover technology that may be required to implement 3756 this standard. Please address the information to the IETF at ietf- 3757 ipr@ietf.org. 3759 13 Acknowledgments 3761 The lively debate in the PKIX Working Group has made a significant 3762 impact on this protocol. Special thanks to the following for their 3763 contributions to this standard and diligence in greatly improving 3764 this document. 3766 Paul Hoffman 3767 Phillip Hallam-Baker 3768 Mike Myers 3769 Frank Balluffi 3770 Ameya Talwalkar 3771 John Thielens 3772 Peter Sylvester 3773 Yuriy Dzambasow 3774 Sean P. Turner 3775 Wen-Cheng Wang 3776 Francis Dupont 3777 Dave Engberg 3778 Faisal Maqsood 3780 Thanks also to working group chair Steve Kent for his support and 3781 help. 3783 14 Authors' Addresses 3785 Trevor Freeman 3786 Microsoft Corporation, 3787 One Microsoft way. 3788 Redmond, WA 98052 3789 USA. 3790 trevorf@microsoft.com 3792 Russell Housley 3793 Vigil Security, LLC 3794 918 Spring Knoll Drive 3795 Herndon, VA 20170 3796 USA 3797 housley@Vigilsec.com 3799 Ambarish Malpani 3800 Malpani Consulting Services 3801 ambarish@yahoo.com 3803 David Cooper 3804 National Institute of Standards and Technology 3805 100 Bureau Drive, Mail Stop 8930 3806 Gaithersburg, MD 20899-8930 3807 david.cooper@nist.gov 3809 Tim Polk 3810 National Institute of Standards and Technology 3811 100 Bureau Drive, Mail Stop 8930 3812 Gaithersburg, MD 20899-8930 3813 wpolk@nist.gov 3815 Appendix A. MIME Media Type Registrations 3817 Four MIME media type registrations are provided in this appendix. 3819 A.1 application/scvp-cv-request 3821 To: ietf-types@iana.org 3822 Subject: Registration of MIME media type application/scvp-cv-request 3824 MIME media type name: application 3826 MIME subtype name: scvp-cv-request 3828 Required parameters: None 3830 Optional parameters: None 3832 Encoding considerations: binary 3834 Security considerations: Carries a request for information. This 3835 request may optionally be cryptographically protected. 3837 Interoperability considerations: None 3839 Published specification: IETF PKIX Working Group Draft on Server- 3840 based Certificate Validation Protocol (SCVP) 3842 Applications that use this media type: SCVP clients sending 3843 certificate validation requests 3845 Additional information: 3847 Magic number(s): None 3848 File extension(s): .SCQ 3849 Macintosh File Type Code(s): none 3851 Person & email address to contact for further information: 3852 Ambarish Malpani 3854 Intended usage: COMMON 3856 Restrictions on usage: This media type can be used with any protocol 3857 that can transport digitally signed objects. 3859 Author: Ambarish Malpani 3861 Change controller: IESG 3863 A.2 application/scvp-cv-response 3865 To: ietf-types@iana.org 3866 Subject: Registration of MIME media type application/scvp-cv-response 3868 MIME media type name: application 3870 MIME subtype name: scvp-cv-response 3872 Required parameters: None 3874 Optional parameters: None 3876 Encoding considerations: binary 3878 Security considerations: The client may require that this response be 3879 cryptographically protected, or may choose to use secure transport 3880 mechanism. DPD responses may be unprotected, but the client 3881 validates the information provided in the request. 3883 Interoperability considerations: None 3885 Published specification: IETF PKIX Working Group Draft on Server- 3886 based Certificate Validation Protocol (SCVP) 3888 Applications that use this media type: SCVP servers responding to 3889 certificate validation requests 3891 Additional information: 3893 Magic number(s): None 3894 File extension(s): .SCS 3895 Macintosh File Type Code(s): none 3897 Person & email address to contact for further information: 3898 Ambarish Malpani 3900 Intended usage: COMMON 3902 Restrictions on usage: This media type can be used with any protocol 3903 that can transport digitally signed objects. 3905 Author: Ambarish Malpani 3907 Change controller: IESG 3909 A.3 application/scvp-vp-request 3911 To: ietf-types@iana.org 3912 Subject: Registration of MIME media type application/scvp-vp-request 3914 MIME media type name: application 3916 MIME subtype name: scvp-vp-request 3918 Required parameters: None 3920 Optional parameters: None 3922 Encoding considerations: binary 3924 Security considerations: Carries a request for information. 3926 Interoperability considerations: None 3928 Published specification: IETF PKIX Working Group Draft on Server- 3929 based Certificate Validation Protocol (SCVP) 3931 Applications that use this media type: SCVP clients sending 3932 validation policy requests 3934 Additional information: 3936 Magic number(s): None 3937 File extension(s): .SPQ 3938 Macintosh File Type Code(s): none 3940 Person & email address to contact for further information: 3941 Ambarish Malpani 3943 Intended usage: COMMON 3945 Restrictions on usage: none 3947 Author: Ambarish Malpani 3949 Change controller: IESG 3951 A.4 application/scvp-vp-response 3953 To: ietf-types@iana.org 3954 Subject: Registration of MIME media type application/scvp-vp-response 3956 MIME media type name: application 3957 MIME subtype name: scvp-vp-response 3959 Required parameters: None 3961 Optional parameters: None 3963 Encoding considerations: Binary 3965 Security considerations: None 3967 Interoperability considerations: None 3969 Published specification: IETF PKIX Working Group Draft on Server- 3970 based Certificate Validation Protocol (SCVP) 3972 Applications that use this media type: SCVP servers responding to 3973 validation policy requests 3975 Additional information: 3977 Magic number(s): None 3978 File extension(s): .SPP 3979 Macintosh File Type Code(s): none 3981 Person & email address to contact for further information: 3982 Ambarish Malpani 3984 Intended usage: COMMON 3986 Restrictions on usage: This media type can be used with any protocol 3987 that can transport digitally signed objects. 3989 Author: Ambarish Malpani 3991 Change controller: IESG 3993 Appendix B. SCVP over HTTP 3995 This appendix describes the formatting and transportation conventions 3996 for the SCVP request and response when carried by HTTP. 3998 In order for SCVP clients and servers using HTTP to interoperate, the 3999 following rules apply. 4001 - Clients MUST use the POST method to submit their requests. 4003 - Servers MUST use the 200 response code for successful responses. 4005 - Clients MAY attempt to send HTTPS requests using TLS 1.0 or later, 4006 although servers are not required to support TLS. 4008 - Servers MUST NOT assume client support for any type of HTTP 4009 authentication such as cookies, Basic authentication, or Digest 4010 authentication. 4012 - Clients and servers are expected to follow the other rules and 4013 restrictions in [HTTP]. Note that some of those rules are for 4014 HTTP methods other than POST; clearly, only the rules that apply 4015 to POST are relevant for this specification. 4017 B.1 SCVP Request 4019 An SCVP request using the POST method is constructed as follows: 4021 The Content-Type header MUST have the value 4022 "application/scvp-cv-request". 4024 The body of the message is the binary value of the DER encoding 4025 of the CVRequest, wrapped in a CMS body as described in Section 4026 3. 4028 B.2 SCVP Response 4030 An HTTP-based SCVP response is composed of the appropriate HTTP 4031 headers, followed by the binary value of the BER encoding of the 4032 CVResponse, wrapped in a CMS body as described in Section 4. 4034 The Content-Type header MUST have the value 4035 "application/scvp-cv-response". 4037 B.3 SCVP Policy Request 4039 An SCVP request using the POST method is constructed as follows: 4041 The Content-Type header MUST have the value 4042 "application/scvp-vp-request". 4044 The body of the message is the binary value of the BER encoding 4045 of the ValPolRequest, wrapped in a CMS body as described in 4046 Section 5. 4048 B.4 SCVP Policy Response 4050 An HTTP-based SCVP policy response is composed of the appropriate 4051 HTTP headers, followed by the binary value of the DER encoding of the 4052 ValPolResponse, wrapped in a CMS body as described in Section 6. 4054 The Content-Type header MUST have the value 4055 "application/scvp-vp-response". 4057 Full Copyright Statement 4059 Copyright (C) The IETF Trust (2007). 4061 This document is subject to the rights, licenses and restrictions 4062 contained in BCP 78, and except as set forth therein, the authors 4063 retain all their rights. 4065 This document and the information contained herein are provided on an 4066 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4067 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 4068 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 4069 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4070 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4071 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4073 This document and translations of it may be copied and furnished to 4074 others, and derivative works that comment on or otherwise explain it 4075 or assist in its implementation may be prepared, copied, published 4076 and distributed, in whole or in part, without restriction of any 4077 kind, provided that the above copyright notice and this paragraph are 4078 included on all such copies and derivative works. In addition, the 4079 ASN.1 modules presented may be used in whole or in part without 4080 inclusion of the copyright notice. However, this document itself may 4081 not be modified in any way, such as by removing the copyright notice 4082 or references to the Internet Society or other Internet 4083 organizations, except as needed for the purpose of developing 4084 Internet standards in which case the procedures for copyrights 4085 defined in the Internet Standards process shall be followed, or as 4086 required to translate it into languages other than English.