idnits 2.17.1 draft-ietf-pkix-scvp-17.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 3667, Section 5.1 on line 20. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 3616), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. == In addition to a regular copyright notice, the document also has a copyright notice embedded in the text. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 3077 -- Looks like a reference, but probably isn't: '1' on line 3078 -- Looks like a reference, but probably isn't: '2' on line 3009 -- Looks like a reference, but probably isn't: '3' on line 2943 -- Looks like a reference, but probably isn't: '4' on line 2879 -- Looks like a reference, but probably isn't: '5' on line 2944 -- Looks like a reference, but probably isn't: '6' on line 2945 -- Looks like a reference, but probably isn't: '7' on line 2946 -- Looks like a reference, but probably isn't: '8' on line 2947 == Missing Reference: 'RQTMS' is mentioned on line 2438, but not defined ** Obsolete normative reference: RFC 2630 (ref. 'CMS') (Obsoleted by RFC 3369, RFC 3370) ** 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) -- Duplicate reference: RFC3280, mentioned in 'PKIX-ALG', was also mentioned in 'PKIX-1'. ** Obsolete normative reference: RFC 3280 (ref. 'PKIX-ALG') (Obsoleted by RFC 5280) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA-1' ** Obsolete normative reference: RFC 2279 (ref. 'UTF8') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2818 (ref. 'HTTP-TLS') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3850 (ref. 'SMIME-CERT') (Obsoleted by RFC 5750) ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2068 (ref. 'HTTP') (Obsoleted by RFC 2616) Summary: 23 errors (**), 0 flaws (~~), 4 warnings (==), 15 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-17.txt Microsoft Corp 4 February 2005 R. Housley 5 Expires in six months Vigil Security 6 A. Malpani 7 Malpani Consulting Services 8 D. Cooper 9 NIST 10 T. Polk 11 NIST 13 Simple Certificate Validation Protocol (SCVP) 15 Status of this Memo 17 By submitting this Internet-Draft, I certify that any applicable 18 patent or other IPR claims of which I am aware have been disclosed, 19 or will be disclosed, and any of which I become aware will be 20 disclosed, in accordance with RFC 3668. 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 25 Internet-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 a "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). All Rights Reserved. 42 Abstract 44 SCVP allows a client to delegate certificate path construction and 45 certificate path validation to a server. The path construction or 46 validation (e.g. making sure that none of the certificates in the 47 path are revoked) is performed according to a validation policy, 48 which contains one or more trust anchors. It allows simplification 49 of client implementations and use of a set of predefined validation 50 policies. 52 Table of Contents 54 1 Introduction..................................................5 55 1.1 SCVP overview and requirements............................5 56 1.2 Terminology................................................6 57 1.3 Validation Policies........................................6 58 1.4 Validation Algorithm.......................................7 59 1.5 Validation Requirements....................................8 60 2 Protocol Overview.............................................8 61 3 Validation Request............................................9 62 3.1 cvRequestVersion..........................................12 63 3.2 query.....................................................12 64 3.2.1 queriedCerts..........................................13 65 3.2.2 checks................................................13 66 3.2.3 wantBack..............................................15 67 3.2.4 validationPolicy......................................17 68 3.2.4.1 validationPolRef..................................18 69 3.2.4.1.1 Default Validation Policy......................18 70 3.2.4.2 validationAlg.....................................19 71 3.2.4.2.1 Basic Validation Algorithm.....................19 72 3.2.4.2.2 Basic Validation Algorithm Errors..............20 73 3.2.4.2.3 Name Validation Algorithm......................21 74 3.2.4.2.4 Name Validation Algorithm Errors...............22 75 3.2.4.3 userPolicySet.....................................23 76 3.2.4.4 inhibitPolicyMapping..............................23 77 3.2.4.5 requireExplicitPolicy.............................23 78 3.2.4.6 inhibitAnyPolicy..................................23 79 3.2.4.7 trustAnchors......................................24 80 3.2.4.8 keyUsages.........................................24 81 3.2.4.9 extendedKeyUsages.................................25 82 3.2.5 responseFlags.........................................25 83 3.2.5.1 fullRequestInResponse.............................26 84 3.2.5.2 responseValidationPolByRef........................26 85 3.2.5.3 protectResponse...................................26 86 3.2.5.4 cachedResponse....................................27 87 3.2.6 serverContextInfo.....................................27 88 3.2.7 valididationTime......................................28 89 3.2.8 intermediateCerts.....................................29 90 3.2.9 revInfos..............................................29 91 3.2.10 producedAt...........................................30 92 3.2.11 queryExtensions......................................31 93 3.2.11.1 extnID...........................................31 94 3.2.11.2 critical.........................................31 95 3.2.11.3 extnValue........................................31 96 3.3 requestorRef..............................................31 97 3.4 requestNonce..............................................32 98 3.5 requestorName.............................................32 99 3.6 requestExtensions.........................................33 100 3.6.1 extnID................................................33 101 3.6.2 critical..............................................33 102 3.6.3 extnValue.............................................33 103 3.7 SCVP Request Authentication...............................33 104 4 Validation Response..........................................34 105 4.1 cvResponseVersion.........................................37 106 4.2 policyID..................................................37 107 4.3 producedAt................................................37 108 4.4 responseStatus............................................38 109 4.5 respValidationPolicy......................................40 110 4.5.1 validationPolicy......................................40 111 4.5.2 validationPolicyAttr..................................40 112 4.6 requestRef................................................40 113 4.6.1 requestHash...........................................41 114 4.6.2 fullRequest...........................................42 115 4.7 requestorRef..............................................42 116 4.8 requestorName.............................................42 117 4.9 replyObjects..............................................42 118 4.9.1 cert..................................................43 119 4.9.2 replyStatus...........................................44 120 4.9.3 replyValTime..........................................45 121 4.9.4 replyChecks...........................................45 122 4.9.5 replyWantBacks........................................47 123 4.9.6 validationErrors......................................48 124 4.9.7 nextUpdate............................................49 125 4.9.8 certReplyExtensions...................................49 126 4.10 respNonce................................................49 127 4.11 serverContextInfo........................................50 128 4.12 cvResponseExtensions.....................................50 129 4.13 SCVP Response Validation.................................51 130 4.13.1 Simple Key Validation................................51 131 4.13.2 SCVP Server Certificate Validation...................51 132 5 Server Policy Request........................................52 133 5.1 vpRequestVersion..........................................52 134 5.2 requestNonce..............................................52 135 6 Validation Policy Response...................................52 136 6.1 vpResponseVersion.........................................54 137 6.2 maxCVRequestVersion.......................................54 138 6.3 maxVPRequestVersion.......................................54 139 6.4 defaultPolicyID...........................................54 140 6.5 thisUpdate................................................55 141 6.6 nextUpdate and requestNonce...............................55 142 6.7 validationPolicies........................................56 143 6.8 validationAlgs............................................56 144 6.9 authPolicies..............................................56 145 6.10 responseTypes............................................56 146 6.11 revocationInfoTypes......................................56 147 6.12 defaultPolicyValues......................................56 148 6.13 serverPublicKeys.........................................57 149 6.14 clockSkew................................................57 150 7 SCVP Server Relay............................................57 151 8 SCVP ASN.1 Module............................................58 152 9 Security Considerations......................................66 153 10 References..................................................68 154 10.1 Normative References.....................................68 155 10.2 Informative References...................................69 156 11 Acknowledgments.............................................69 157 Appendix A -- MIME Registrations...............................70 158 A.1 application/cv-request....................................70 159 A.2 application/cv-response...................................71 160 A.3 application/vp-request....................................72 161 A.4 application/vp-response...................................72 162 Appendix B -- SCVP over HTTP...................................73 163 B.1 SCVP Request..............................................73 164 B.2 SCVP Response.............................................74 165 B.3 SCVP Policy Request.......................................74 166 B.4 SCVP Policy Response......................................74 167 Appendix C -- Author Contact Information.......................75 168 1 Introduction 170 Certificate validation is complex. If certificate handling is to be 171 widely deployed in a variety of applications and environments, the 172 amount of processing an application needs to perform before it can 173 accept a certificate needs to be reduced. There are a variety of 174 applications that can make use of public key certificates, but these 175 applications are burdened with the overhead of constructing and 176 validating the certification paths. SCVP reduces this overhead for 177 two classes of certificate-using applications. 179 The first class of applications wants just two things: confirmation 180 that the public key belongs to the identity named in the certificate 181 and confirmation that the public key can be used for the intended 182 purpose. Such clients can completely delegate certification path 183 construction and validation to the SCVP server. This is often 184 referred to as delegated path validation (DPV). 186 The second class of applications can perform certification path 187 validation, but they lack a reliable or efficient method of 188 constructing a valid certification path. Such clients delegate 189 certification path construction to the SCVP server, but not 190 validation of the returned certification path. This is often 191 referred to as delegated path discovery (DPD). 193 1.1 SCVP overview and requirements 195 SCVP meets the mandatory requirements documented in [RQMTS]. 197 The primary goals of SCVP are to make it easier to deploy PKI-enabled 198 applications and to allow central administration of PKI policies 199 within an organization. SCVP can be used by clients that do much of 200 the certificate processing themselves but simply want an untrusted 201 server to collect information for them. However, when the client has 202 complete trust in the SCVP server, SCVP can be used to delegate the 203 work of certification path construction and validation, and SCVP can 204 be used to ensure that policies are consistently enforced throughout 205 an organization. 207 Untrusted SCVP servers can provide clients the certification paths. 208 They can also provide clients the revocation information, such as 209 CRLs and OCSP responses, that the clients need to validate the 210 certification paths constructed by the SCVP server. These services 211 can be valuable to clients that do not include the protocols needed 212 to find and download intermediate certificates, CRLs, and OCSP 213 responses. 215 Trusted SCVP servers can perform certification path construction and 216 validation for the client. For a client that uses these services, 217 the client inherently trusts the SCVP server as much as it would its 218 own certification path validation software (if it contained such 219 software). There are two main reasons that a client may want to 220 trust such an SCVP server: 222 1. The client does not want to incur the overhead of including 223 certification path validation software and running it for each 224 certificate it receives. 226 2. The client is in an organization or community that wants to 227 centralize its PKI policies. These policies might dictate that 228 particular trust anchors are to be used and the types of policy 229 checking that are to be performed during certification path 230 validation. 232 1.2 Terminology 234 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 235 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 236 document are to be interpreted as described in [STDWORDS]. 238 1.3 Validation Policies 240 A validation policy (as defined in RFC 3379 [RQMTS]) specifies the 241 rules and parameters to be used by the SCVP server when validating a 242 certificate. In SCVP, the validation policy to be used by the server 243 can either be fully referenced in the request by the client (and thus 244 no additional parameters are necessary) or it can be referenced in 245 the request by the client with additional parameters. 247 Policy definitions can be quite long and complex, and some policies 248 may allow for the setting of a few parameters. The request can 249 therefore be very simple if an OBJECT IDENTIFIER (OID) or URI is used 250 to specify both the algorithm to be used and all the associated 251 parameters of the validation policy. The request can be more complex 252 if the validation policy fixes many of the parameters but allows the 253 client to specify some of them. When the validation policy defines 254 every parameter necessary, an SCVP request needs only to contain the 255 certificate to be validated, the referenced validation policy, and 256 any run-time parameters for the request. 258 A server publishes the references of the validation policies it 259 supports. When these policies have parameters that may be 260 overridden, the server communicates the default values for these 261 parameters as well. The client can simplify the request by omitting 262 a parameter from a request if the default value published by the 263 server for a given validation policy reference is acceptable. 265 However, if there is a desire to demonstrate to someone else that a 266 specific validation policy with all its parameters has been used, the 267 client will need to ask the server for the inclusion of the full 268 validation policy with all the parameters in the response. 270 The inputs to the basic certification path processing algorithm used 271 by SCVP are defined by [PKIX-1] in section 6.1.1 and comprise: 273 Certificate to be validated (by value or by reference); 275 Validation time; 277 Set of Trust Anchors (by value or by reference); 279 The initial policy set; 281 Initial inhibit policy mapping setting; 283 Initial inhibit anyPolicy setting; and 285 Initial require explicit policy setting. 287 The basic certification path processing algorithm also supports the 288 following parameters, which are defined in [PKIX-1] section 4: 290 The usage of the key contained in the certificate (e.g., key 291 encipherment, key agreement, signature); and 293 Other application-specific purposes for which the certified public 294 key may be used. 296 1.4 Validation Algorithm 298 The validation algorithm is determined by agreement between the 299 client and the server and is represented as an OID. The algorithm 300 defines the checking that will be performed by the server to 301 determine whether the certificate is valid. A validation algorithm 302 is one of the parameters to a validation policy. SCVP defines a 303 basic validation algorithm which implements the certification path 304 validation algorithm as defined in [PKIX-1]. New validation 305 algorithms can be specified that define additional checks if needed. 306 These new validation algorithms may specify additional parameters. 307 The values for these parameters may be defined by any validation 308 policy that uses the algorithm or may be included by the client in 309 the request. 311 Application-specific validation algorithms in addition to those 312 defined in this document can be defined to meet specific requirements 313 not covered by the basic validation algorithm. The validation 314 algorithms documented here should serve as a guide for the 315 development of further application-specific validation algorithms. 316 For example, a new application-specific validation algorithm might 317 require the presence of a particular name form in the subject 318 alternative name extension of the certificate. 320 1.5 Validation Requirements 322 For a certification path to be considered valid under a particular 323 validation policy it MUST be a valid certification path as defined in 324 [PKIX-1] and all validation policy constraints that apply to the 325 certification path MUST be verified. 327 Revocation checking is one aspect of certification path validation 328 defined in [PKIX-1]. However, revocation checking is an optional 329 feature in [PKIX-1], and revocation information is distributed in 330 multiple formats. Clients specify in requests whether revocation 331 checking should be performed and whether revocation information 332 should be returned in the response. 334 Servers MUST be capable of indicating the sources of revocation 335 information that they are capable of processing: 337 1. full CRLs (or full Authority Revocation Lists); 339 2. OCSP responses, using [OCSP]; 341 3. delta CRLs; and 343 4. indirect CRLs. 345 2 Protocol Overview 347 SCVP uses a simple request-response model. That is, the SCVP client 348 creates a request and sends it to the SCVP server, and then the SCVP 349 server creates a single response and sends it to the client. The 350 typical use of SCVP is expected to be over HTTP [HTTP], but it can 351 also be used with email or any other protocol that can transport 352 digitally signed objects. Appendices A and B provide the details 353 necessary to use SCVP with HTTP. 355 SCVP includes two request-response pairs. The primary request- 356 response pair handles certificate validation. The secondary request- 357 response pair is used to determine the list of validation policies 358 and default parameters supported by a specific SCVP server. 360 Section 3 defines the certificate validation request. 362 Section 4 defines the corresponding certificate validation response. 364 Section 5 defines the validation policies request. 366 Section 6 defines the corresponding validation policies response. 368 Appendix A registers MIME types for SCVP requests and responses, and 369 Appendix B describes the use of these MIME types with HTTP. 371 3 Validation Request 373 An SCVP client request to the server MUST be a single CVRequest item. 374 When a CVRequest is encapsulated in a MIME body part, application/cv- 375 request MUST be used. 377 There are two forms of SCVP request: unprotected and protected. A 378 protected request is used to authenticate the client to the server or 379 to provide anonymous client integrity over the request-response pair. 380 The protection is provided by a digital signature or message 381 authentication code (MAC). In the later case, the MAC key is derived 382 using a key agreement algorithm, such as Diffie-Hellman. If the 383 client's public key is contained in a certificate, then it may be 384 used to authenticate the client. More commonly, the client's key 385 agreement public key will be ephemeral, supporting anonymous client 386 integrity. 388 A server MAY require all requests to be protected, and a server MAY 389 discard all unprotected requests. Alternatively, a server MAY choose 390 to process unprotected requests. 392 The unprotected request consists of a CVRequest encapsulated in a CMS 393 ContentInfo [CMS]. An overview of these structures is provided below 394 and is only intended as illustrative. The definitive ASN.1 is found 395 in [CMS]. Many details are not shown, but the way that SCVP makes 396 use of CMS is clearly illustrated. 398 ContentInfo { 399 contentType id-ct-scvp-certValRequest, 400 -- (1.2.840.113549.1.9.16.1.10) 401 content CVRequest } 403 The protected request consists of a CVRequest encapsulated in either 404 a SignedData or AuthenticatedData, which is in turn encapsulated in a 405 ContentInfo. SignedData is used when the request is digitally 406 signed. AuthenticatedData is used with a message authentication code 407 (MAC). An overview of these structures is provided below. Again, 408 many details are not shown, but the way that SCVP makes use of CMS is 409 clearly illustrated. 411 SignedData example: 413 ContentInfo { 414 contentType id-signedData, -- (1.2.840.113549.1.7.2) 415 content SignedData } 417 SignedData { 418 version CMSVersion, 419 digestAlgorithms DigestAlgorithmIdentifiers, 420 encapContentInfo EncapsulatedContentInfo, 421 certificates [0] IMPLICIT CertificateSet, -- Optional 422 crls [1] IMPLICIT CertificateRevocationLists, 423 -- Optional 424 signerInfos SET OF SignerInfo } -- Only one in SCVP 426 SignerInfo { 427 version CMSVersion, 428 sid SignerIdentifier, 429 digestAlgorithm DigestAlgorithmIdentifier, 430 signedAttrs SignedAttributes, -- Required in SCVP 431 signatureAlgorithm SignatureAlgorithmIdentifier, 432 signature SignatureValue, 433 unsignedAttrs UnsignedAttributes } -- not used in SCVP 435 EncapsulatedContentInfo { 436 eContentType id-ct-scvp-certValRequest, 437 -- (1.2.840.113549.1.9.16.1.10) 438 eContent OCTET STRING } -- Contains CVRequest 440 AuthenticatedData example: 442 ContentInfo { 443 contentType id-ct-authData, 444 -- (1.2.840.113549.1.9.16.1.2) 445 content AuthenticatedData } 447 AuthenticatedData { 448 version CMSVersion, 449 originatorInfo OriginatorInfo, -- Optional 450 recipientInfos RecipientInfos, -- Only SCVP server 451 macAlgorithm MessageAuthenticationCodeAlgorithm, 452 digestAlgorithm DigestAlgorithmIdentifier, -- Optional 453 encapContentInfo EncapsulatedContentInfo, 454 authAttrs AuthAttributes, -- Required in SCVP 455 mac MessageAuthenticationCode, 456 unauthAttrs UnauthAttributes } -- not used in SCVP 458 EncapsulatedContentInfo { 459 eContentType id-ct-scvp-certValRequest, 460 -- (1.2.840.113549.1.9.16.1.10) 462 eContent OCTET STRING } -- Contains CVRequest 464 All SCVP clients MUST support SignedData for signed requests and 465 responses. SCVP clients SHOULD support AuthenticatedData for MAC 466 protected requests and responses. 468 If the client uses SignedData it MUST have a public key that has been 469 bound to a subject identity by a certificate that conforms to the 470 PKIX profile [PKIX-1] and that certificate MUST be suitable for 471 signing the SCVP request. That is: 473 1. If the key usage extension is present, either the digital 474 signature or the non-repudiation bit MUST be asserted. 476 2. If the extended key usage extension is present, it MUST 477 contain either the SCVP client OID (see Section 3.7) or 478 another OID acceptable to the SCVP server. 480 The client MUST put an unambiguous reference to its certificate in 481 the SignedData that encapsulates the request. The client SHOULD 482 include its certificate in the request, but MAY omit the certificate 483 to reduce the size of the request. The client MAY include other 484 certificates in the request to aid the validation of its certificates 485 by the SCVP server. 487 The client MUST put its key agreement public key or an unambiguous 488 reference to a certificate that contains its key agreement public key 489 in the AuthenticatedData that encapsulates the request. If an 490 ephemeral key agreement key pair is used, then the ephemeral key 491 agreement public key is carried in the originatorKey field of 492 KeyAgreeRecipientInfo, which requires the client to obtain the 493 server's key agreement public key before computing the message 494 authentication code (MAC). 496 The syntax and semantics for SignedData, AuthenticatedData, and 497 ContentInfo are defined in [CMS]. The syntax and semantics for 498 CVRequest are defined below. The CVRequest item contains the client 499 request. The CVRequest contains the cvRequestVersion and query 500 items; the CVRequest MAY also contain the requestorRef, requestNonce, 501 requestorName, and requestExtensions items. 503 The CVRequest MUST have the following syntax: 505 CVRequest ::= SEQUENCE { 506 cvRequestVersion INTEGER, 507 query Query, 508 requestorRef [0] SEQUENCE SIZE (1..MAX) OF OCTET STRING 509 OPTIONAL, 510 requestNonce [1] OCTET STRING OPTIONAL, 511 requestorName [2] GeneralName OPTIONAL, 512 requestExtensions [3] Extensions OPTIONAL } 514 Each of the items within the CVRequest is described in the following 515 sections. 517 3.1 cvRequestVersion 519 The cvRequestVersion item defines the version of the SCVP CVRequest 520 used in a request. The subsequent response MUST use the same version 521 number. The value of the cvRequestVersion item MUST be one (1) for a 522 client implementing this specification. Future updates to this 523 specification must specify other values if there are any changes to 524 syntax or semantics. 526 3.2 query 528 The query item specifies one or more certificates that are the 529 subject of the request; the certificates can be either public key 530 certificates [PKIX-1] or attribute certificates [PKIX-AC]. A query 531 MUST contain a queriedCerts item as well as one checks, one wantBack, 532 and one validationPolicy item; a query MAY also contain 533 responseFlags, serverContextInfo, validationTime, intermediateCerts, 534 revInfos, producedAt, and queryExtensions items. 536 Query MUST have the following syntax: 538 Query ::= SEQUENCE { 539 queriedCerts CertReferences, 540 checks CertChecks, 541 wantBack WantBack, 542 validationPolicy ValidationPolicy, 543 responseFlags ResponseFlags OPTIONAL, 544 serverContextInfo [2] OCTET STRING OPTIONAL, 545 validationTime [3] GeneralizedTime OPTIONAL, 546 intermediateCerts [4] CertBundle OPTIONAL, 547 revInfos [5] RevocationInfos OPTIONAL, 548 producedAt [6] GeneralizedTime OPTIONAL, 549 queryExtensions [7] Extensions OPTIONAL } 551 The list of certificate references in the query item tells the server 552 the certificate(s) for which the client wants information. The 553 checks item specifies the checking that the client wants performed. 554 The wantBack item specifies the objects that the client wants the 555 server to return in the response. The validationPolicy item 556 specifies the validation policy that the client wants the server to 557 employ. The responseFlags item allows the client to request optional 558 features for the response. The serverContextInfo item tells the 559 server that additional information from a previous request-response 560 is desired. The validationTime item tells the date and time relative 561 to which the client wants the server to perform the checks. The 562 intermediateCerts and revInfos items provide context for the client 563 request. The queryExtensions item provides for future expansion of 564 the query syntax. The syntax and semantics of each of these items is 565 discussed in the following sections. 567 3.2.1 queriedCerts 569 The queriedCerts field is a SEQUENCE of one or more certificates, 570 each of which is a subject of the request. The specified 571 certificates are either public key certificates or attribute 572 certificates; if more than one certificate is specified, all must be 573 of the same type. Each certificate is either directly included or it 574 is referenced. When referenced, a SHA-1 hash value [SHA-1] of the 575 referenced item is included to ensure that the SCVP client and the 576 SCVP server both obtain the same certificate when the referenced 577 certificate is fetched. Certificate references use the ESSCertID 578 type defined in [ESS]. A single request MAY contain both directly 579 included and referenced certificates. 581 CertReferences has the following syntax: 583 CertReferences ::= CHOICE { 584 pkcRefs [0] SEQUENCE SIZE (1..MAX) OF PKCReference, 585 acRefs [1] SEQUENCE SIZE (1..MAX) OF ACReference } 587 PKCReference ::= CHOICE { 588 cert [0] Certificate, 589 pkcRef [1] ESSCertID } 591 ACReference ::= CHOICE { 592 attrCert [2] AttributeCertificate, 593 acRef [3] ESSCertID } 595 The ASN.1 definition of Certificate is imported from [PKIX-1]; the 596 definition of AttributeCertificate is imported from [PKIX-AC]; and 597 the definition of ESSCertID is imported from [ESS]. 599 3.2.2 checks 601 The checks item describes the checking that the SCVP client wants the 602 SCVP server to perform on the certificate(s) in the queriedCerts 603 item. The checks item MUST contain a sequence of object identifiers 604 (OIDs). Each OID tells the SCVP server what checking the client 605 expects the server to perform. For each check specified in the 606 request, the SCVP server MUST perform all of the requested checks, or 607 return an error. A server may choose to perform additional checks 608 (e.g., a server that is only asked to build a validated certification 609 path may choose to also perform revocation status checks), although 610 the server cannot indicate in the response that the additional checks 611 have been performed. 613 The checks item uses the CertChecks type, which has the following 614 syntax: 616 CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 618 For public key certificates, the following checks are defined: 620 - id-stc-build-pkc-path: Build a certification path to a trust 621 anchor; 623 - id-stc-build-valid-pkc-path: Build a validated certification path 624 to a trust anchor (revocation checking not required); 626 - id-stc-build-status-checked-pkc-path: Build a validated 627 certification path to a trust anchor and perform revocation 628 status checks on the certification path. 630 Conforming SCVP server implementations MUST support the id-stc-build- 631 pkc-path check. Conforming SCVP server implementations that support 632 delegated path validation (DPV) as defined in [RQMTS] MUST support 633 the id-stc-build-valid-pkc-path and id-stc-build-status-checked-pkc- 634 path checks. 636 For attribute certificates, the following checks are defined: 638 - id-stc-build-aa-path: Build a certification path to a trust 639 anchor for the AC issuer; 641 - id-stc-build-valid-aa-path: Build a validated certification path 642 to a trust anchor for the AC issuer; 644 - id-stc-build-status-checked-aa-path: Build a validated 645 certification path to a trust anchor for the AC issuer and 646 perform revocation status checks on the certification path for 647 the AC issuer; 649 - id-stc-status-check-ac-and-build-status-checked-aa-path: Build a 650 validated certification path to a trust anchor for the AC issuer 651 and perform revocation status checks on the AC as well as the 652 certification path for the AC issuer. 654 Conforming SCVP server implementations MAY support the attribute 655 certificates checks. 657 For these purposes, the following OIDs are defined: 659 id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 660 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 } 662 id-stc-build-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 } 663 id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 2 } 664 id-stc-build-status-checked-pkc-path 665 OBJECT IDENTIFIER ::= { id-stc 3 } 666 id-stc-build-aa-path OBJECT IDENTIFIER ::= { id-stc 4 } 667 id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 5 } 668 id-stc-build-status-checked-aa-path 669 OBJECT IDENTIFIER ::= { id-stc 6 } 670 id-stc-status-check-ac-and-build-status-checked-aa-path 671 OBJECT IDENTIFIER ::= { id-stc 7 } 673 3.2.3 wantBack 675 The wantBack item describes the kind of information the SCVP client 676 wants from the SCVP server for the certificate(s) in the queriedCerts 677 item. The wantBack item MUST contain a sequence of object 678 identifiers (OIDs). Each OID tells the SCVP server what the client 679 wants to know about the queriedCerts item. For each type of 680 information specified in the request, the server MUST return 681 information regarding its finding (in a successful response). 683 For example, a request might include a checks item that only 684 specifies certification path building and include a wantBack item 685 that requests the return of the certification path built by the 686 server. In this case, the response would not include a status for 687 the validation of the certification path, but it would include a 688 certification path that the server considers to be valid. A client 689 that wants to perform its own certification path validation might use 690 a request of this form. 692 Alternatively, a request might include a checks item that requests 693 the server to build a certification path and validate it, including 694 revocation checking, and include a wantBack item that requests the 695 return of the status. In this case, the response would include only 696 a status for the validation of the certification path. A client that 697 completely delegates certification path validation might use a 698 request of this form. 700 The wantBack item uses the WantBack type, which has the following 701 syntax: 703 WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 705 For public key certificates, the types of information that can be 706 requested are: 708 - id-swb-pkc-cert: The certificate that was the subject of the 709 request; 711 - id-swb-pkc-best-cert-path: The certification path built for the 712 certificate including the certificate that was validated; 714 - id-swb-pkc-revocation-info: Proof of revocation status for each 715 certificate in the certification path; 717 - id-swb-pkc-cert-status: Status indication; 719 - id-swb-pkc-public-key-info: The public key from the certificate; 720 and 722 - id-swb-pkc-all-cert-paths: A set of certification paths for the 723 certificate. 725 The SCVP protocol provides two methods for a client to obtain 726 multiple certification paths for a certificate. The client could use 727 serverContextInfo to request one path at a time (see section 3.2.6). 728 After obtaining each path, the client could submit the 729 serverContextInfo from the previous request to obtain another path 730 until the client either found a suitable path or the server indicated 731 (by not returning a serverContextInfo) that no more paths were 732 available. Alternatively, the client could send a single request 733 with an id-swb-pkc-all-cert-paths wantBack, in which case the server 734 would return all of the available paths in a single response. 736 The server may, at its discretion, limit the number of paths that it 737 returns in response to the id-swb-pkc-all-cert-paths. When the 738 request includes an id-swb-pkc-all-cert-paths wantBack, the response 739 should not include a serverContextInfo. 741 For attribute certificates, the types of information that can be 742 requested are: 744 - id-swb-ac-cert: The attribute certificate that was the subject of 745 the request; 747 - id-swb-aa-cert-path: The certification path built for the AC 748 issuer certificate; 750 - id-swb-ac-revocation-info: Proof of revocation status for each 751 certificate in the AC issuer certification path; 753 - id-swb-aa-revocation-info: Proof of revocation status for the 754 attribute certificate; and 756 - id-swb-ac-cert-status: Status indication. 758 For these purposes, the following OIDs are defined: 760 id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 761 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 } 763 id-swb-pkc-best-cert-path OBJECT IDENTIFIER ::= { id-swb 1 } 764 id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 } 765 id-swb-pkc-cert-status OBJECT IDENTIFIER ::= { id-swb 3 } 766 id-swb-pkc-public-key-info OBJECT IDENTIFIER ::= { id-swb 4 } 767 id-swb-aa-cert-path OBJECT IDENTIFIER ::= { id-swb 5 } 768 id-swb-aa-revocation-info OBJECT IDENTIFIER ::= { id-swb 6 } 769 id-swb-ac-revocation-info OBJECT IDENTIFIER ::= { id-swb 7 } 770 id-swb-ac-cert-status OBJECT IDENTIFIER ::= { id-swb 8 } 771 id-swb-pkc-cert OBJECT IDENTIFIER ::= { id-swb 10} 772 id-swb-ac-cert OBJECT IDENTIFIER ::= { id-swb 11} 773 id-swb-pkc-all-cert-paths OBJECT IDENTIFIER ::= { id-swb 12} 775 3.2.4 validationPolicy 777 The validationPolicy item defines the validation policy that the 778 client wants the SCVP server to use during certificate validation. 779 If this policy cannot be used for any reason, then the server MUST 780 return an error response. 782 A validation policy MUST define default values for all parameters 783 necessary for processing an SCVP request. For each parameter, a 784 validation policy may either allow the client to specify a non- 785 default value or forbid the use of a non-default value. If the 786 client wishes to use the default values for all of the parameters, 787 then the client need only supply a reference to the policy in this 788 item. If the client wishes to use non-default values for one or more 789 parameters, then the client supplies a reference to the policy plus 790 whatever parameters are necessary to complete the request in this 791 item. If there are any conflicts between the policy referenced in 792 the request and any supplied parameter values in the request, then 793 the server MUST return an error response. 795 The syntax of the validationPolicy item is: 797 ValidationPolicy ::= SEQUENCE { 798 validationPolRef ValidationPolRef, 799 validationAlg [0] ValidationAlg OPTIONAL, 800 userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT 801 IDENTIFIER OPTIONAL, 802 inhibitPolicyMapping [2] BOOLEAN OPTIONAL, 803 requireExplicitPolicy [3] BOOLEAN OPTIONAL, 804 inhibitAnyPolicy [4] BOOLEAN OPTIONAL, 805 trustAnchors [6] TrustAnchors OPTIONAL, 806 keyUsages [7] KeyUsages OPTIONAL, 807 extendedKeyUsages [8] SEQUENCE OF KeyPurposeId OPTIONAL} 809 The validationPolRef item is required, but the remaining items are 810 optional. The optional items are used to provide validation policy 811 parameters. When the client uses the validation policy's default 812 values for all parameters, all of the optional items are absent. The 813 validationAlg item specifies the validation algorithm. The 814 userPolicySet item provides an acceptable set of certificate 815 policies. The inhibitPolicyMapping item inhibits certificate policy 816 mapping during certification path validation. The 817 requireExplicitPolicy item requires at least one valid certificate 818 policy in the certificate policies extension. The inhibitAnyPolicy 819 item indicates whether the anyPolicy certificate policy OID is 820 processed or ignored when evaluating certificate policy. The 821 trustAnchors item indicates the trust anchors that are acceptable to 822 the client. The keyUsages item indicates the technical usage of the 823 public key that is to be confirmed by the server as acceptable. The 824 extendedKeyUsages item indicates the application-specific usage of 825 the public key that is to be confirmed by the server as acceptable. 826 The syntax and semantics of each of these items is discussed in the 827 following sections. 829 3.2.4.1 validationPolRef 831 The reference to the validation policy can be either an OID or a URI. 832 In either case, the client and server have agreed that the value 833 represents a particular validation policy. The URI can point to a 834 human readable definition of the policy to facilitate correct 835 configuration. 837 The syntax of the ValidationPolRef item is: 839 ValidationPolRef::= CHOICE { 840 valPolRefByOID OBJECT IDENTIFIER, 841 valPolRefByURI IA5String} 843 There is no requirement for either the client or the server to 844 dereference the URI during SCVP request processing. The URI is 845 simply used as a reference for the validation policy. Clients and 846 server MAY dereference the URI as part of configuration. 848 3.2.4.1.1 Default Validation Policy 849 The client can request the SCVP server's default validation policy or 850 another validation policy. The object identifier to identify the 851 default validation policy is: 853 id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 854 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 } 856 id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 } 858 The default validation policy MUST use the basic validation algorithm 859 as its default validation algorithm (see section 3.2.4.2.1). 861 When using the default validation policy, the client can override any 862 of the default parameter values by supplying a specific value in the 863 request. The SCVP server MUST make use of the provided parameter 864 values or return an error response. 866 Conforming implementations of SCVP servers MUST support the default 867 policy. However, an SCVP server may be configured to send an error 868 response to all requests using the default policy to meet local 869 security requirements. 871 3.2.4.2 validationAlg 873 The optional validationAlg item defines the validation algorithm to 874 be used by the SCVP server during certificate validation. The value 875 of this item can be determined by agreement between the client and 876 the server. The validation algorithm is represented by an object 877 identifier. 879 The syntax of the validationAlg is: 881 ValidationAlg ::= SEQUENCE { 882 valAlgId OBJECT IDENTIFIER, 883 parameters ANY DEFINED BY valAlgId OPTIONAL } 885 The following section specifies the basic validation algorithm and 886 the name validation algorithm. 888 SCVP clients and servers MUST support both validation algorithms 889 defined in this section. Other validation algorithms can be 890 specified in other documents for use with specific applications. 891 SCVP clients and servers MAY support any such validation algorithms. 893 3.2.4.2.1 Basic Validation Algorithm 895 The client can request use of the SCVP basic validation algorithm or 896 another algorithm. For identity certificates, the basic validation 897 algorithm MUST implement the certification path validation algorithm 898 as defined in section 6 of [PKIX-1]. For attribute certificates, the 899 basic validation algorithm MUST implement certificate path validation 900 as defined in section 5 of [PKIX-AC]. Other validation algorithms 901 MAY implement functions over and above those in the basic algorithm, 902 but validation algorithms MUST generate results compliant with the 903 basic validation algorithm. That is, none of the validation 904 requirements in the basic algorithm may be omitted from any newly 905 defined validation algorithms. However, other validation algorithms 906 MAY reject paths that are valid using the basic validation algorithm. 907 The object identifier to identify the basic validation algorithm is: 909 id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 } 911 When id-svp-basicValAlg appears in valAlgId, the parameters item MUST 912 be absent. 914 3.2.4.2.2 Basic Validation Algorithm Errors 916 The following errors are defined for the basic validation algorithm 917 for inclusion in the validationErrors item in the response (see 918 section 4.9.6). These errors can be used by any other validation 919 algorithm since all validation algorithms MUST implement the 920 functionality of the basic validation algorithm. 922 id-bvae OBJECT IDENTIFIER ::= id-svp-basicValAlg 924 id-bvae-expired OBJECT IDENTIFIER ::= { id-bvae 1 } 925 id-bvae-not-yet-valid OBJECT IDENTIFIER ::= { id-bvae 2 } 926 id-bvae-wrong-anchor OBJECT IDENTIFIER ::= { id-bvae 3 } 927 id-bvae-invalid-key-usage OBJECT IDENTIFIER ::= { id-bvae 10 } 928 id-bvae-invalid-purpose OBJECT IDENTIFIER ::= { id-bvae 11 } 929 id-bvae-revoked OBJECT IDENTIFIER ::= { id-bvae 16 } 931 The id-bvae-expired value means that the validation time used for the 932 request was later than the notAfter time in the end certificate. 934 The id-bvae-not-yet-valid value means that the validation time used 935 for the request was before the notBefore time in the end certificate. 937 The id-bvae-wrong-anchor value means that a certification path could 938 not be constructed for the client specified trust anchor(s), but a 939 path exists for one of the trust anchors specified in the server's 940 default validation policy. 942 The id-bvae-invalid-key-usage value means that the keyUsage extension 943 (PKIX-1 section 4.2.1.3) in the end certificate does not satisfy the 944 validation policy. For example, the keyUsage extension in the 945 certificate may assert only the keyEncipherment bit, but the 946 validation policy specifies in the keyUsages field that 947 digitalSignature is required. 949 The id-bvae-invalid-purpose value means that the extended key usage 950 extension (PKIX-1 section 4.2.1.13) in the end certificate does not 951 satisfy the validation policy. 953 The id-bvae-revoked value means that the end certificate was revoked. 955 3.2.4.2.3 Name Validation Algorithm 957 The name validation is a refinement of the basic validation algorithm 958 that allows the client to specify one or more subject names that MUST 959 appear in the end certificate. The name validation algorithm allows 960 the client to supply an application identifier and a name to the 961 server. The application identifier defines the name matching rules 962 to use in comparing the name supplied in the request with the names 963 in the certificate. 965 id-svp-nameValAlg OBJECT IDENTIFIER ::= { id-svp 2 } 967 When the id-svp-nameValAlg appears as a valAlgId, the parameters MUST 968 use the NameValidationAlgParms syntax: 970 NameValidationAlgParms ::= SEQUENCE { 971 nameCompAlgId OBJECT IDENTIFIER, 972 validationNames GeneralNames } 974 GeneralNames is defined in [PKIX-1]. 976 If more than one name is supplied in the validationNames value, all 977 names MUST be of the same type. The certificate must contain a 978 matching name for each of the names supplied in validationNames 979 according to the name matching rules associated with the 980 nameCompAlgId. This specification defines three sets of name 981 matching rules. 983 If the nameCompAlgId supplied in the request is id-nva-dnCompAlg, 984 then GeneralNames supplied in the request MUST be a directoryName, 985 and the matching rules to be used are defined in [PKIX-1]. The 986 certificate must contain a matching name in either the subject field 987 or a directoryName in the subjectAltName extension. This 988 specification defines the OID for id-nva-dnCompAlg as follows: 990 id-nva-dnCompAlg OBJECT IDENTIFIER ::= { id-svp 4 } 992 If the nameCompAlgId supplied in the request is id-kp-serverAuth 993 [PKIX-1], then GeneralNames supplied in the request MUST be a 994 dNSName, and the matching rules to be used are defined in [HTTP-TLS]. 996 If the nameCompAlgId supplied in the request is id-kp-mailProtection 997 [PKIX-1], then GeneralNames supplied in the request MUST be an 998 rfc822Name, and the matching rules are defined in [SMIME-CERT]. 1000 Conforming SCVP servers MUST support the name validation algorithm 1001 and the matching rules associated with id-nva-dnCompAlg, id-kp- 1002 serverAuth, id-kp-mailProtection. SCVP server MAY support other name 1003 matching rules. 1005 3.2.4.2.4 Name Validation Algorithm Errors 1007 The following errors are defined for the Name Validation Algorithm: 1009 id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg 1011 id-nvae-name-mismatch OBJECT IDENTIFIER ::= { id-nvae 1 } 1012 id-nvae-no-name OBJECT IDENTIFIER ::= { id-nvae 2 } 1013 id-nvae-unknown-alg OBJECT IDENTIFIER ::= { id-nvae 3 } 1014 id-nvae-bad-name OBJECT IDENTIFIER ::= { id-nvae 4 } 1015 id-nvae-bad-name-type OBJECT IDENTIFIER ::= { id-nvae 5 } 1016 id-nvae-mixed-names OBJECT IDENTIFIER ::= { id-nvae 6 } 1018 The id-nvae-name-mismatch value means the client supplied a name with 1019 the request, which the server recognized and the server found 1020 corresponding name type in the certificate, but was unable to find a 1021 match to the name supplied. For example, the client supplied a DNS 1022 name of example1.com, the certificate contained a DNS name of 1023 example.com. 1025 The id-nvae-no-name value means the client supplied a name with the 1026 request, which the server recognized, but the server could not find 1027 the corresponding name type in the certificate. For example, the 1028 client supplied a DNS name of example1.com, the certificate only 1029 contained a rfc822Name of user@example.com. 1031 The id-nvae-unknown-alg value means the client supplied a 1032 nameCompAlgId which the server does not recognize. 1034 The id-nvae-bad-name value means the client supplied either an empty 1035 or malformed name in the request. 1037 The id-nvae-bad-name-type value means the client supplied an 1038 inappropriate name type for the application identifier. For example, 1039 the client specified a nameCompAlgId of id-kp-serverAuth, and an 1040 rfc822Name of user@example.com. 1042 The id-nvae-mixed-names value means the client supplied multiple 1043 names in the request of different types. 1045 3.2.4.3 userPolicySet 1047 The userPolicySet item specifies a list of certificate policy 1048 identifiers that the SCVP server MUST use when constructing and 1049 validating a certification path. The userPolicySet item specifies 1050 the user-initial-policy-set as defined in Section 6 of [PKIX-1]. A 1051 userPolicySet containing the anyPolicy OID indicates a user-initial- 1052 policy-set of any-policy. 1054 SCVP clients SHOULD support userPolicySet item in requests, and SCVP 1055 servers MUST support userPolicySet item in requests. 1057 3.2.4.4 inhibitPolicyMapping 1059 The inihibitPolicyMapping item specifies an input to the 1060 certification path validation algorithm, and it controls whether 1061 policy mapping is allowed during certification path validation (see 1062 [PKIX-1], section 6.1.1). If the client wants the server to inhibit 1063 policy mapping, inhibitPolicyMapping is set to TRUE in the request. 1065 SCVP clients MAY support inhibiting policy mapping. SCVP servers 1066 SHOULD support inhibiting policy mapping. 1068 3.2.4.5 requireExplicitPolicy 1070 The requireExplicitPolicy item specifies an input to the 1071 certification path validation algorithm, and it controls whether 1072 there must be at least one valid policy in the certificate policies 1073 extension (see [PKIX-1], section 6.1.1). If the client wants the 1074 server to require at least one policy, requireExplicitPolicy is set 1075 to TRUE in the request. 1077 SCVP clients MAY support requiring explicit policies. SCVP servers 1078 SHOULD support requiring explicit policies. 1080 3.2.4.6 inhibitAnyPolicy 1082 The inhibitAnyPolicy item specifies an input to the certification 1083 path validation algorithm (see [PKIX-1], section 6.1.1), and it 1084 controls whether the anyPolicy OID is processed or ignored when 1085 evaluating certificate policy. If the client wants the server to 1086 ignore the anyPolicy OID, inhibitAnyPolicy MUST be set to TRUE in the 1087 request. 1089 SCVP clients MAY support ignoring the anyPolicy OID. SCVP servers 1090 SHOULD support ignoring the anyPolicy OID. 1092 3.2.4.7 trustAnchors 1094 The trustAnchors item specifies the trust anchors at which the 1095 certification path must terminate if the path is to be considered 1096 valid by the SCVP server for the request. If a trustAnchors item is 1097 present, the server MUST NOT consider any certification paths ending 1098 in other trust anchors as valid. 1100 The TrustAnchors type contains one or more trust anchor 1101 specifications. A certificate reference can be used to identify the 1102 trust anchor by certificate hash and optionally a distinguished name 1103 with serial number. Alternatively, trust anchors can be provided 1104 directly. The order of trust anchor specifications within the 1105 sequence is not important. Any CA certificate that meets the 1106 requirements of [PKIX-1] for signing certificates can be provided as 1107 a trust anchor. If a trust anchor is supplied which does not meet 1108 these requirements, the server MUST return an error response. 1110 The trust anchor itself, regardless of its form, MUST NOT be included 1111 in any certification path returned by the SCVP server. 1113 TrustAnchors has the following syntax: 1115 TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF PKCReference 1117 SCVP server MUST support trustAnchors. SCVP clients SHOULD support 1118 trustAnchors. 1120 3.2.4.8 keyUsages 1122 The key usage extension [PKIX-1, section 4.2.1.3] in the certificate 1123 defines the technical purpose (such as encipherment, signature, and 1124 certificate signing) of the key contained in the certificate. If the 1125 client wishes to confirm the technical usage, then it can communicate 1126 the usage it wants to validate by the same structure using the same 1127 semantics as defined in [PKIX-1]. Therefore, if the client obtained 1128 the certificate in the context of a digital signature, it can confirm 1129 this use by including a keyUsage structure with the digital signature 1130 bit set. 1132 KeyUsages ::= CHOICE { 1133 anyKeyUsage NULL, 1134 requiredKeyUsages SEQUENCE SIZE (1..MAX) OF KeyUsage } 1136 The keyUsages item may indicate either the particular key usages that 1137 are required by the client or that the client does not require any 1138 particular key usage. 1140 The requiredKeyUsages item can contain one or more keyUsage 1141 definitions to allow the client to search for a set of patterns any 1142 one of which is acceptable to the client. If the client wishes to 1143 match against multiple possibilities then the client passes in a 1144 sequence of possible patterns. Each keyUsage can contain a set of 1145 one or more bits set in the request, all bits MUST be present in the 1146 certificate to match against an instance of the keyUsage in the SCVP 1147 request. If the certificate key usage extension contains more usages 1148 than requested, then the certificate MUST be considered a match. 1149 Therefore if a client wishes to check for either digital signature or 1150 non-repudiation, then the client provides two keyUsage values, one 1151 with digital signature set and the other with non-repudiation set. 1152 If the key usage extension is absent from the certificate, the 1153 certificate MUST be considered good for all usages and therefore any 1154 pattern in the SCVP request will match. 1156 SCVP clients SHOULD support keyUsages, and SCVP servers MUST support 1157 keyUsages. 1159 3.2.4.9 extendedKeyUsages 1161 The extended key usage extension [PKIX-1, section 4.2.1.13] defines 1162 more specific technical purposes, in addition to or in place of the 1163 purposes indicated in the key usage extension, for which the 1164 certified public key may be used. If the client wishes to confirm 1165 the extended key usage, then it can communicate the usage it wants to 1166 validate by the same extension using the same semantics as defined in 1167 [PKIX-1]. Therefore if the client obtained the certificate in the 1168 context of a TLS server, it can confirm this usage by including the 1169 extended key usage structure with the id-kp-serverAuth object 1170 identifier. If the extension is absent or is present and asserts the 1171 anyExtendedKeyUsage OID, then all usages specified in the request are 1172 a match. If the extension is present and more than one usage is set 1173 in the request, all usages MUST be present in the certificate. If 1174 the certificate extension contains more usages than requested, then 1175 the certificate MUST be considered a match. 1177 Where the client does not require any particular extended key usage, 1178 the client can specify an empty SEQUENCE. This may be used to 1179 override extended key usage requirements imposed in the validation 1180 policy specified by validationPolRef. 1182 SCVP clients SHOULD support extendedKeyUsages, and SCVP servers MUST 1183 support extendedKeyUsages. 1185 3.2.5 responseFlags 1187 The optional response flags item allows the client to indicate which 1188 optional features in the CVResponse it wants the server to include. 1190 If the default values for all of the flags are used, then the 1191 response flags item MUST NOT be included in the request. 1193 The syntax of the responseFlags is: 1195 ResponseFlags ::= SEQUENCE { 1196 fullRequestInResponse [0] BOOLEAN DEFAULT FALSE, 1197 responseValidationPolByRef [1] BOOLEAN DEFAULT TRUE, 1198 protectResponse [2] BOOLEAN DEFAULT TRUE, 1199 cachedResponse [3] BOOLEAN DEFAULT TRUE } 1201 Each of the response flags is described in the following sections. 1203 3.2.5.1 fullRequestInResponse 1205 By default, the server includes a hash of the request in non-cached 1206 responses to allow the client to identify the response. If the 1207 client wants the server to include the full request in the non-cached 1208 response, fullRequestInResponse is set to TRUE. The main reason a 1209 client would request the server to include the full request in the 1210 response is to archive the request-response exchange in a single 1211 object. That is, the client wants to archive a single object that 1212 includes both request and response. 1214 SCVP clients and servers MUST support the default behavior. SCVP 1215 clients MAY support requesting and processing the full request. SCVP 1216 servers SHOULD support returning the full request. 1218 3.2.5.2 responseValidationPolByRef 1220 The responseValidationPolByRef item controls whether the response 1221 includes just a reference to the policy or a reference to the policy 1222 plus all the parameters by value of the policy used to process the 1223 request. The response MUST contain a reference to the validation 1224 policy. If the client wants the validation policy parameters to be 1225 also included by value, then responseValidationPolByRef is set to 1226 FALSE. The main reason a client would request the server to include 1227 validation policy to be included by value is to archive the request- 1228 response exchange in a single object. That is, the client wants to 1229 archive the CVResponse and have it include every aspect of the 1230 validation policy. 1232 SCVP clients and servers MUST support the default behavior. SCVP 1233 clients MAY support requesting and processing the validation policy 1234 by values. SVCP server SHOULD support returning the validation 1235 policy by values. 1237 3.2.5.3 protectResponse 1238 The protectResponse item indicates whether the client requires the 1239 server to protect the response. If the client is performing full 1240 certification path validation on the response and it is not concerned 1241 about the source of the response, then the client does not benefit 1242 from a digital signature or MAC on the response. In this case, the 1243 client can indicate to the server that protecting the message is 1244 unnecessary. However, the server is always permitted to return a 1245 protected response. 1247 SCVP clients that support delegated path discovery (DPD) as defined 1248 in [RQMTS] MUST support setting this value to FALSE. 1250 SCVP clients that support delegated path validation (DPV) as defined 1251 in [RQMTS] require an authenticated response. Unless a protected 1252 transport mechanism (such a TLS) is used, such clients MUST always 1253 set this value to TRUE or omit the responseFlags item entirely, which 1254 requires the server to return a protected response. 1256 SCVP servers MUST support returning protected responses, and SCVP 1257 servers SHOULD support returning unprotected responses. Based on 1258 local policy, the server can be configured to return protected or 1259 unprotected responses if this value is set to FALSE. If based on 1260 local policy the server is unable to return protected responses, then 1261 the server MUST return an error if this value is set to TRUE. 1263 3.2.5.4 cachedResponse 1265 The cachedResponse item indicates whether the client will accept a 1266 cached response. To enhance performance and limit the exposure of 1267 signing keys, an SCVP service may be designed to cache responses 1268 until new revocation information is expected. Where cachedResponse 1269 is set to TRUE, the client will accept a previously cached response. 1271 Clients may insist on creation of a fresh response to protect against 1272 a replay attack and ensure information is up to date. Where 1273 cachedResponse is FALSE, the client will not accept a cached 1274 response. To ensure that a response is fresh, the client MUST also 1275 include the requestNonce as defined in Section 3.4. 1277 Servers MUST process the cachedResponse flag. Where cachedResponse 1278 is FALSE, servers that cannot produce fresh responses MUST reply with 1279 an error message. Servers MAY choose to provide fresh responses even 1280 where cachedResponse is set to TRUE. 1282 3.2.6 serverContextInfo 1284 The optional serverContextInfo item, if present, contains context 1285 from a previous request-response exchange with the same SCVP server. 1286 It allows the server to return more than one certification path for 1287 the same certificate to the client. For example, if a server 1288 constructs a particular certification path for a certificate, but the 1289 client finds it unacceptable, the client can then send the same query 1290 back to the server with the serverContextInfo from the first 1291 response, and the server will be able to provide a different 1292 certification path (if another one can be found). 1294 Contents of the serverContextInfo are opaque to the SCVP client. 1295 That is, the client only knows that it needs to return the value 1296 provided by the server with the subsequent request to get a different 1297 certification path. Note that the subsequent query needs to be 1298 identical to the previous query with the exception of the following: 1300 - requestNonce; 1302 - serverContextInfo; and 1304 - the client's digital signature or MAC on the request. 1306 SCVP clients MAY support serverContextInfo, and SCVP servers SHOULD 1307 support serverContextInfo. 1309 3.2.7 valididationTime 1311 The optional validationTime item, if present, tells the date and time 1312 relative to which the SCVP client wants the server to perform the 1313 checks. If the validationTime is not present, the server MUST 1314 perform the validation using the date and time at which the server 1315 processes the request. If the validationTime is present, it MUST be 1316 encoded as GeneralizedTime. The validationTime provided MUST be a 1317 retrospective time since the server can only perform a validity check 1318 using the current time (default) or previous time. A server can 1319 ignore the validationTime provided in the request if the time is 1320 within the clock skew of the server's current time. 1322 The revocation status information is obtained with respect to the 1323 validation time. When specifying a validation time other than the 1324 current time, the validation time should not necessarily be identical 1325 to the time when the private key was used. The validation time 1326 specified by the client may be adjusted to compensate for: 1328 1) time for the end-entity to realize that its private key has 1329 been or could possibly be compromised, and/or 1331 2) time for the end-entity to report the key compromise, and/or 1333 3) time for the revocation authority to process the revocation 1334 request from the end-entity, and/or 1336 4) time for the revocation authority to update and distribute the 1337 revocation status information. 1339 GeneralizedTime values MUST be expressed in Universal Coordinated 1340 Time (UTC) (which is also known as Greenwich Mean Time and Zulu time) 1341 and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even when 1342 the number of seconds is zero. GeneralizedTime values MUST NOT 1343 include fractional seconds. 1345 The information in the corresponding CertReply item in the response 1346 MUST be formatted as if the server created the response at the time 1347 indicated in the validationTime. However, if the server does not 1348 have appropriate historical information, the server MUST return an 1349 error response. 1351 SCVP servers MUST apply a clock skew to the validity time to allow 1352 for minor time synchronization errors. The default value is 10 1353 minutes. If the server uses a value other than the default it MUST 1354 include the clock skew value in the validation policy response. 1356 SCVP clients MAY support validationTime other than the current time. 1357 SCVP servers MUST support using its current time, and SHOULD support 1358 the client setting the validationTime in the request. 1360 3.2.8 intermediateCerts 1362 The optional intermediateCerts item may help the SCVP server create 1363 valid certification paths. The intermediateCerts item, when present, 1364 provides certificates that the server MAY use when forming a 1365 certification path. When building certification paths, the server 1366 MAY use the certificates in the intermediateCerts item in addition to 1367 any other certificates that the server can access. When present, the 1368 intermediateCerts item MUST contain at least one certificate, and the 1369 intermediateCerts item MUST be structured as a CertBundle. The 1370 certificates in the intermediateCerts item MUST NOT be considered as 1371 valid by the server just because they are present in this item. 1373 The CertBundle type contains one or more certificates. The order of 1374 the entries in the bundle is not important. CertBundle has the 1375 following syntax: 1377 CertBundle ::= SEQUENCE SIZE (1..MAX) OF Certificate 1379 SCVP clients SHOULD support intermediateCerts, and SCVP servers MUST 1380 support intermediateCerts. 1382 3.2.9 revInfos 1383 The optional revInfos item specifies revocation information such as 1384 CRLs, delta CRLs [PKIX-1], and OCSP responses [OCSP] that the SCVP 1385 server MAY use when validating certification paths. The purpose of 1386 the revInfos item is to provide revocation information to which the 1387 server might not otherwise have access, such as an OCSP response that 1388 the client received along with the certificate. Note that the 1389 information in the revInfos item might not be used by the server. 1390 For example, the revocation information might be associated with 1391 certificates that the server does not use in the certification path 1392 that it constructs. 1394 Clients SHOULD be courteous to the SCVP server by separating CRLs and 1395 delta CRLs. However, since the two share a common syntax, SCVP 1396 servers SHOULD accept delta CRLs even if they are identified as 1397 regular CRLs by the SCVP client. 1399 CRLs, delta CRLs, and OCSP responses can be provided as revocation 1400 information. If needed, additional object identifiers can be 1401 assigned for additional revocation information types in the future. 1403 The revInfos item uses the RevocationInfos type, which has the 1404 following syntax: 1406 RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo 1408 RevocationInfo ::= CHOICE { 1409 crl [0] CertificateList, 1410 delta-crl [1] CertificateList, 1411 ocsp [2] OCSPResponse, 1412 other [3] OtherRevInfo } 1414 OtherRevInfo ::= SEQUENCE { 1415 riType OBJECT IDENTIFIER, 1416 riValue ANY DEFINED BY riType } 1418 3.2.10 producedAt 1420 The client MAY allow the server to use a cached SCVP response. When 1421 doing so, the client MAY use the producedAt item to express 1422 requirements on the freshness of the cached response. The producedAt 1423 item tells the earliest date and time at which an acceptable cached 1424 response could have been produced. The producedAt item represents 1425 the date and time in UTC, using the GeneralizedTime type. The value 1426 in the producedAt item is independent of the validation time. 1428 GeneralizedTime value MUST be expressed in UTC, as defined in section 1429 3.2.7. 1431 SCVP client MAY support using producedAt values in the request. SCVP 1432 server MAY support the producedAt values in the request. SCVP 1433 servers that support cached responses SHOULD support the producedAt 1434 value in requests. 1436 3.2.11 queryExtensions 1438 The optional queryExtensions item contains Extensions. If present, 1439 each extension in the sequence extends the query. This specification 1440 does not define any extensions; the facility is provided to allow 1441 future specifications to extend SCVP. The syntax for extensions is 1442 imported from [PKIX-1]. The queryExtensions item, when present, MUST 1443 contain a sequence of extension items, and each of the extensions 1444 MUST contain extnID, critical, and extnValue items. Each of these is 1445 described in the following sections. 1447 3.2.11.1 extnID 1449 The extnID item is an identifier for the extension. It contains the 1450 object identifier that names the extension. 1452 3.2.11.2 critical 1454 The critical item is a BOOLEAN. Each extension is designated as 1455 either critical (with a value of TRUE) or non-critical (with a value 1456 of FALSE). By default, the extension is non-critical. An SCVP 1457 server MUST reject the query if it encounters a critical extension 1458 that it does not recognize; however, a non-critical extension MAY be 1459 ignored if it is not recognized, but MUST be processed if it is 1460 recognized. 1462 3.2.11.3 extnValue 1464 The extnValue item is an octet string, which contains the extension 1465 value. An ASN.1 type is specified for each extension, identified by 1466 the associated extnID object identifier. 1468 3.3 requestorRef 1470 The optional requestorRef item contains a SEQUENCE of OCTET STRINGs 1471 identifying SCVP servers, and it is intended for use in environments 1472 where SCVP relay is employed. As described in [RQMTS], in some 1473 network environments an SCVP server might not be able to obtain all 1474 of the information that it needs to process a request. However, the 1475 SCVP server might be configured to use the services of one or more 1476 other SCVP servers to fulfill all requests. In such cases, the 1477 client is unaware that the queried SCVP server is using the services 1478 of other SCVP servers, and the client-queried SCVP server acts as an 1479 SCVP client to another SCVP server. Unlike the original client, the 1480 SCVP server is expected to have moderate computing and memory 1481 resources, enabling the use of relay, re-direct or multicasting 1482 mechanisms. The requestorRef item is used to detect looping in some 1483 configurations. The value and use of requestorRef is defined in 1484 section 7. To detect loops, the server MUST inspect the sequence 1485 of octet strings, looking for values that it inserted as a client. 1487 If the SCVP client includes a requestorRef value in the request, then 1488 the SCVP server MUST return the same value in a non-cached response. 1489 The SCVP server MAY omit the requestorRef value from cached SCVP 1490 responses. 1492 The requestorRef item MUST be a sequence of octet strings. No 1493 provisions are made to ensure uniqueness of the requestorRef octet 1494 strings. 1496 3.4 requestNonce 1498 The optional requestNonce item contains a request identifier 1499 generated by the SCVP client. If the client includes a requestNonce 1500 value in the request, it is expressing a preference that the SCVP 1501 server SHOULD return a non-cached response. If the server returns a 1502 non-cached response it MUST include the value of requestNonce from 1503 the request in the response as the respNonce field; however, the 1504 server MAY return a cached response which MUST NOT have a respNonce. 1506 If the client includes a requestNonce and also sets the 1507 cachedResponse flag to FALSE as defined in section 3.2.5.4, the 1508 client is indicating that the SCVP server MUST return either a non- 1509 cached response including the respNonce or an error response. The 1510 client SHOULD include a requestNonce item in every request to prevent 1511 an attacker from acting as a man-in-the-middle by replaying old 1512 responses from the server. The requestNonce value SHOULD change with 1513 every request sent by the client. 1515 The client MUST NOT set the cachedResponse flag to FALSE without also 1516 including a requestNonce. A server receiving such a request SHOULD 1517 return an invalidRequest error response. 1519 The requestNonce item, if present, MUST be an octet string that was 1520 generated exclusively for this request. 1522 3.5 requestorName 1524 The optional requestorName item is used by the client to include an 1525 identifier in the request. The client MAY include this information 1526 for the DPV server to copy into the response. 1528 SCVP servers MUST be able to process requests that include this 1529 field. 1531 3.6 requestExtensions 1533 The OPTIONAL requestExtensions item contains Extensions. If present, 1534 each Extension in the sequence extends the request. This 1535 specification does not define any extensions; the facility is 1536 provided to allow future specifications to extend SCVP. The syntax 1537 for Extensions is imported from [PKIX-1]. The requestExtensions 1538 item,when present, MUST contain a sequence of extension items, and 1539 each of extension MUST contain extnID, critical, and extnValue items. 1540 Each of these is described in the following sections. 1542 3.6.1 extnID 1544 The extnID item is an identifier for the extension. It contains the 1545 object identifier that names the extension. 1547 3.6.2 critical 1549 The critical item is a BOOLEAN. Each extension is designated as 1550 either critical (with a value of TRUE) or non-critical (with a value 1551 of FALSE). By default, the extension is non-critical. An SCVP 1552 server MUST reject the query if it encounters a critical extension it 1553 does not recognize. A non-critical extension MAY be ignored if it is 1554 not recognized, but MUST be processed if it is recognized. 1556 3.6.3 extnValue 1558 The extnValue item contains an octet string. Within the octet string 1559 is the extension value. An ASN.1 type is specified for each 1560 extension, identified by the associated extnID object identifier. 1562 3.7 SCVP Request Authentication 1564 It is a matter of local policy what validation policy the server uses 1565 when authenticating requests. When authenticating protected SCVP 1566 requests, the SCVP servers SHOULD use the validation algorithm 1567 defined in section 6 of [PKIX-1]. 1569 If the certificate used to validate a SignedData validation request 1570 includes the key usage extension [PKIX-1, section 4.2.1.3], it MUST 1571 have either the digital signature bit set, the non-repudiation bit 1572 set, or both bits set. 1574 If the certificate used to validate an AuthenticatedData validation 1575 request includes the key usage extension, it MUST have the key 1576 agreement bit set. 1578 If the certificate used on a validation request contains the extended 1579 key usage extension [PKIX-1, section 4.2.1.13], the server SHALL 1580 verify that it contains the SCVP client OID or another OID acceptable 1581 to the server. The SCVP client OID is defined as follows: 1583 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 1585 id-kp-scvpClient OBJECT IDENTIFIER ::= { id-kp 16 } 1587 If a protected request fails to meet the validation policy of the 1588 server, it MUST be treated as an unauthenticated request. 1590 4 Validation Response 1592 An SCVP server response to the client MUST be a single CVResponse 1593 item. When a CVResponse is encapsulated in a MIME body part, 1594 application/cv-response MUST be used. 1596 There are a number of forms of an SCVP response: 1598 1. A success response to a request made over a protected transport 1599 such as TLS. These responses SHOULD NOT be protected by the 1600 server. 1602 2. A success response to a request that has protectResponse set to 1603 FALSE. These responses SHOULD NOT be protected by the server. 1605 3. The server MUST protect all other success responses. If the 1606 server is unable to return a protected success response due to 1607 local policy, then it MUST return an error response. 1609 4. An error response to a request made over a protected transport 1610 such as TLS. These responses SHOULD NOT be protected by the 1611 server 1613 5. An error response to a request that has protectResponse set to 1614 FALSE. These responses SHOULD NOT be protected by the server. 1616 6. An error response to an authenticated request. The server MUST 1617 protect these responses. 1619 7. An error response to an AuthenticatedData request where MAC is 1620 valid. The server MUST protect these responses. 1622 8. All other error responses MUST NOT be protected by the server. 1624 Successful responses are made when the server has fully complied with 1625 the request. That is, the server was able to build a certification 1626 path using the referenced or supplied validation policy, and it was 1627 able to comply with all the requested parameters. If the server is 1628 unable to perform validations using the required validation policy or 1629 the request contains an unsupported option, then the server MUST 1630 return an error response. 1632 For protected requests and responses, SCVP servers MUST support 1633 SignedData and SHOULD support AuthenticatedData. It is a matter of 1634 local policy which types are used. 1636 If the server is making a protected response to a protected request, 1637 then the server MUST use the same protection mechanism (SignedData or 1638 AuthenticatedData) as in the request. 1640 An overview of the structure used for an unprotected response is 1641 provided below. Many details are not shown, but the way that SCVP 1642 makes use of CMS is clearly illustrated. 1644 ContentInfo { 1645 contentType id-ct-scvp-certValResponse, 1646 -- (1.2.840.113549.1.9.16.1.11) 1647 content CVResponse } 1649 The protected response consists of a CVResponse encapsulated in 1650 either a SignedData or an AuthenticatedData, which is in turn 1651 encapsulated in a ContentInfo. An overview of the structure used for 1652 a protected response is provided below. As above, many details are 1653 not shown, but the way that SCVP makes use of CMS is clearly 1654 illustrated. 1656 SignedData Example: 1658 ContentInfo { 1659 contentType id-signedData, -- (1.2.840.113549.1.7.2) 1660 content SignedData } 1662 SignedData { 1663 version CMSVersion, 1664 digestAlgorithms DigestAlgorithmIdentifiers, 1665 encapContentInfo EncapsulatedContentInfo, 1666 certificates [0] IMPLICIT CertificateSet OPTIONAL, 1667 -- MUST include server cert 1668 crls [1] IMPLICIT CertificateRevocationLists 1669 OPTIONAL, 1670 signerInfos SET OF SignerInfos } -- Only one in SCVP 1672 SignerInfo { 1673 version CMSVersion, 1674 sid SignerIdentifier, 1675 digestAlgorithm DigestAlgorithmIdentifier, 1676 signedAttrs SignedAttributes, -- Required by CMS 1677 signatureAlgorithm SignatureAlgorithmIdentifier, 1678 signature SignatureValue, 1679 unsignedAttrs UnsignedAttributes } -- Not used in SCVP 1681 EncapsulatedContentInfo { 1682 eContentType id-ct-scvp-certValResponse, 1683 -- (1.2.840.113549.1.9.16.1.11) 1684 eContent OCTET STRING } -- Contains CVResponse 1686 AuthenticatedData Example: 1688 ContentInfo { 1689 contentType id-ct-authData, 1690 -- (1.2.840.113549.1.9.16.1.2) 1691 content AuthenticatedData } 1693 AuthenticatedData ::= SEQUENCE { 1694 version CMSVersion, 1695 originatorInfo OriginatorInfo, 1696 recipientInfos RecipientInfos, -- Only for SCVP client 1697 macAlgorithm MessageAuthenticationCodeAlgorithm, 1698 digestAlgorithm DigestAlgorithmIdentifier, 1699 encapContentInfo EncapsulatedContentInfo, 1700 authAttrs AuthAttributes, -- Required by CMS 1701 mac MessageAuthenticationCode, 1702 unauthAttrs UnauthAttributes } -- Not used in SCVP 1704 EncapsulatedContentInfo { 1705 eContentType id-ct-scvp-certValResponse, 1706 -- (1.2.840.113549.1.9.16.1.11) 1707 eContent OCTET STRING } -- Contains CVResponse 1709 The SCVP server MUST include its own certificate in the certificates 1710 field within SignedData. Other certificates MAY also be included. 1711 The SCVP server MAY also provide one or more CRLs in the crls field 1712 within SignedData. 1714 The signedAttrs field within SignerInfo MUST include the content-type 1715 and message-digest attributes defined in [CMS], and it SHOULD include 1716 the signing-certificate attribute as defined in [ESS]. Within the 1717 signing-certificate attribute, the first certificate identified in 1718 the sequence of certificate identifiers MUST be the certificate of 1719 the SCVP server. The inclusion of other certificate identifiers in 1720 the signing-certificate attribute is OPTIONAL. The inclusion of 1721 policies in the signing-certificate is OPTIONAL. 1723 The CVResponse item contains the server's response. The CVResponse 1724 MUST contain the cvResponseVersion, policyID, producedAt, and 1725 responseStatus items. The CVResponse MAY also contain the 1726 respValidationPolicy, requestRef, requestorRef, requestorName, 1727 replyObjects, respNonce, serverContextInfo, and cvResponseExtensions 1728 items. The replyObjects item MUST contain exactly one CertReply item 1729 for each certificate requested. The requestorRef item MUST be 1730 included if the request included a requestorRef item. The respNonce 1731 item MUST be included if the request included a requestNonce item and 1732 a non-cached response is provided. 1734 The CVResponse MUST have the following syntax: 1736 CVResponse ::= SEQUENCE { 1737 cvResponseVersion INTEGER, 1738 policyID INTEGER, 1739 producedAt GeneralizedTime, 1740 responseStatus ResponseStatus, 1741 respValidationPolicy [0] RespValidationPolicy OPTIONAL, 1742 requestRef [1] RequestReference OPTIONAL, 1743 requestorRef [2] SEQUENCE SIZE (1..MAX) OF OCTET 1744 STRING OPTIONAL, 1745 requestorName [3] GeneralNames OPTIONAL, 1746 replyObjects [5] ReplyObjects OPTIONAL, 1747 respNonce [6] OCTET STRING OPTIONAL, 1748 serverContextInfo [7] OCTET STRING OPTIONAL, 1749 cvResponseExtensions [8] Extensions OPTIONAL } 1751 4.1 cvResponseVersion 1753 The syntax and semantics of cvResponseVersion are the same as 1754 cvRequestVersion as described in section 3.1. The 1755 cvResponseVersion MUST match the cvRequestVersion in the request. If 1756 the server cannot generate a response with a matching version number, 1757 then the server MUST return an error response that indicates the 1758 highest version number that the server supports as the version 1759 number. 1761 4.2 policyID 1763 The policy ID representing the version of the default validation 1764 policy that was used by the SCVP server when it processed the 1765 request. See section 6.4 for details. 1767 4.3 producedAt 1769 The producedAt item tells the date and time at which the SCVP server 1770 generated the response. The producedAt item MUST be expressed in 1771 UTC, and it MUST be interpreted as defined in section 3.2.7. This 1772 value is independent of the validation time. 1774 4.4 responseStatus 1776 The responseStatus item gives status information to the SCVP client 1777 about its request. The responseStatus item has a numeric status code 1778 and an optional string that is a sequence of characters from the 1779 ISO/IEC 10646-1 character set encoded with the UTF-8 transformation 1780 format defined in [UTF8]. 1782 The string MAY be used to transmit status information. The client 1783 MAY choose to display the string to a human user. However, because 1784 there is often no way to know the languages understood by a human 1785 user, the string may be of little or no assistance. 1787 The responseStatus item uses the ResponseStatus type, which has the 1788 following syntax: 1790 ResponseStatus ::= SEQUENCE { 1791 statusCode CVStatusCode, 1792 errorMessage [0] UTF8String OPTIONAL } 1794 CVStatusCode ::= ENUMERATED { 1795 okay (0), 1796 skipUnrecognizedItems (1), 1797 tooBusy (10), 1798 invalidRequest (11), 1799 internalError (12), 1800 badStructure (20), 1801 unsupportedVersion (21), 1802 abortUnrecognizedItems (22), 1803 unrecognizedSigKey (23), 1804 badSignatureOrMAC (24), 1805 unableToDecode (25), 1806 notAuthorized (26), 1807 unsupportedChecks (27), 1808 unsupportedWantBacks (28), 1809 unsupportedSignatureOrMAC (29), 1810 invalidSignatureOrMAC (30), 1811 relayingLoop (40), 1812 unrecognizedValPol (50), 1813 unrecognizedValAlg (51), 1814 fullRequestInResponseUnsupported (52), 1815 fullPolResponseUnsupported (53), 1816 inhibitPolicyMappingUnsuported (54), 1817 requireExplicitPolicyUnsupported (55), 1818 inhibitAnyPolicyUnsupported (56), 1819 validityTimeUnsupported (57), 1820 unrecognizedCritQueryExt (63), 1821 unrecognizedCritRequestExt (64)} 1823 The CVStatusCode values have the following meaning: 1825 0 The request was fully processed. 1826 1 The request included some unrecognized non-critical extensions; 1827 however, processing was able to continue ignoring them. 1828 10 Too busy; try again later. 1829 11 The server was able to decode the request, but there was some 1830 other problem with the request. 1831 12 An internal server error occurred. 1832 20 The structure of the request was wrong. 1833 21 The version of request is not supported by this server. 1834 22 The request included unrecognized items, and the server was not 1835 able to continue processing. 1836 23 The server could not validate the key used to protect the 1837 request. 1838 24 The signature or message authentication code did not match the 1839 body of the request. 1840 25 The encoding was not understood. 1841 26 The request was not authorized. 1842 27 The request included unsupported checks items, and the server 1843 was not able to continue processing. 1844 28 The request included unsupported want back items, and the server 1845 was not able to continue processing. 1846 29 The server does not support the signature or message 1847 authentication code algorithm used by the client to protect the 1848 request. 1849 30 The server could not validate the client's signature or message 1850 authentication code on the request. 1851 40 The request was previously relayed by the same server. 1852 50 The request contained an unrecognized validation policy 1853 reference. 1854 51 The request contained an unrecognized validation algorithm OID. 1855 52 The server does not support returning the full request in the 1856 response. 1857 53 The server does not support returning the full validation policy 1858 by value in the response. 1859 54 The server does not support inhibiting policy mapping. 1860 55 The server does not support requiring explicit policy. 1861 56 The server does not support ignoring the anyPolicy certificate 1862 policy OID. 1863 57 The server only validates requests using current time. 1864 63 The query item in the request contains a critical extension 1865 whose OID is not recognized. 1866 64 The request contains a critical request extension whose OID is 1867 not recognized. 1869 Status codes 0-9 are reserved for codes that indicate the request was 1870 processed by the server and therefore MUST be sent in a success 1871 response. Status codes 10 and above indicate an error and MUST 1872 therefore be sent in an error response. 1874 4.5 respValidationPolicy 1876 The respValidationPolicy item contains either a reference to the full 1877 validation policy or the full policy by value used by the server to 1878 validate the request. It MUST be present in success responses and 1879 MUST NOT be present in error responses. The choice between returning 1880 the policy by reference or by value is controlled by the 1881 responseValidationPolByRef item in the request. The resultant 1882 validation policy is the union of the following: 1884 1. Values from the request. 1886 2. For values that are not explicitly included in the request, 1887 values from the validation policy specified by reference in 1888 the request. 1890 The RespValidationPolicy syntax is: 1892 RespValidationPolicy ::= SEQUENCE { 1893 validationPolicy ValidationPolicy, 1894 validationPolicyAttr SEQUENCE SIZE (1..MAX) OF Attribute 1895 OPTIONAL } 1897 4.5.1 validationPolicy 1899 The validationPolicy item is defined in section 3.2.4. When 1900 responseValidationPolByRef is set to FALSE in the request, all fields 1901 in the validationPolicy item MUST be populated. When 1902 responseValidationPolByRef is set to TRUE, OPTIONAL fields in the 1903 validationPolicy item only need to be populated for items for which 1904 the value in the request differs from the value from the referenced 1905 validation policy. 1907 4.5.2 validationPolicyAttr 1909 The validationPolicyAttr item MAY contain Attributes. If present, 1910 each attribute in the sequence extends the policy values for the 1911 validation policy. This specification does not define any 1912 attributes. The facility is provided to allow future 1913 specifications to extend SCVP. The syntax for Attribute is 1914 imported from [CMS]. 1916 4.6 requestRef 1918 The requestRef item allows the SCVP client to identify the request 1919 that corresponds to this response from the server. It associates the 1920 response to a particular request using either a hash of the request 1921 or a copy of CVRequest from the request. The hash is calculated as 1922 described in [CMS] for SignedData and AuthenticatedData. That is, it 1923 covers the encapsulated content and authenticated attributes but not 1924 the unauthenticated attributes. 1926 The requestRef item does not provide authentication, but does allow 1927 the client to determine that the request was not maliciously 1928 modified. 1930 The requestRef item allows the client to associate a response with a 1931 request. The requestNonce provides an alternative mechanism for 1932 matching requests and responses if the client has selected to include 1933 a full request. When the fullRequest alternative is used, the 1934 response provides a single data structure that is suitable for 1935 archive of the transaction. 1937 The requestRef item uses the RequestReference type, which has the 1938 following syntax: 1940 RequestReference ::= CHOICE { 1941 requestHash [0] HashValue, -- hash of CVRequest 1942 fullRequest [1] CVRequest } 1944 SCVP clients MUST support requestHash, and they MAY support 1945 fullRequest. SCVP servers MUST support using requestHash, and they 1946 SHOULD support using fullRequest. 1948 4.6.1 requestHash 1950 The requestHash item is the hash of the CVRequest. By default, SHA-1 1951 is used as the one-way hash function, but others can be used. The 1952 requestHash item serves two purposes. First, it allows a client to 1953 determine that the request was not maliciously modified. Second, it 1954 allows the client to associate a response with a request when using 1955 connectionless protocols. The requestNonce provides an alternative 1956 mechanism for matching requests and responses. 1958 The requestHash item uses the HashValue type, which has the following 1959 syntax: 1961 HashValue ::= SEQUENCE { 1962 algorithm AlgorithmIdentifier DEFAULT { sha-1 }, 1963 value OCTET STRING } 1965 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1966 oiw(14) secsig(3) algorithm(2) 26 } 1968 The algorithm identifier for SHA-1 is imported from [PKIX-ALG]. It 1969 is repeated here for convenience. 1971 4.6.2 fullRequest 1973 Like requestHash, the fullRequest alternative allows a client to 1974 determine that the request was not maliciously modified. It also 1975 provides a single data structure that is suitable for archive of the 1976 transaction. 1978 The fullRequest item uses the CVRequest type. The syntax and 1979 semantics of the CVRequest type are described in section 3. 1981 4.7 requestorRef 1983 The optional requestorRef item is used by the client to identify the 1984 original requestor in cases where SCVP relay is used. The value is 1985 only of local significance to the client. If the SCVP client 1986 includes a requestorRef value in the request, then the SCVP server 1987 MUST return the same value if the server is generating a non-cached 1988 response. 1990 4.8 requestorName 1992 The optional requestorName item is used by the server to return one 1993 or more identities associated with the client in the response. 1995 The SCVP server MAY choose to include any or all of the following: 1997 (1) the identity asserted by the client in the requestorName field 1998 of the request, 1999 (2) an authenticated identity for the client from a certificate or 2000 other credential used to authenticate the request, or 2001 (3) a client identifier from an out-of-band mechanism. 2003 Alternatively, the SCVP server MAY omit this item. 2005 In the case of non-cached responses to signed requests, the SCVP 2006 server SHOULD return a requestor name. 2008 SCVP servers that support signed requests SHOULD support this item. 2010 SCVP clients MUST be able to process responses that include this 2011 field, although the item value might not impact the processing in any 2012 manner. 2014 4.9 replyObjects 2016 The replyObjects item returns requested objects to the SCVP client, 2017 each of which tells the client about a single certificate from the 2018 request. The replyObjects item MUST be present in the response, 2019 unless the response is reporting an error. The CertReply item MUST 2020 contain cert, replyStatus, replyValTime, replyChecks, and 2021 replyWantBacks items; and the CertReply item MAY contain the 2022 validationErrors, nextUpdate, and certReplyExtensions items. 2024 A success response MUST contain one CertReply for each certificate 2025 specified in the queriedCerts item in the request. The order is 2026 important. The first CertReply in the sequence MUST correspond to 2027 the first certificate in the request; the second CertReply in the 2028 sequence MUST correspond to the second certificate in the request; 2029 and so on. 2031 The checks item in the request determines the content of the 2032 replyChecks item in the response. The wantBack item in the request 2033 determines the content of the replyWantBacks item in the response. 2034 The queryExtensions items in the request controls the absence or the 2035 presence and content of the certReplyExtensions item in the response. 2037 The replyObjects item uses the ReplyObjects type, which has the 2038 following syntax: 2040 ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply 2042 CertReply ::= SEQUENCE { 2043 cert CertReference, 2044 replyStatus ReplyStatus, 2045 replyValTime GeneralizedTime, 2046 replyChecks ReplyChecks, 2047 replyWantBacks ReplyWantBacks, 2048 validationErrors [0] SEQUENCE SIZE (1..MAX) OF 2049 OBJECT IDENTIFIER OPTIONAL, 2050 nextUpdate [1] GeneralizedTime OPTIONAL, 2051 certReplyExtensions [2] Extensions OPTIONAL } 2053 4.9.1 cert 2055 The cert item contains either the certificate or a reference to the 2056 certificate about which the client is requesting information. If the 2057 certificate was specified by reference in the request, the request 2058 included either the id-swb-pkc-cert or id-swb-aa-cert wantBack, and 2059 the server was able to obtain the referenced certificate then this 2060 item MUST include the certificate. Otherwise, this item MUST include 2061 the same value as was used in the queriedCerts item in the request. 2063 CertReference has the following syntax: 2065 CertReference ::= CHOICE { 2066 pkc PKCReference, 2067 ac ACReference } 2069 4.9.2 replyStatus 2071 The replyStatus item gives status information to the client about the 2072 request for the specific certificate. Note that the responseStatus 2073 item is different than the replyStatus item. The responseStatus item 2074 is the status of the whole request, while the replyStatus item is the 2075 status for the individual query item. 2077 The replyStatus item uses the ReplyStatus type, which has the 2078 following syntax: 2080 ReplyStatus ::= ENUMERATED { 2081 success (0), 2082 malformedPKC (1), 2083 malformedAC (2), 2084 unavailableValidityTime (3), 2085 referenceCertHashFail (4), 2086 certPathConstructFail (5), 2087 certPathNotValid (6), 2088 certPathNotValidNow (7), 2089 wantBackUnsatisfied (8) } 2091 The meaning of the various ReplyStatus values are: 2093 0 Success: all checks were performed successfully. 2094 1 Failure: the public key certificate was malformed. 2095 2 Failure: the attribute certificate was malformed. 2096 3 Failure: historical data for the requested validity time is not 2097 available. 2098 4 Failure: the server could not locate the reference certificate or 2099 the referenced certificate did not match the hash value provided. 2100 5 Failure: no certification path could be constructed. 2101 6 Failure: the constructed certification path is not valid with 2102 respect to the validation policy. 2103 7 Failure: the constructed certification path is not valid with 2104 respect to the validation policy, but a query at a later time 2105 may be successful. 2106 8 Failure: all checks were performed successfully, however one or 2107 more of the wantBacks could not be satisfied. 2109 Codes 1 and 2 are used to tell the client that the request was 2110 properly formed, but the certificate in question was not. This is 2111 especially useful to clients that do not parse certificates. 2113 Code 7 is used to tell the client that a valid certification path was 2114 found with the exception that a certificate in the path is on hold, 2115 current revocation information is unavailable, or the validation time 2116 precedes the notBefore time in one or more certificates in the path. 2118 For codes 1, 2, 3, and 4, the replyChecks and replyWantBacks items 2119 are not populated (i.e., they MUST be an empty sequence). For codes 2120 5, 6, 7, and 8 replyChecks MUST include an entry corresponding to 2121 each check in the request; the replyWantBacks item is not populated. 2123 4.9.3 replyValTime 2125 The replyValTime item tells the time at which the information in the 2126 CertReply was correct. The replyValTime item represents the date and 2127 time in UTC, using GeneralizedTime type. The encoding rules for 2128 GeneralizedTime in section 3.2.7 MUST be used. 2130 Within the request, the optional validityTime item tells the date and 2131 time relative to which the SCVP client wants the server to perform 2132 the checks. If the validityTime is not present, the server MUST 2133 respond as if the client provided the date and time at which the 2134 server processes the request. 2136 The information in the CertReply item MUST be formatted as if the 2137 server created this portion of the response at the time indicated in 2138 the validityTime item of the query. However, if the server does not 2139 have appropriate historical information, the server MAY either return 2140 an error or return information for a later time. 2142 4.9.4 replyChecks 2144 The replyChecks item contains the responses to the checks item in the 2145 query. The replyChecks item includes the object identifier (OID) 2146 from the query and an integer. The value of the integer indicates 2147 whether the requested check was successful. The OIDs in the checks 2148 item of the query are used to identify the corresponding replyChecks 2149 values. The OIDs in the replyChecks item MUST match the OIDs in the 2150 checks item in the request. 2152 The replyChecks item uses the ReplyChecks type, which has the 2153 following syntax: 2155 ReplyChecks ::= SEQUENCE OF ReplyCheck 2157 ReplyCheck ::= SEQUENCE { 2158 check OBJECT IDENTIFIER, 2159 status INTEGER } 2161 The status value for public key certification path building to a 2162 trusted root, { id-stc 1 }, can be one of the following: 2164 0: Built a path 2165 1: Could not build a path 2167 The status value for public key certification path building to a 2168 trusted root along with simple validation processing, { id-stc 2 }, 2169 can be one of the following: 2171 0: Valid 2172 1: Not valid 2174 The status value for public key certification path building to a 2175 trusted root along with complete status checking, { id-stc 3 }, can 2176 be one of the following: 2178 0: Valid 2179 1: Not valid 2180 2: Revocation Offline 2181 3: Revocation Unavailable 2182 4: No known source for revocation information 2184 Revocation offline means that the server or distribution point for 2185 the revocation information was connected to successfully without a 2186 network error but either no data was returned or if data was returned 2187 it was stale. Revocation unavailable means that a network error was 2188 returned when an attempt was made to reach the server or distribution 2189 point. No known source for revocation information means that the 2190 server was able to build a valid certification path but was unable to 2191 locate a source for revocation information for one or more 2192 certificates in the path. 2194 The status value for AC issuer certification path building to a 2195 trusted root, { id-stc 4 }, can be one of the following: 2197 0: Built a path 2198 1: Could not build a path 2200 The status value for AC issuer certification path building to a 2201 trusted root along with simple validation processing, { id-stc 5 }, 2202 can be one of the following: 2204 0: Valid 2205 1: Not valid 2207 The status value for AC issuer certification path building to a 2208 trusted root along with complete status checking, { id-stc 6 }, can 2209 be one of the following: 2211 0: Valid 2212 1: Not Valid 2213 2: Revocation Offline 2214 3: Revocation Unavailable 2215 4: No known source for revocation information 2217 The status value for revocation status checking of an AC as well as 2218 AC issuer certification path building to a trusted root along with 2219 complete status checking, { id-stc 7 }, can be one of the following: 2221 0: Valid 2222 1: Not Valid 2223 2: Revocation Offline 2224 3: Revocation Unavailable 2225 4: No known source for revocation information 2227 4.9.5 replyWantBacks 2229 The replyWantBacks item contains the responses to the wantBack item 2230 in the request. The replyWantBacks item includes the object 2231 identifier (OID) from the wantBack item in the request and an octet 2232 string. Within the octet string is the requested value. The OIDs in 2233 the wantBack item in the request are used to identify the 2234 corresponding reply value. The OIDs in the replyWantBacks item MUST 2235 match the OIDs in the wantBack item in the request. 2237 The replyWantBacks item uses the ReplyWantBacks type, which has the 2238 following syntax: 2240 ReplyWantBacks ::= SEQUENCE OF ReplyWantBack 2242 ReplyWantBack::= SEQUENCE { 2243 wb OBJECT IDENTIFIER, 2244 value OCTET STRING } 2246 The octet string value for the certification path used to verify the 2247 certificate in the request, { id-swb 1 }, contains the CertBundle 2248 type. The syntax and semantics of the CertBundle type are described 2249 in section 3.2.8. This CertBundle includes all the certificates in 2250 the path, starting with the end certificate and ending with the 2251 certificate issued by the trust anchor. If proof of revocation 2252 status was also requested, the CertBundle also contains any 2253 additional certificates used to validate the revocation information. 2254 These certificates follow the certificate issued by the trust anchor 2255 in the sequence. 2257 The octet string value for the proof of revocation status, { id-swb 2258 2 }, contains the RevocationInfos type. The syntax and semantics of 2259 the RevocationInfos type are described in section 3.2.9. 2261 The octet string value for the public key certificate status, { id- 2262 swb 3 }, contains an ASN.1 BOOLEAN type. The value will be TRUE if 2263 the certificate is valid, and the value will be FALSE if the 2264 certificate is not valid. 2266 The octet string value for the public key information, { id-swb 4 }, 2267 contains the SubjectPublicKeyInfo type. The syntax and semantics of 2268 the SubjectPublicKeyInfo type are described in [PKIX-1]. 2270 The octet string value for the AC issuer certification path used to 2271 verify the certificate in the request, { id-swb 5 }, contains the 2272 CertBundle type. The syntax and semantics of the CertBundle type are 2273 described in section 3.2.8. This CertBundle includes all the 2274 certificates in the path, beginning with the AC issuer certificate 2275 and ending with the certificate issued by the trust anchor. If proof 2276 of revocation status was also requested, the CertBundle also contains 2277 any additional certificates used to validate the revocation 2278 information. These certificates follow the certificate issued by the 2279 trust anchor in the sequence. 2281 The octet string value for the proof of revocation status of the AC 2282 issuer certification path, { id-swb 6 }, contains the RevocationInfos 2283 type. The syntax and semantics of the RevocationInfos type are 2284 described in section 3.2.9. 2286 The octet string value for the proof of revocation status of the 2287 attribute certificate, { id-swb 7 }, contains the RevocationInfos 2288 type. The syntax and semantics of the RevocationInfos type are 2289 described in section 3.2.9. 2291 The octet string value for the attribute certificate status, { id-swb 2292 8 }, contains an ASN.1 BOOLEAN type. The value will be TRUE if the 2293 certificate is valid, and the value will be FALSE if the certificate 2294 is not valid. 2296 The octet string value for returning all paths, { id-swb 12 }, 2297 contains an ASN.1 type CertBundles, as defined below. The syntax and 2298 semantics of the CertBundle type are described in section 3.2.8. 2299 Each CertBundle includes all the certificates in one path, starting 2300 the end certificate and ending with the certificate issued by the 2301 trust anchor. If proof of revocation status was also requested, the 2302 CertBundle also contains any additional certificates used to validate 2303 the revocation information for that path. These certificates follow 2304 the certificate issued by the trust anchor in the sequence. 2306 CertBundles ::= SEQUENCE SIZE (1..MAX) OF CertBundle 2308 4.9.6 validationErrors 2310 The validationErrors item MUST only be present in failure responses. 2311 If present, it MUST contain one or more OIDs representing the reason 2312 the validation failed (validation errors for the basic validation 2313 algorithm and name validation algorithm are defined in sections 2314 3.2.4.2.2 and 3.2.4.2.4). The validationErrors item SHOULD only 2315 be included when the replyStatus is 3, 5, 6, 7, or 8. SCVP servers 2316 are not required to specify all of the reasons that validation 2317 failed. SCVP clients MUST NOT assume that the OIDs included in 2318 validationErrors represent all of the validation errors for the 2319 certification path. 2321 4.9.7 nextUpdate 2323 The nextUpdate item tells the time at which the server expects a 2324 refresh of information regarding the validity of the certificate to 2325 become available. The nextUpdate item is especially interesting if 2326 the certificate revocation status information is not available or the 2327 certificate is suspended. The nextUpdate item represents the date 2328 and time in UTC, using the GeneralizedTime type. The encoding rules 2329 for GeneralizedTime in section 3.2.7 MUST be used. 2331 4.9.8 certReplyExtensions 2333 The certReplyExtensions contains the responses to the queryExtensions 2334 item in the request. The certReplyExtensions item uses the 2335 Extensions type defined in [PKIX-1]. The object identifiers (OIDs) 2336 in the queryExtensions item in the request are used to identify the 2337 corresponding reply values. The certReplyExtensions item, when 2338 present, contains a sequence of Extension items, each of which 2339 contains an extnID item, a critical item, and an extnValue item. 2341 The extnID item is an identifier for the extension. It contains the 2342 OID that names the extension, and it MUST match one of the OIDs in 2343 the queryExtensions item in the request. 2345 The critical item is a BOOLEAN, and it MUST be set to FALSE. 2347 The extnValue item contains an OCTET STRING. Within the OCTET STRING 2348 is the extension value. An ASN.1 type is specified for each 2349 extension, identified by the associated extnID object identifier. 2351 4.10 respNonce 2353 The respNonce item contains an identifier to bind the request to the 2354 response. 2356 If the client includes a requestNonce value in the request and the 2357 server is generating a specific non-cached response to the request 2358 then the server MUST return the same value in the response. 2360 If the server is using a cached response to the request then it 2361 MUST omit the respNonce field. 2363 If the server is returning a specific non-cached response to a 2364 request without a nonce, then the server MAY include a message 2365 specific nonce. For digitally signed messages, the server MAY use 2366 the value of the message-digest attribute in the signedAttrs within 2367 SignerInfo of the request as the value in the respNonce field. 2369 The requestNonce item uses the octet string type. 2371 Client SHOULD support respNonce and servers MUST support respNonce. 2373 4.11 serverContextInfo 2375 The serverContextInfo item in a response is a mechanism for the 2376 server to pass some opaque context information to the client. If the 2377 client does not like the certification path returned, it can make a 2378 new query and pass along this context information. 2380 Section 3.2.6 contains information about the client's usage of this 2381 item. 2383 The context information is opaque to the client, but it provides 2384 information to the server that ensures that a different certification 2385 path will be returned (if another one can be found). The context 2386 information could indicate state on the server or it could contain a 2387 sequence of hashes of certification paths that have already been 2388 returned to the client. The protocol does not dictate any structure 2389 or requirements for this item. However, implementers should review 2390 the Security Considerations section of this document before selecting 2391 a structure. 2393 Servers that are incapable of returning additional paths MUST NOT 2394 include the serverContextInfo item in the response. 2396 4.12 cvResponseExtensions 2398 If present, the CVResponseExtensions item contains a sequence of 2399 Extensions that extend the response. This specification does not 2400 define any extensions. The facility is provided to allow future 2401 specifications to extend SCVP. The syntax for Extensions is imported 2402 from [PKIX-1]. The cvResponseExtensions item, when present, contains 2403 a sequence of Extension items, each of which contains an extnID item, 2404 a critical item, and an extnValue item. 2406 The extnID item is an identifier for the extension. It contains the 2407 object identifier (OID) that names the extension. 2409 The critical item is a BOOLEAN. Each extension is designated as 2410 either critical (with a value of TRUE) or non-critical (with a value 2411 of FALSE). An SCVP client MUST reject the response if it encounters 2412 a critical extension it does not recognize; however, a non-critical 2413 extension MAY be ignored if it is not recognized. 2415 The extnValue item contains an OCTET STRING. Within the OCTET STRING 2416 is the extension value. An ASN.1 type is specified for each 2417 extension, identified by the associated extnID object identifier. 2419 4.13 SCVP Response Validation 2421 There are two mechanisms for validation of SCVP responses, one based 2422 on the client's knowledge of a specific SCVP server key and the other 2423 based on validation of the certificate corresponding to the private 2424 key used to protect the SCVP response. 2426 4.13.1 Simple Key Validation 2428 The simple key validation method is where the SCVP client has a local 2429 policy of one or more SCVP server keys that directly identify the set 2430 of valid SCVP servers. Mechanisms for storage of server keys or 2431 identifiers are a local matter. For example, a client could store 2432 cryptographic hashes of public keys used to verify SignedData 2433 responses. Alternatively, a client could store shared symmetric keys 2434 used to verify MACs in AuthenticatedData responses. 2436 Simple key validation MUST be used by SCVP clients that cannot 2437 validate PKIX-1 certificates and are therefore making delegated path 2438 validation requests to the SCVP server [RQTMS]. It is a matter of 2439 local policy with these clients whether to use SignedData or 2440 AuthenticatedData. Simple key validation MAY be used by other SCVP 2441 clients for other reasons. 2443 4.13.2 SCVP Server Certificate Validation 2445 It is a matter of local policy what validation policy the client uses 2446 when validating responses. When validating protected SCVP responses, 2447 SCVP clients SHOULD use the validation algorithm defined in section 6 2448 of [PKIX-1]. 2450 If the certificate used to sign the validation policy responses and 2451 SignedData validation responses contains the key usage extension 2452 [PKIX-1 section 4.2.1.3] it MUST have either the digital signature 2453 bit set, the non-repudiation bit set, or both bits set. 2455 If the certificate for AuthenticatedData validation responses 2456 contains the key usage extension it MUST have the key agreement bit 2457 set. 2459 If the certificate used on a validation policy response or a 2460 validation response contains the extended key usage extension [PKIX-1 2461 section 4.2.1.13] it MUST contain the following OID: 2463 id-kp-scvpServer OBJECT IDENTIFIER ::= { id-kp 15 } 2465 5 Server Policy Request 2467 An SCVP client uses the ValPolRequest item to request the list of 2468 validation policies supported by the SCVP server. When a 2469 ValPolRequest is encapsulated in a MIME body part, it MUST be carried 2470 in an application/vp-request MIME body part. 2472 The request consists of a ValPolRequest encapsulated in a 2473 ContentInfo. The client does not sign the request. 2475 ContentInfo { 2476 contentType id-ct-scvp-valPolRequest, 2477 -- (1.2.840.113549.1.9.16.1.12) 2478 content ValPolRequest } 2480 The ValPolRequest type has the following syntax: 2482 ValPolRequest ::= SEQUENCE { 2483 vpRequestVersion INTEGER, 2484 requestNonce OCTET STRING } 2486 5.1 vpRequestVersion 2488 The syntax and semantics of vpRequestVersion are the same as 2489 cvRequestVersion as described in section 3.1. 2491 5.2 requestNonce 2493 The requestNonce item contains a request identifier generated by the 2494 SCVP client. If the server returns a specific response it MUST 2495 include the requestNonce from the request in the response, but the 2496 server MAY return a cached response which MUST NOT include a 2497 requestNonce. 2499 6 Validation Policy Response 2501 In response to a ValPolRequest, the SCVP server provides a 2502 ValPolResponse. The ValPolResponse MAY not be unique to any 2503 ValPolRequest, so may be reused by the server in response to multiple 2504 ValPolRequests. The ValPolResponse also has an indication of how 2505 frequently the ValPolResponse may be reissued. The server MUST sign 2506 the response using its digital signature certificate. When a 2507 ValPolResponse is encapsulated in a MIME body part, it MUST be 2508 carried in an application/vp-response MIME body part. 2510 The response consists of a ValPolResponse encapsulated in a 2511 SignedData, which is in turn encapsulated in a ContentInfo. An 2512 overview of the structure used for the response is provided below. 2513 Many details are not shown, but the way that SCVP makes use of CMS is 2514 clearly illustrated. 2516 ContentInfo { 2517 contentType id-signedData, -- (1.2.840.113549.1.7.2) 2518 content SignedData } 2520 SignedData { 2521 version CMSVersion, 2522 digestAlgorithms DigestAlgorithmIdentifiers, 2523 encapContentInfo EncapsulatedContentInfo, 2524 certificates [0] IMPLICIT CertificateSet OPTIONAL, 2525 -- MUST include server cert 2526 crls [1] IMPLICIT CertificateRevocationLists 2527 OPTIONAL, 2528 signerInfos SET OF SignerInfos } -- Only one in SCVP 2530 SignerInfo { 2531 version CMSVersion, 2532 sid SignerIdentifier, 2533 digestAlgorithm DigestAlgorithmIdentifier, 2534 signedAttrs SignedAttributes, -- Required by CMS 2535 signatureAlgorithm SignatureAlgorithmIdentifier, 2536 signature SignatureValue, 2537 unsignedAttrs UnsignedAttributes } -- Not used in SCVP 2539 EncapsulatedContentInfo { 2540 eContentType id-ct-scvp-valPolResponse, 2541 -- (1.2.840.113549.1.9.16.1.13) 2542 eContent OCTET STRING } -- Contains ValPolResponse 2544 The ValPolResponse type has the following syntax: 2546 ValPolResponse ::= SEQUENCE { 2547 vpResponseVersion INTEGER, 2548 maxCVResponseVersion INTEGER, 2549 maxVPResponseVersion INTEGER, 2550 defaultPolicyID INTEGER, 2551 thisUpdate GeneralizedTime, 2552 nextUpdate GeneralizedTime OPTIONAL, 2553 validationPolices SEQUENCE OF ValidationPolRef, 2554 validationAlgs SEQUENCE OF OBJECT IDENTIFIER, 2555 authPolicies SEQUENCE OF AuthPolicy, 2556 responseTypes ResponseTypes, 2557 defaultPolicyValues RespValidationPolicy, 2558 revocationInfoTypes RevocationInfoTypes, 2559 serverPublicKeys SEQUENCE OF KeyAgreePublicKey 2560 OPTIONAL, 2561 clockSkew [0] INTEGER DEFAULT 10, 2562 requestNonce [1] OCTET STRING OPTIONAL } 2564 ResponseTypes ::= ENUMERATED { 2565 cached-only (0), 2566 non-cached-only (1), 2567 cached-and-non-cached (2)} 2569 RevocationInfoTypes ::= BIT STRING { 2570 fullCRLs (0), 2571 deltaCRLs (1), 2572 indirectCRLs (2), 2573 oCSPResponses (3) } 2575 SCVP clients that support validation policy requests MUST support 2576 validation policy responses. SCVP servers MUST support validation 2577 policy responses. 2579 SCVP servers MUST support cached policy responses and MAY support 2580 specific responses to policy requests. 2582 6.1 vpResponseVersion 2584 The syntax and semantics of the vpResponseVersion item are the same 2585 as cvRequestVersion as described in section 3.1. The 2586 vpResponseVersion used MUST be the same as the vpRequestVersion 2587 unless the client has used a value greater than the values the server 2588 supports. If the client submits a vpRequestVersion greater than the 2589 version supported by the server, the server MUST return a 2590 vpResponseVersion using the highest version number the server 2591 supports as the version number. 2593 6.2 maxCVRequestVersion 2595 The maxCVRequestVersion defines the maximum version number for CV 2596 requests that the server supports. 2598 6.3 maxVPRequestVersion 2600 The maxVPRequestVersion defines the maximum version number for VP 2601 requests that the server supports. 2603 6.4 defaultPolicyID 2604 An integer that uniquely represents the version of the default 2605 validation policy as represented by the validationPolicy, 2606 validationAlg, authPolicies, and clockSkew. If any of these values 2607 change, the server MUST create a new ValPolResponse with a new 2608 defaultPolicyID. If the policy and therefore the defaultPolicyID has 2609 not changed, then the server may reuse defaultPolicyID across 2610 multiple ValPolResponse messages. However if the server, having 2611 changed the policy, then reverts to an earlier policy, the server 2612 MUST NOT revert the policy ID as well, but MUST select another unique 2613 value. 2615 6.5 thisUpdate 2617 This field indicates the signing date and time of this policy 2618 response. 2620 GeneralizedTime values MUST be expressed Greenwich Mean Time (Zulu) 2621 and interpreted as defined in section 3.2.7. 2623 6.6 nextUpdate and requestNonce 2625 These fields are used to indicate whether policy responses are 2626 specific to policy requests. Where policy responses are cached, 2627 these fields indicate when the information will be updated. The 2628 optional nextUpdate field indicates the time by which the next policy 2629 response will be published. The optional requestNonce field links 2630 the response to a specific request by returning the nonce provided in 2631 the request. 2633 If the nextUpdate field is omitted it indicates a non-cached response 2634 generated in response to a specific request (i.e. the ValPolResponse 2635 is bound to a specific request). If this field is omitted the 2636 requestNonce field MUST be present and MUST include the requestNonce 2637 value from the request. 2639 If the nextUpdate field is present it indicates a cached response 2640 that is not bound to a specific request. An SCVP server MUST 2641 periodically generate a new response as defined by the next update 2642 time, but MAY use the same ValPolResponse to respond to multiple 2643 requests. Thes requestNonce is omitted if the nextUpdate field is 2644 present. 2646 It is a matter of local server policy to return a cached or non- 2647 cached specific response. 2649 GeneralizedTime values in nextUpdate MUST be expressed Greenwich Mean 2650 Time (Zulu) as specified in section 3.2.7. 2652 6.7 validationPolicies 2654 The validationPolicies item contains a sequence of ValidationPolRef 2655 representing the validation policies supported by the server. It is 2656 a matter of local policy if the server wishes to process requests 2657 using the default validation policy, and if it does not, then it MUST 2658 NOT include the id-svp-defaultValPolicy in this list. 2660 6.8 validationAlgs 2662 The validationAlgs item contains a sequence of OIDs. Each OID 2663 identifies a validation algorithm supported by the server. 2665 6.9 authPolicies 2667 The authPolicies item contains a sequence of policy references for 2668 authenticating to the SCVP server. 2670 The reference to the authentication policy can be either an OID where 2671 the client and server have agreed the OID to represent an 2672 authentication policy or a URI where the URI points to a human 2673 readable definition of the policy. The list of policies is intended 2674 to document to the client if authentication is required for some 2675 requests and if so how. 2677 AuthPolicy ::= CHOICE { 2678 authPolRefByOID [0] OBJECT IDENTIFIER, 2679 authPolRefByURI [1] IA5String} 2681 6.10 responseTypes 2683 responseTypes allows the server to publish the range of response 2684 types it supports. Cached only means the server will only return 2685 cached responses to requests. Non-cached only means the server will 2686 return a specific response to the request i.e. containing the 2687 requestor's nonce. Both means the server will return either, 2688 depending on the request. 2690 6.11 revocationInfoTypes 2692 revocationInfoTypes allows the server to indicate the sources of 2693 revocation information that it is capable of processing. For each 2694 bit in the RevocationInfoTypes bit string, the server MUST set the 2695 bit to one if it is capable of processing the corresponding 2696 revocation information type and to zero if it can not. 2698 6.12 defaultPolicyValues 2699 This is the default validation policy used by the server. It 2700 contains a RespValidationPolicy, which is defined in section 4.5. 2701 All OPTIONAL fields in the validationPolicy field MUST be populated. 2702 A server will use these default values when the request references 2703 the default validation policy and the client does not override the 2704 default values by supplying other values in the request. 2706 This allows the client to optimize the request by omitting parameters 2707 that match the server default values. 2709 6.13 serverPublicKeys 2711 The serverPublicKeys item is a sequence of one or more key agreement 2712 public keys and associated parameters. It is used by clients making 2713 AuthenticatedData requests to the server. Each item in the 2714 serverPublicKeys sequence is of the KeyAgreePublicKey type: 2716 KeyAgreePublicKey ::= SEQUENCE { 2717 algorithm AlgorithmIdentifier, 2718 publicKey BIT STRING } 2720 The KeyAgreePublicKey includes the algorithm identifier and the 2721 server's public key. SCVP servers that support the key agreement 2722 mode of AuthenticatedData for SCVP requests MUST support 2723 serverPublicKeys and the Diffie-Hellman key agreement algorithm as 2724 specified in [PKIX-ALG]. SCVP servers that support serverPublicKeys 2725 MUST support the 1024-bit MODP group key (group 2) as defined in 2726 [IKE]. SCVP servers that support serverPublicKeys MAY support other 2727 Diffie-Hellman groups [IKE-GROUPS], as well as other key agreement 2728 algorithms. 2730 6.14 clockSkew 2732 The clockSkew item is the number of minutes the server will allow for 2733 clock skew. The default value of 10 minutes. 2735 7 SCVP Server Relay 2737 In some network environments, especially ones that include firewalls, 2738 an SCVP server might not be able to obtain all of the information 2739 that it needs to process a request. However, the server might be 2740 configured to use the services of one or more other SCVP servers to 2741 fulfill all requests. In such cases, the SCVP client is unaware that 2742 the initial SCVP server is using the services of other SCVP servers. 2743 The initial SCVP server acts as a client to another SCVP server. 2744 Unlike the original client, the SCVP server is expected to have 2745 moderate computing and memory resources. This section describes 2746 SCVP server-to-SCVP server exchanges. This section does not impose 2747 any requirements on SCVP clients that are not also SCVP servers. 2749 Further, this section does not impose any requirements on SCVP 2750 servers that do not relay requests to other SCVP servers. 2752 When one SCVP server relays a request to another server, in an 2753 incorrectly configured system of servers, it is possible that the 2754 same request will be relayed back again. Any SCVP server that relays 2755 requests MUST implement the conventions described in this section to 2756 detect and break loops. 2758 When an SCVP server relays a request, the request MUST include the 2759 requestorRef item. If the request to be relayed already contains a 2760 requestorRef item, then the server-generated request MUST contain a 2761 requestorRef item constructed from this value followed by an octet 2762 string that contains an identifier of the SCVP server. If the 2763 request to be relayed does not contain a requestorRef item, then the 2764 server-generated request MUST contain a requestorRef item that 2765 includes a single octet string that contains an identifier of the 2766 SCVP server. 2768 To prevent false loop detection, servers should use identifiers that 2769 are unique within their network of cooperating SCVP servers. SCVP 2770 servers that support relay SHOULD populate this item with the DNS 2771 name of the server or the distinguished name in the server's 2772 certificate. SCVP servers MAY choose other procedures for generating 2773 identifiers that are unique within their community. 2775 When an SVCP server receives a request that contains a requestorRef 2776 item, the server MUST check the sequence of octet strings in the 2777 requestorRef item for its own identifier. If the server discovers 2778 its own identifier in the requestor item, it MUST respond with an 2779 error, setting the cvResponseStatus to 40. 2781 When an SCVP server generates a non-cached response to a relayed 2782 request, the server MUST include the requestorRef item from the 2783 request in the response. 2785 8 SCVP ASN.1 Module 2787 This section defines the syntax for SCVP request-response pairs. The 2788 semantics for the messages are defined in sections 3, 4, 5, and 6. 2789 The SCVP ASN.1 module follows. 2791 SCVP 2793 { iso(1) identified-organization(3) dod(6) internet(1) 2794 security(5) mechanisms(5) pkix(7) id-mod(0) 21 } 2796 DEFINITIONS IMPLICIT TAGS ::= BEGIN 2797 IMPORTS 2799 AlgorithmIdentifier, Attribute, Certificate, Extensions, 2800 -- Import UTF8String if required by compiler 2801 -- UTF8String, -- CertificateList 2802 FROM PKIX1Explicit88 -- RFC 3280 2803 { iso(1) identified-organization(3) dod(6) internet(1) 2804 security(5) mechanisms(5) pkix(7) id-mod(0) 18 } 2806 GeneralNames, GeneralName, KeyUsage, KeyPurposeId 2807 FROM PKIX1Implicit88 -- RFC 3280 2808 { iso(1) identified-organization(3) dod(6) internet(1) 2809 security(5) mechanisms(5) pkix(7) id-mod(0) 19 } 2811 AttributeCertificate 2812 FROM PKIXAttributeCertificate -- RFC 3281 2813 { iso(1) identified-organization(3) dod(6) internet(1) 2814 security(5) mechanisms(5) pkix(7) id-mod(0) 12 } 2816 ESSCertID 2817 FROM ExtendedSecurityServices -- RFC 2634 2818 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 2819 pkcs-9(9) smime(16) modules(0) 2 } 2821 OCSPResponse 2822 FROM OCSP -- RFC 2560 2823 { iso(1) identified-organization(3) dod(6) internet(1) 2824 security(5) mechanisms(5) pkix(7) id-mod(0) 14 } ; 2826 -- SCVP Certificate Validation Request 2828 id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2829 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2830 id-smime(16) 1 } 2832 id-ct-scvp-certValRequest OBJECT IDENTIFIER ::= { id-ct 10 } 2834 CVRequest ::= SEQUENCE { 2835 cvRequestVersion INTEGER, 2836 query Query, 2837 requestorRef [0] SEQUENCE SIZE (1..MAX) OF OCTET STRING 2838 OPTIONAL, 2839 requestNonce [1] OCTET STRING OPTIONAL, 2840 requestorName [2] GeneralName OPTIONAL, 2841 reqestExtensions [3] Extensions OPTIONAL } 2843 Query ::= SEQUENCE { 2844 queriedCerts CertReferences, 2845 checks CertChecks, 2846 wantBack WantBack, 2847 validationPolicy ValidationPolicy, 2848 responseFlags ResponseFlags OPTIONAL, 2849 serverContextInfo [2] OCTET STRING OPTIONAL, 2850 validationTime [3] GeneralizedTime OPTIONAL, 2851 intermediateCerts [4] CertBundle OPTIONAL, 2852 revInfos [5] RevocationInfos OPTIONAL, 2853 producedAt [6] GeneralizedTime OPTIONAL, 2854 queryExtensions [7] Extensions OPTIONAL } 2856 CertReferences ::= CHOICE { 2857 pkcRefs [0] SEQUENCE SIZE (1..MAX) OF PKCReference, 2858 acRefs [1] SEQUENCE SIZE (1..MAX) OF ACReference } 2860 CertReference::= CHOICE { 2861 pkc PKCReference, 2862 ac ACReference } 2864 PKCReference ::= CHOICE { 2865 cert [0] Certificate, 2866 pkcRef [1] ESSCertID } 2868 ACReference ::= CHOICE { 2869 attrCert [2] AttributeCertificate, 2870 acRef [3] ESSCertID } 2872 ValidationPolicy ::= SEQUENCE { 2873 validationPolRef ValidationPolRef, 2874 validationAlg [0] ValidationAlg OPTIONAL, 2875 userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT 2876 IDENTIFIER OPTIONAL, 2877 inhibitPolicyMapping [2] BOOLEAN OPTIONAL, 2878 requireExplicitPolicy [3] BOOLEAN OPTIONAL, 2879 inhibitAnyPolicy [4] BOOLEAN OPTIONAL, 2880 trustAnchors [6] TrustAnchors OPTIONAL, 2881 keyUsages [7] KeyUsages OPTIONAL, 2882 extendedKeyUsages [8] SEQUENCE OF KeyPurposeId OPTIONAL} 2884 CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 2886 WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 2888 ValidationPolRef ::= CHOICE { 2889 valPolRefByOID OBJECT IDENTIFIER, 2890 valPolRefByURI IA5String} 2892 ValidationAlg ::= SEQUENCE { 2893 valAlgId OBJECT IDENTIFIER, 2894 parameters ANY DEFINED BY valAlgId OPTIONAL } 2896 NameValidationAlgParms ::= SEQUENCE { 2897 nameCompAlgId OBJECT IDENTIFIER, 2898 validationNames GeneralNames } 2900 TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF PKCReference 2902 KeyUsages ::= CHOICE { 2903 anyKeyUsage NULL, 2904 requiredKeyUsages SEQUENCE SIZE (1..MAX) OF KeyUsage } 2906 KeyAgreePublicKey ::= SEQUENCE { 2907 algorithm AlgorithmIdentifier, 2908 publicKey BIT STRING } 2910 ResponseFlags ::= SEQUENCE { 2911 fullRequestInResponse [0] BOOLEAN DEFAULT FALSE, 2912 responseValidationPolByRef [1] BOOLEAN DEFAULT TRUE, 2913 protectResponse [2] BOOLEAN DEFAULT TRUE, 2914 cachedResponse [3] BOOLEAN DEFAULT TRUE } 2916 CertBundle ::= SEQUENCE SIZE (1..MAX) OF Certificate 2918 RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo 2920 RevocationInfo ::= CHOICE { 2921 crl [0] CertificateList, 2922 delta-crl [1] CertificateList, 2923 ocsp [2] OCSPResponse, 2924 other [3] OtherRevInfo } 2926 OtherRevInfo ::= SEQUENCE { 2927 riType OBJECT IDENTIFIER, 2928 riValue ANY DEFINED BY riType } 2930 -- SCVP Certificate Validation Response 2932 id-ct-scvp-certValResponse OBJECT IDENTIFIER ::= { id-ct 11 } 2934 CVResponse ::= SEQUENCE { 2935 cvResponseVersion INTEGER, 2936 policyID INTEGER, 2937 producedAt GeneralizedTime, 2938 responseStatus ResponseStatus, 2939 respValidationPolicy [0] RespValidationPolicy OPTIONAL, 2940 requestRef [1] RequestReference OPTIONAL, 2941 requestorRef [2] SEQUENCE SIZE (1..MAX) OF OCTET STRING 2942 OPTIONAL, 2943 requestorName [3] GeneralNames OPTIONAL, 2944 replyObjects [5] ReplyObjects OPTIONAL, 2945 respNonce [6] OCTET STRING OPTIONAL, 2946 serverContextInfo [7] OCTET STRING OPTIONAL, 2947 cvResponseExtensions [8] Extensions OPTIONAL } 2949 ResponseStatus ::= SEQUENCE { 2950 statusCode CVStatusCode, 2951 errorMessage [0] UTF8String OPTIONAL } 2953 CVStatusCode ::= ENUMERATED { 2954 okay (0), 2955 skipUnrecognizedItems (1), 2956 tooBusy (10), 2957 invalidREquest (11), 2958 internalError (12), 2959 badStructure (20), 2960 unsupportedVersion (21), 2961 abortUnrecognizedItems (22), 2962 unrecognizedSigKey (23), 2963 badSignatureOrMAC (24), 2964 unableToDecode (25), 2965 notAuthorized (26), 2966 unsupportedChecks (27), 2967 unsupportedWantBacks (28), 2968 unsupportedSignatureOrMAC (29), 2969 invalidSignatureOrMAC (30), 2970 relayingLoop (40), 2971 unrecognizedValPol (50), 2972 unrecognizedValAlg (51), 2973 fullRequestInResponseUnsupported (52), 2974 fullPolResponseUnsupported (53), 2975 inhibitPolicyMappingUnsupported (54), 2976 requireExplicitPolicyUnsupported (55), 2977 inhibitAnyPolicyUnsupported (56), 2978 validityTimeUnsupported (57), 2979 unrecognizedCritQueryExt (63), 2980 unrecognizedCriticalRequestExt (64)} 2982 RespValidationPolicy ::= SEQUENCE { 2983 validationPolicy ValidationPolicy, 2984 validationPolicyAttr SEQUENCE SIZE (1..MAX) OF Attribute 2985 OPTIONAL } 2987 RequestReference ::= CHOICE { 2988 requestHash [0] HashValue, -- hash of CVRequest 2989 fullRequest [1] CVRequest } 2991 HashValue ::= SEQUENCE { 2992 algorithm AlgorithmIdentifier DEFAULT { sha-1 }, 2993 value OCTET STRING } 2995 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 2996 oiw(14) secsig(3) algorithm(2) 26 } 2998 ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply 3000 CertReply ::= SEQUENCE { 3001 cert CertReference, 3002 replyStatus ReplyStatus, 3003 replyValTime GeneralizedTime, 3004 replyChecks ReplyChecks, 3005 replyWantBacks ReplyWantBacks, 3006 validationErrors [0] SEQUENCE SIZE (1..MAX) OF 3007 OBJECT IDENTIFIER OPTIONAL, 3008 nextUpdate [1] GeneralizedTime OPTIONAL, 3009 certReplyExtensions [2] Extensions OPTIONAL } 3011 ReplyStatus ::= ENUMERATED { 3012 success (0), 3013 malformedPKC (1), 3014 malformedAC (2), 3015 unavailableValidityTime (3), 3016 referenceCertHashFail (4), 3017 certPathConstructFail (5), 3018 certPathNotValid (6), 3019 certPathNotValidNow (7), 3020 wantBackUnsatisfied (8) } 3022 ReplyChecks ::= SEQUENCE OF ReplyCheck 3024 ReplyCheck ::= SEQUENCE { 3025 check OBJECT IDENTIFIER, 3026 status INTEGER } 3028 ReplyWantBacks ::= SEQUENCE OF ReplyWantBack 3030 ReplyWantBack::= SEQUENCE { 3031 wb OBJECT IDENTIFIER, 3032 value OCTET STRING } 3034 CertBundles ::= SEQUENCE SIZE (1..MAX) OF CertBundle 3036 -- SCVP Validation Policies Request 3038 id-ct-scvp-valPolRequest OBJECT IDENTIFIER ::= { id-ct 12 } 3039 ValPolRequest ::= SEQUENCE { 3040 vpRequestVersion INTEGER, 3041 requestNonce OCTET STRING } 3043 -- SCVP Validation Policies Response 3045 id-ct-scvp-valPolResponse OBJECT IDENTIFIER ::= { id-ct 13 } 3047 ValPolResponse ::= SEQUENCE { 3048 vpResponseVersion INTEGER, 3049 maxCVResponseVersion INTEGER, 3050 maxVPResponseVersion INTEGER, 3051 defaultPolicyID INTEGER, 3052 thisUpdate GeneralizedTime, 3053 nextUpdate GeneralizedTime OPTIONAL, 3054 validationPolices SEQUENCE OF ValidationPolRef, 3055 validationAlgs SEQUENCE OF OBJECT IDENTIFIER, 3056 authPolicies SEQUENCE OF AuthPolicy, 3057 responseTypes ResponseTypes, 3058 defaultPolicyValues RespValidationPolicy, 3059 revocationInfoTypes RevocationInfoTypes, 3060 serverPublicKeys SEQUENCE OF KeyAgreePublicKey 3061 OPTIONAL, 3062 clockSkew [0] INTEGER DEFAULT 10, 3063 requestNonce [1] OCTET STRING OPTIONAL } 3065 ResponseTypes ::= ENUMERATED { 3066 cached-only (0), 3067 non-cached-only (1), 3068 cached-and-non-cached (2)} 3070 RevocationInfoTypes ::= BIT STRING { 3071 fullCRLs (0), 3072 deltaCRLs (1), 3073 indirectCRLs (2), 3074 oCSPResponses (3) } 3076 AuthPolicy ::= CHOICE { 3077 authPolRefByOID [0] OBJECT IDENTIFIER, 3078 authPolRefByURI [1] IA5String} 3080 -- SCVP Check Identifiers 3082 id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3083 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 } 3085 id-stc-build-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 } 3086 id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 2 } 3087 id-stc-build-status-checked-pkc-path 3088 OBJECT IDENTIFIER ::= { id-stc 3 } 3089 id-stc-build-aa-path OBJECT IDENTIFIER ::= { id-stc 4 } 3090 id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 5 } 3091 id-stc-build-status-checked-aa-path 3092 OBJECT IDENTIFIER ::= { id-stc 6 } 3093 id-stc-status-check-ac-and-build-status-checked-aa-path 3094 OBJECT IDENTIFIER ::= { id-stc 7 } 3096 -- SCVP WantBack Identifiers 3098 id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3099 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 } 3101 id-swb-pkc-best-cert-path OBJECT IDENTIFIER ::= { id-swb 1 } 3102 id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 } 3103 id-swb-pkc-cert-status OBJECT IDENTIFIER ::= { id-swb 3 } 3104 id-swb-pkc-public-key-info OBJECT IDENTIFIER ::= { id-swb 4 } 3105 id-swb-aa-cert-path OBJECT IDENTIFIER ::= { id-swb 5 } 3106 id-swb-aa-revocation-info OBJECT IDENTIFIER ::= { id-swb 6 } 3107 id-swb-ac-revocation-info OBJECT IDENTIFIER ::= { id-swb 7 } 3108 id-swb-ac-cert-status OBJECT IDENTIFIER ::= { id-swb 8 } 3109 id-swb-pkc-cert OBJECT IDENTIFIER ::= { id-swb 10} 3110 id-swb-ac-cert OBJECT IDENTIFIER ::= { id-swb 11} 3111 id-swb-pkc-all-cert-paths OBJECT IDENTIFIER ::= { id-swb 12} 3113 -- SCVP Validation Policy and Algorithm Identifiers 3115 id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3116 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 } 3118 id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 } 3120 -- SCVP Basic Validation Algorithm Identifier 3122 id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 } 3124 -- SCVP Basic Validation Algorithm Errors 3126 id-bvae OBJECT IDENTIFIER ::= id-svp-basicValAlg 3128 id-bvae-expired OBJECT IDENTIFIER ::= { id-bvae 1 } 3129 id-bvae-not-yet-valid OBJECT IDENTIFIER ::= { id-bvae 2 } 3130 id-bvae-wrong-anchor OBJECT IDENTIFIER ::= { id-bvae 3 } 3131 id-bvae-invalid-key-usage OBJECT IDENTIFIER ::= { id-bvae 10 } 3132 id-bvae-invalid-purpose OBJECT IDENTIFIER ::= { id-bvae 11 } 3133 id-bvae-revoked OBJECT IDENTIFIER ::= { id-bvae 16 } 3135 -- SCVP Name Validation Algorithm Identifier 3136 id-svp-nameValAlg OBJECT IDENTIFIER ::= { id-svp 2 } 3138 -- SCVP Name Validation Algorithm DN comparison algorithm 3140 id-nva-dnCompAlg OBJECT IDENTIFIER ::= { id-svp 4 } 3142 -- SCVP Name Validation Algorithm Errors 3144 id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg 3146 id-nvae-name-mismatch OBJECT IDENTIFIER ::= { id-nvae 1 } 3147 id-nvae-no-name OBJECT IDENTIFIER ::= { id-nvae 2 } 3148 id-nvae-unknown-alg OBJECT IDENTIFIER ::= { id-nvae 3 } 3149 id-nvae-bad-name OBJECT IDENTIFIER ::= { id-nvae 4 } 3150 id-nvae-bad-name-type OBJECT IDENTIFIER ::= { id-nvae 5 } 3151 id-nvae-mixed-names OBJECT IDENTIFIER ::= { id-nvae 6 } 3153 -- SCVP Extended Key Usage Key Purpose Identifiers 3155 id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3156 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } 3158 id-kp-scvpServer OBJECT IDENTIFIER ::= { id-kp 15 } 3160 id-kp-scvpClient OBJECT IDENTIFIER ::= { id-kp 16 } 3162 END 3164 9 Security Considerations 3166 For security considerations specific to the Cryptographic Message 3167 Syntax message formats, see [CMS]. For security considerations 3168 specific to the process of PKI certificate path validation, see 3169 [PKIX-1]. 3171 A client that trusts a server's response for validation of a 3172 certificate inherently trusts that server as much as it would trust 3173 its own validation software. This means that if an attacker 3174 compromises a trusted SCVP server, the attacker can change the 3175 validation processing for every client that relies on that server. 3176 Thus, an SCVP server must be protected at least as well as the trust 3177 anchors that the SCVP server trusts. 3179 Clients MUST check the requestRef item in the response and ensure 3180 that it matches their original request. Requests contain a lot of 3181 information that affects the response and clients need to ensure that 3182 the server response corresponds to the request. 3184 When the SCVP response is used to determine the validity of a 3185 certificate, the client MUST validate the digital signature or MAC on 3186 the response to ensure that the expected SCVP server generated it. 3187 If the client does not check the digital signature or MAC on the 3188 response, a man-in-the-middle attack could fool the client into 3189 believing modified responses from the server, or responses to 3190 questions the client did not ask. 3192 If the client does not include a requestNonce item, or if the client 3193 does not check that the requestNonce in the response matches the 3194 value in the request, an attacker can replay previous responses from 3195 the SCVP server. 3197 If the server does not require some sort of authorization (such as 3198 signed requests), an attacker can get the server to respond to 3199 arbitrary requests. Such responses may give the attacker information 3200 about weaknesses in the server or about the timeliness of the 3201 server's checking. This information may be valuable for a future 3202 attack. 3204 If the server uses the serverContextInfo item to indicate some server 3205 state associated with a requestor, implementers must take appropriate 3206 measures against denial of service attacks where an attacker sends in 3207 a lot of requests at one time to force the server to keep a lot of 3208 state information. 3210 SCVP does not include any confidentiality mechanisms. If 3211 confidentiality is needed, it can be achieved with a lower-layer 3212 security protocol. 3214 The only validation policy references that are truly persistent are 3215 OIDs. If the ownership of the policy could in any way be an issue, 3216 then OIDs should be the reference type of choice. However in many 3217 situations, even though URIs are technically non-persistent, the use 3218 of a URI is much more readily understood because of its widespread 3219 use elsewhere, and with many organizations they may be viewed as 3220 persistent for practical purposes. Therefore in these situations use 3221 of a URI many be more attractive. 3223 If an SCVP client is not operating on a network with good physical 3224 protection, it must ensure that there is integrity over the SCVP 3225 request-response pair and ensure that the response cannot be a replay 3226 of a cached response obtained by another client. It can do this by 3227 using a protected transport such as TLS. It can also do this by 3228 using the Diffie-hellman keys to protect the request. It can also 3229 use signing keys and request a fresh response from the server. 3231 If an SCVP client populates the userPolicySet in a request with a 3232 value other than anyPolicy, but does not set the 3233 requireExplicitPolicy flag, the server may return an affirmative 3234 answer for paths that do not satisfy any of the specified policies. 3235 In general, when a client populates the userPolicySet in a request 3236 with a value other than anyPolicy, the requireExplicitPolicy flag 3237 should also be set. This guarantees that all valid paths satisfy at 3238 least one of the requested policies. 3240 In SCVP, historical validation of a certificate returns the known 3241 status of the certificate at the time specified in validationTime. 3242 This may be used to demonstrate due diligence, but does not 3243 necessarily provide the most complete information. A certificate may 3244 have been revoked after the time specified in validationTime, but an 3245 invalidity date that precedes the validationTime. The SCVP server 3246 would provide an affirmative response even though the most current 3247 information available indicates the certificate should not be trusted 3248 at that time. SCVP clients may wish to specify a validationTime 3249 later than the actual time of interest to mitigate this risk. 3251 10 References 3253 Normative and informative references are provided. 3255 10.1 Normative References 3257 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 3258 Requirement Levels", BCP 14, RFC 2119, March 1997. 3259 http://www.ietf.org/rfc/rfc2119.txt 3261 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,June 1999. 3262 http://www.ietf.org/rfc/rfc2630.txt 3264 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. Adams, 3265 "X.509 Internet Public Key Infrastructure - Online 3266 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 3267 http://www.ietf.org/rfc/rfc2560.txt 3269 [PKIX-1] Housley, R., Polk, T, Ford, W. and Solo, D., "Internet 3270 X.509 Public Key Infrastructure Certificate and 3271 Certificate Revocation List (CRL) Profile", RFC 3280, 3272 April 2002. 3273 http://www.ietf.org/rfc/rfc3280.txt 3275 [PKIX-AC] Farrell, S., and R. Housley, "An Internet Attribute 3276 Certificate Profile for Authorization", RFC 3281, April 3277 2002. 3278 http://www.ietf.org/rfc/rfc3281.txt 3280 [PKIX-ALG] Polk, W., Housley, R. and L. Bassham, "Algorithms and 3281 Identifiers for the Internet X.509 Public Key 3282 Infrastructure Certificate and Certificate Revocation List 3283 (CRL) Profile", RFC 3279, April 2002. 3284 http://www.ietf.org/rfc/rfc3280.txt 3286 [SHA-1] National Institute of Standards and Technology, "Secure Hash 3287 Standard", NIST FIPS Pub 180-1, April 1995. 3289 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3290 2279, January 1998. 3291 http://www.ietf.org/rfc/rfc2279.txt 3293 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, 3294 June 1999. 3295 http://www.ietf.org/rfc/rfc2634.txt 3297 [HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC2818, May 2000. 3298 http://www.ietf.org/rfc/rfc2818.txt 3300 [SMIME-CERT] B. Ramsdell, Ed. "Secure/Multipurpose Internet Mail 3301 Extensions (S/MIME) Version 3.1 Certificate Handling" 3302 RFC3850, July 2004. 3303 http://www.ietf.org/rfc/rfc3850.txt 3305 [IKE] D. Harkins, D. Carrel. "The Internet Key Exchange" 3306 RFC2409, November 1998 3307 http://www.ietf.org/rfc/rfc2409.txt 3309 10.2 Informative References 3311 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. 3312 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 3313 RFC 2068, January 1997. 3315 [IKE-GROUPS] T. Kivinen, M. Kojo "More Modular Exponential (MODP) 3316 Diffie-Hellman groups for Internet Key Exchange (IKE) 3317 RFC3526, May 2003 3318 http://www.ietf.org/rfc/rfc3526.txt 3320 [RQMTS] Pinkas, D., and R. Housley, "Delegated Path Validation and 3321 Delegated Path Discovery Protocol Requirements", RFC 3379, 3322 September 2002. 3324 11 Acknowledgments 3326 The lively debate in the PKIX Working Group has made a significant 3327 impact on this protocol. Special thanks to the following for their 3328 contributions to this standard and diligence in greatly improving 3329 this document. 3331 Denis Pinkas 3332 Phillip Hallam-Baker 3333 Mike Myers 3334 Frank Balluffi 3335 Ameya Talwalkar 3336 John Thielens 3337 Peter Sylvester 3338 Yuriy Dzambasow 3339 Sean P. Turner 3340 Wen-Cheng Wang 3341 Francis Dupont 3342 Dave Engberg 3343 Faisal Maqsood 3345 Thanks also to working group chair Steve Kent for his support and 3346 help. 3348 Appendix A -- MIME Registrations 3350 Four MIME type registrations are provided in this appendix. 3352 A.1 application/cv-request 3354 To: ietf-types@iana.org 3355 Subject: Registration of MIME media type application/cv-request 3357 MIME media type name: application 3359 MIME subtype name: cv-request 3361 Required parameters: format 3363 Optional parameters: None 3365 Encoding considerations: binary 3367 Security considerations: Carries a request for information. This 3368 request may optionally be cryptographically protected. 3370 Interoperability considerations: None 3372 Published specification: IETF PKIX Working Group Draft on Simple 3373 Certificate Validation Protocol (SCVP) 3375 Applications that use this media type: SCVP clients 3376 Additional information: 3377 Magic number(s): None 3378 File extension(s): .SCQ 3379 Macintosh File Type Code(s): none 3381 Person & email address to contact for further information: 3382 Ambarish Malpani 3384 Intended usage: COMMON 3386 Author/Change controller: 3387 Ambarish Malpani 3389 A.2 application/cv-response 3391 To: ietf-types@iana.org 3392 Subject: Registration of MIME media type application/cv-response 3394 MIME media type name: application 3396 MIME subtype name: cv-response 3398 Required parameters: format 3400 Optional parameters: None 3402 Encoding considerations: binary 3404 Security considerations: The client may require that this response be 3405 cryptographically protected, or may choose to use secure transport 3406 mechanism. DPD responses may be unprotected, but the client 3407 validates the information provided in the request. 3409 Interoperability considerations: None 3411 Published specification: IETF PKIX Working Group Draft on Simple 3412 Certificate Validation Protocol (SCVP) 3414 Applications that use this media type: SCVP servers 3416 Additional information: 3418 Magic number(s): None 3419 File extension(s): .SCS 3420 Macintosh File Type Code(s): none 3422 Person & email address to contact for further information: 3423 Ambarish Malpani 3424 Intended usage: COMMON 3426 Author/Change controller: Ambarish Malpani 3428 A.3 application/vp-request 3430 To: ietf-types@iana.org 3431 Subject: Registration of MIME media type application/vp-request 3433 MIME media type name: application 3435 MIME subtype name: vp-request 3437 Required parameters: format 3439 Optional parameters: None 3441 Encoding considerations: binary 3443 Security considerations: Carries a request for information. 3445 Interoperability considerations: None 3447 Published specification: IETF PKIX Working Group Draft on Simple 3448 Certificate Validation Protocol (SCVP) 3450 Applications that use this media type: SCVP clients 3452 Additional information: 3454 Magic number(s): None 3455 File extension(s): .SPQ 3456 Macintosh File Type Code(s): none 3458 Person & email address to contact for further information: 3459 Ambarish Malpani 3461 Intended usage: COMMON 3463 Author/Change controller: Ambarish Malpani 3465 A.4 application/vp-response 3467 To: ietf-types@iana.org 3468 Subject: Registration of MIME media type application/vp-response 3470 MIME media type name: application 3471 MIME subtype name: vp-response 3473 Required parameters: format 3475 Optional parameters: None 3477 Encoding considerations: Binary 3479 Security considerations: None 3481 Interoperability considerations: None 3483 Published specification: IETF PKIX Working Group Draft on Simple 3484 Certificate Validation Protocol (SCVP) 3486 Applications that use this media type: SCVP servers 3488 Additional information: 3489 Magic number(s): None 3490 File extension(s): .SPP 3491 Macintosh File Type Code(s): none 3493 Person & email address to contact for further information: 3494 Ambarish Malpani 3496 Intended usage: COMMON 3498 Author/Change controller: 3499 Ambarish Malpani 3501 Appendix B -- SCVP over HTTP 3503 This appendix describes the formatting conventions for the SCVP 3504 request and response when carried by HTTP. 3506 B.1 SCVP Request 3508 HTTP based SCVP requests can use the POST method to submit their 3509 requests. Where privacy is a requirement, SCVP transactions 3510 exchanged using HTTP MAY be protected using either TLS/SSL or some 3511 other lower layer protocol. 3513 An SCVP request using the POST method is constructed as follows: 3515 The Content-Type header MUST have the value "application/cv- 3516 request". 3518 The Content-Length header MUST be present and have the exact 3519 length of the request. 3521 The body of the message is the binary value of the DER encoding 3522 of the CVRequest, wrapped in a CMS body as described in 3523 Section 3. Other HTTP headers MAY be present and MAY be 3524 ignored if not understood by the requestor. 3526 Sample Content-Type headers are: 3527 Content-Type: application/cv- request 3529 B.2 SCVP Response 3531 An HTTP-based SCVP response is composed of the appropriate HTTP 3532 headers, followed by the binary value of the DER encoding of the 3533 CVResponse, wrapped in a CMS body as described in Section 4. 3535 The Content-Type header MUST have the value "application/cv- 3536 response". 3538 The Content-Length header MUST be present and specify the length of 3539 the response. 3541 Other HTTP headers MAY be present and MAY be ignored if not 3542 understood by the requestor. 3544 B.3 SCVP Policy Request 3546 HTTP based SCVP policy requests can use the POST method to submit 3547 their requests. Where privacy is a requirement, SCVP transactions 3548 exchanged using HTTP MAY be protected using either TLS/SSL or some 3549 other lower layer protocol. 3551 An SCVP request using the POST method is constructed as follows: 3553 The Content-Type header MUST have the value "application/vp- 3554 request". 3556 The Content-Length header MUST be present and have the exact 3557 length of the request. 3559 The body of the message is the binary value of the DER encoding 3560 of the ValPolRequest, wrapped in a CMS body as described in 3561 Section 5. Other HTTP headers MAY be present and 3562 MAY be ignored if not understood by the requestor. 3564 Sample Content-Type headers are: 3565 Content-Type: application/vp-request 3567 B.4 SCVP Policy Response 3568 An HTTP-based SCVP policy response is composed of the appropriate 3569 HTTP headers, followed by the binary value of the DER encoding of the 3570 ValPolResponse, wrapped in a CMS body as described in Section 6. 3572 The Content-Type header MUST have the value "application/vp- 3573 response". 3575 The Content-Length header MUST be present and specify the length of 3576 the response. 3578 Other HTTP headers MAY be present and MAY be ignored if not 3579 understood by the requestor. 3581 Appendix C -- Author Contact Information 3583 Trevor Freeman 3584 Microsoft Corporation, 3585 One Microsoft way. 3586 Redmond, WA 98052 3587 USA. 3588 trevorf@microsoft.com 3590 Russell Housley 3591 Vigil Security, LLC 3592 918 Spring Knoll Drive 3593 Herndon, VA 20170 3594 USA 3595 housley@Vigilsec.com 3597 Ambarish Malpani 3598 Malpani Consulting Services 3599 ambarish@malpani.biz 3601 David Cooper 3602 National Institute of Standards and Technology 3603 100 Bureau Drive, Mail Stop 8930 3604 Gaithersburg, MD 20899-8930 3605 david.cooper@nist.gov 3607 Tim Polk 3608 National Institute of Standards and Technology 3609 100 Bureau Drive, Mail Stop 8930 3610 Gaithersburg, MD 20899-8930 3611 tim.polk@nist.gov 3612 Full Copyright Statement 3614 "Copyright (C) The Internet Society (2005). This document is subject 3615 to the rights, licenses and restrictions contained in BCP 78, and 3616 except as set forth therein, the authors retain all their rights." 3618 "This document and the information contained herein are provided on 3619 An "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 3620 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 3621 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 3622 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3623 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3624 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 3626 This document and translations of it may be copied and furnished to 3627 others, and derivative works that comment on or otherwise explain it 3628 or assist in its implementation may be prepared, copied, published 3629 and distributed, in whole or in part, without restriction of any 3630 kind, provided that the above copyright notice and this paragraph 3631 are included on all such copies and derivative works. In addition, 3632 the ASN.1 modules presented may be used in whole or in part without 3633 inclusion of the copyright notice. However, this document itself may 3634 not be modified in any way, such as by removing the copyright notice 3635 or references to the Internet Society or other Internet 3636 organizations, except as needed for the purpose of developing 3637 Internet standards in which case the procedures for copyrights 3638 defined in the Internet Standards process shall be followed, or as 3639 required to translate it into languages other than English.