idnits 2.17.1 draft-ietf-pkix-scvp-16.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 39. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 3607), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 111 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 73 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 4 instances of lines with control characters in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 3081 -- Looks like a reference, but probably isn't: '1' on line 3082 -- Looks like a reference, but probably isn't: '2' on line 3033 -- Looks like a reference, but probably isn't: '3' on line 2992 -- Looks like a reference, but probably isn't: '4' on line 2943 -- 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: 'PKIX' is mentioned on line 1105, but not defined == Missing Reference: 'REQMTS' is mentioned on line 1464, but not defined == Missing Reference: 'RQTMS' is mentioned on line 2506, 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: 24 errors (**), 0 flaws (~~), 9 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft T. Freeman 2 draft-ietf-pkix-scvp-16.txt Microsoft Corp 3 October 2004 R. Housley 4 Expires in six months Vigil Security 5 A. Malpani 6 Malpani Consulting Services 8 Simple Certificate Validation Protocol (SCVP) 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 or will be disclosed, and any of which I become aware will be 15 disclosed, in accordance with RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than a "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 IPR Statement 36 By submitting this Internet-Draft, I certify that any applicable 37 patent or other IPR claims of which I am aware have been disclosed, 38 or will be disclosed, and any of which I become aware will be 39 disclosed, in accordance with RFC 3668. 41 Copyright Notice 43 Copyright (C) The Internet Society (2003). All Rights Reserved. 45 Abstract 47 SCVP allows a client to offload certificate handling to a server. 48 The server can provide the client with a variety of valuable 49 information about the certificate, such as whether the certificate 50 is valid, a certification path to a trust anchor, and revocation 51 status. SCVP has many purposes, including simplifying client 52 implementations and allowing companies to centralize trust and 53 policy management. 55 Table of Contents 57 1 Introduction....................................................5 58 1.1 SCVP overview and requirements...............................5 59 1.2 Terminology..................................................6 60 1.3 Validation Policies..........................................6 61 1.4 Validation Algorithm.........................................7 62 2 Protocol Overview...............................................8 63 3 Validation Request..............................................9 64 3.1 cvRequestVersion............................................11 65 3.1.1 queriedCerts............................................12 66 3.1.2 checks..................................................13 67 3.1.3 wantBack................................................14 68 3.1.4 validationPolicy........................................15 69 3.1.4.1 validationPolRef....................................16 70 3.1.5 validationAlg...........................................17 71 3.1.5.1 Default Validation Algorithm........................17 72 3.1.5.2 validationAlg.......................................18 73 3.1.5.2.1 Basic Validation Algorithm........................18 74 3.1.5.2.2 Basic Validation Algorithm Errors................19 75 3.1.5.2.3 Name Validation Algorithm........................20 76 3.1.5.2.4 Name Validation Algorithm Errors.................21 77 3.1.5.3 userPolicySet.......................................22 78 3.1.5.4 inhibitPolicyMapping................................22 79 3.1.5.5 requireExplicitPolicy...............................22 80 3.1.5.6 inhibitAnyPolicy....................................23 81 3.1.5.7 isCA................................................23 82 3.1.5.8 trustAnchors........................................23 83 3.1.5.9 keyUsages...........................................24 84 3.1.5.10 extendedKeyUsages..................................25 85 3.1.6 responseFlags...........................................25 86 3.1.6.1 responseRefHash.....................................25 87 3.1.6.2 responseValidationPolByRef..........................26 88 3.1.6.3 signResponse........................................26 89 3.1.7 serverContextInfo.......................................26 90 3.1.8 valididationTime........................................27 91 3.1.9 intermediateCerts.......................................28 92 3.1.10 revInfos...............................................28 93 3.1.11 producedAt.............................................29 94 3.1.12 queryExtensions........................................29 95 3.1.12.1 extnID.............................................29 96 3.1.12.2 critical...........................................29 97 3.1.12.3 extnValue..........................................30 98 3.2 requestorRef................................................30 99 3.3 requestNonce................................................30 100 3.4 requestExtensions...........................................31 101 3.4.1 extnID..................................................31 102 3.4.2 critical................................................31 103 3.4.3 extnValue...............................................31 104 3.5 dhPublicKey.................................................32 105 3.6 SCVP Request Authentication.................................32 106 4 Validation Response............................................32 107 4.1 cvResponseVersion...........................................36 108 4.2 policyID....................................................36 109 4.3 producedAt..................................................36 110 4.4 responseStatus..............................................36 111 4.5 respValidationPolicy........................................38 112 4.5.1 validationPolRef........................................39 113 4.5.2 validationPolValues.....................................39 114 4.5.2.1 validationAlg.......................................40 115 4.5.2.2 inhibitPolMap.......................................40 116 4.5.2.3 requireExplicitPol..................................40 117 4.5.2.4 inhibitAnyPol.......................................40 118 4.5.2.5 isCA................................................40 119 4.5.2.6 trustAnchors........................................40 120 4.5.2.7 keyUsage............................................40 121 4.5.2.8 extendedKeyUsage....................................40 122 4.5.2.9 validationPolicyAttr................................40 123 4.5.3 userFinalPolicySet......................................40 124 4.5.4 permittedSubtrees.......................................40 125 4.5.5 excludedSubtrees........................................41 126 4.5.6 validationPolicyAtt.....................................41 127 4.6 requestRef..................................................41 128 4.6.1 requestHash.............................................42 129 4.6.2 fullRequest.............................................42 130 4.7 requestorRef................................................42 131 4.8 requestorName...............................................42 132 4.9 responder...................................................43 133 4.10 replyObjects...............................................43 134 4.10.1 cert...................................................44 135 4.10.2 replyStatus............................................44 136 4.10.3 replyValTime...........................................45 137 4.10.4 replyChecks............................................45 138 4.10.5 replyWantBack..........................................47 139 4.10.6 validationAlg..........................................48 140 4.10.7 validationErrors.......................................48 141 4.10.8 nextUpdate.............................................48 142 4.10.9 certReplyExtensions....................................48 143 4.11 responseNonce..............................................49 144 4.12 serverContextInfo..........................................49 145 4.13 respExtensions.............................................50 146 4.14 SCVP Response Validation...................................50 147 4.14.1 Simple Key Validation..................................50 148 4.14.2 SCVP Server Certificate Validation.....................51 149 5 Server Policy Request..........................................51 150 5.1 vpRequestVersion............................................51 151 5.2 requestNonce................................................51 152 6 Validation Policy Response.....................................52 153 6.1 vpResponseVersion...........................................53 154 6.2 maxCVRequestVersion.........................................53 155 6.3 maxVPRequestVersion.........................................53 156 6.4 defaultPolicyID.............................................53 157 6.5 thisUpdate..................................................53 158 6.6 nextUpdate..................................................53 159 6.7 trustAnchors................................................54 160 6.8 validationPolicies..........................................54 161 6.9 validationAlgs..............................................54 162 6.10 authPolicies...............................................54 163 6.11 responseTypes..............................................55 164 6.12 dhPublicKeyInfo............................................55 165 6.13 clockSkew..................................................55 166 6.14 defaultValPolicy...........................................55 167 7 SCVP Server Relay..............................................56 168 8 SCVP ASN.1 Module..............................................56 169 9 Security Considerations........................................64 170 10 References....................................................65 171 10.1 Normative References.......................................65 172 10.2 Informative References.....................................67 173 11 Acknowledgments...............................................67 174 Appendix A -- MIME Registrations.................................67 175 A.1 application/cv-request......................................67 176 A.2 application/cv-response.....................................68 177 A.3 application/vp-request......................................69 178 A.4 application/vp-response.....................................70 179 Appendix B -- SCVP over HTTP.....................................70 180 B.1 SCVP Request................................................70 181 B.2 SCVP Response...............................................71 182 B.3 SCVP Policy Request.........................................71 183 B.4 SCVP Policy Response........................................72 184 Appendix C -- Author Contact Information.........................72 185 Full Copyright Statement.........................................73 186 1 Introduction 188 Certificate validation is complex. If certificate handling is to 189 be widely deployed in a variety of applications and environments, 190 the amount of processing an application needs to perform before it 191 can accept a certificate needs to be reduced. There are a variety 192 of applications that can make use of public key certificates, but 193 these applications are burdened with the overhead of constructing 194 and validating the certification paths. SCVP reduces this overhead 195 for two classes of certificate-using applications. 197 The first class of application wants just two things. First, they 198 want confirmation that the public key belongs to the identity named 199 in the certificate. Second, they want to know if the public key 200 can be used for the intended purpose. The client completely 201 delegates certification path construction and validation to the 202 SCVP server. This class of application is often referred to as 203 delegated path validation (DPV). 205 The second class of application can perform certification path 206 validation, but these applications have no reliable method of 207 constructing a certification path to a trust anchor. The client 208 only delegates certification path construction to the SCVP server. 209 This class of application is often referred to as delegated path 210 discovery (DPD). 212 1.1 SCVP overview and requirements 214 The SCVP meets the mandatory requirements documented in [RQMTS]. 216 The primary goals of SCVP are to make it easier to deploy PKI- 217 enabled applications and to allow central administration of PKI 218 policies within an organization. SCVP can be used by clients that 219 do much of the certificate processing themselves but simply want an 220 untrusted server to collect information for them. However, when 221 the client has complete trust in the SCVP server, SCVP can be used 222 to delegate the work of certification path construction and 223 validation, and SCVP can be used to ensure that policies are 224 consistently enforced throughout an organization. 226 Untrusted SCVP servers can provide clients the certification paths. 227 They can also provide clients revocation information, such as CRLs 228 and OCSP responses, and the client needs to validate the 229 certification path constructed by the SCVP server. These services 230 can be valuable to clients that do not include the protocols needed 231 to find and download intermediate certificates, CRLs, and OCSP 232 responses. 234 Trusted SCVP servers can perform certification path construction 235 and validation for the client. For a client that uses these 236 services, the client inherently trusts the SCVP server as much as 237 it would its own certification path validation software (if it 238 contained such software). There are two main reasons that a client 239 may want to trust such an SCVP server: 241 1. The client does not want to incur the overhead of including 242 certification path validation software and running it for each 243 certificate it receives. 245 2. The client is in an organization or community that wants to 246 centralize its PKI policies. These policies might dictate that 247 particular trust anchors are to be used and the types of policy 248 checking that is to be performed during certification path 249 validation. 251 1.2 Terminology 253 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 254 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 255 this document are to be interpreted as described in [STDWORDS]. 257 1.3 Validation Policies 259 A validation policy (as defined in RFC 3379 [RQMTS]) specifies the 260 rules and parameters to be used by the SCVP server when validating 261 a certificate. In SCVP, a validation policy can be either mutually 262 agreed between client and server, and subsequently referenced in 263 request, or explicitly expressed in the request by passing all of 264 the necessary parameters. 266 Policy definitions can be quite long and complex, and some policies 267 may allow for the setting of a few parameters such as a set of 268 trust anchors. The request can therefore be simplified if these 269 previously agreed policy dependent parameters are referenced in the 270 request by a mutually agreed OBJECT IDENTIFIER (OID) or URL value. 271 The referenced value indicates either a partial or full set of 272 parameters. The client can therefore omit these agreed parameters 273 from the request, only passing any parameters which are not 274 specified by the previously agreed policy. Therefore in the 275 simplest form, with validation polices which define every parameter 276 necessary, a SCVP request need only contain the certificate to be 277 validated, the validation policy and any run-time parameters for 278 the request. 280 SCVP server also publishes its default validation policy settings. 281 The default policy can be requested for validation and the client 282 can override any default value in the request if required. The 283 default values are also used when processing requests which 284 reference a validation policy other than the default one that does 285 not contain the full set of parameters necessary for validation and 286 the client has also omitted the missing values in the request. 288 Therefore a client can also simplify the request by omitting a 289 parameter from a request if the default value published by the 290 server is acceptable. 292 The inputs to the basic certification path processing algorithm 293 used by SCVP are defined by [PKIX-1] in section 6.1.1 and comprise: 295 Certificate to be validated (by value or by reference) 297 Validation time 299 Set of Trust Anchors (by value or by reference) 301 The initial policy set 303 Initial policy mapping setting 305 Initial any-Policy setting 307 Initial explicit policy setting 309 The basic certificate path processing algorithm also supports the 310 following parameters which are defined in [PKIX-1] section 4 312 The basic certification path processing algorithm also supports the 313 following parameters which are defined in [PKIX-1] section 4: 315 The usage of the key contained in the certificate (e.g., key 316 encipherment, key agreement, signature) 318 Other application-specific purposes for which the certified 319 public key may be used. 321 1.4 Validation Algorithm 323 The validation algorithm is determined by agreement between the 324 client and the server and is represented as an OID. The algorithm 325 defines the checking that will be performed by the server to 326 determine whether the certificate is valid, and it specifies any 327 parameters defined in the policy. A validation algorithm is 328 therefore one of the parameters to a validation policy. SCVP 329 defines a basic validation algorithm which implements the 330 certification path validation algorithm as defined in [PKIX-1]. 331 New validation algorithms can be specified that define additional 332 parameters if needed. 334 Application-specific validation algorithms in addition to those 335 defined in this document can be defined to meet specific 336 requirements not covered by the basic validation algorithm. The 337 validation algorithms documented here should serve as guide for the 338 development of further application-specific validation algorithms. 340 For example, a new application-specific validation algorithm might 341 require the presence of a particular name form in the subject 342 alternative name extension of the certificate. 344 For a certification path to be considered valid under a particular 345 validation policy, it MUST be a valid certification path as defined 346 in [PKIX-1] and all validation policy constraints that apply to the 347 certification path MUST be verified. 349 Revocation checking is one aspect of certification path validation 350 defined in [PKIX-1]. Therefore, the validation policy MUST specify 351 the source of revocation information. Five alternatives are 352 envisioned: 354 1. full CRLs (or full Authority Revocation Lists) have to be 355 collected; 357 2. OCSP responses, using [OCSP], have to be collected; 359 3. delta CRLs and the relevant associated full CRLs (or full 360 Authority Revocation Lists) are to be collected; 362 4. any available revocation information has to be collected; 363 and 365 5. no revocation information need be collected. 367 2 Protocol Overview 369 The SCVP uses a simple request-response model. That is, the SCVP 370 client creates a request and sends it to the SCVP server, and then 371 the SCVP server creates a single response and sends it to the 372 client. The typical use of SCVP is expected to be over HTTP [HTTP], 373 but it can also be used with email or any other protocol that can 374 transport digitally signed objects. Appendix A and Appendix B 375 provide the details necessary to use SCVP with HTTP. 377 SCVP includes two request-response pairs. The primary request- 378 response pair handles certificate validation. The secondary 379 request-response pair is used to determine the list of validation 380 policies and default parameters supported by a specific SCVP server. 382 Section 3 defines the certificate validation request. 384 Section 4 defines the corresponding certificate validation response. 386 Section 5 defines the validation policies request. 388 Section 6 defines the corresponding validation policies response. 390 Appendix A registers MIME types for SCVP requests and responses, 391 and Appendix B describes the use of these MIME types with HTTP. 393 3 Validation Request 395 A SCVP client request to the server MUST be a single CVRequest item. 396 When a CVRequest is encapsulated in a MIME body part, 397 application/cv-request MUST be used. 399 There are two forms of SCVP request: unsigned and signed. A signed 400 request is used to authenticate the client to the server or to 401 provide an anonymous client integrity over the request-response 402 pair. A server MAY require all requests to be signed, and a server 403 MAY discard all unsigned requests. Alternatively, a server MAY 404 choose to process unsigned requests. 406 The unsigned request consists of a CVRequest encapsulated in a CMS 407 ContentInfo [CMS]. An overview of these structures are provided 408 below and are only intended as illustrative. The definitive ASN.1 409 is found in [CMS]. Many details are not shown, but the way that 410 SCVP makes use of CMS is clearly illustrated. 412 ContentInfo { 413 contentType id-ct-scvp-certValRequest, 414 -- (1.2.840.113549.1.9.16.1.10) 415 content CVRequest } 417 The signed request consists of a CVRequest encapsulated in either a 418 SignedData or AuthenticatedData which is in turn encapsulated in a 419 ContentInfo. An overview of these structures are provided below. 420 Again, many details are not shown, but the way that SCVP makes use 421 of CMS is clearly illustrated. 423 SignedData example: 425 ContentInfo { 426 contentType id-signedData, -- (1.2.840.113549.1.7.2) 427 content SignedData } 429 SignedData { 430 version CMSVersion, 431 digestAlgorithms DigestAlgorithmIdentifiers, 432 encapContentInfo EncapsulatedContentInfo, 433 certificates [0] IMPLICIT CertificateSet Optional, 434 crls [1] IMPLICIT CertificateRevocationLists 435 Optional, 436 signerInfos SET OF SignerInfo } -- only one in SCVP 438 SignerInfo { 439 version CMSVersion, 440 sid SignerIdentifier, 441 digestAlgorithm DigestAlgorithmIdentifier, 442 signedAttrs SignedAttributes, -- Required 443 signatureAlgorithm SignatureAlgorithmIdentifier, 444 signature SignatureValue, 445 unsignedAttrs UnsignedAttributes } -- not used in SCVP 447 EncapsulatedContentInfo { 448 eContentType id-ct-scvp-certValRequest, 449 -- (1.2.840.113549.1.9.16.1.10) 450 eContent OCTET STRING } -- Contains CVRequest 452 AuthenticatedData example: 454 ContentInfo { 455 contentType id-ct-authData, 456 -- (1.2.840.113549.1.9.16.1.2) 457 content AuthenticatedData } 459 AuthenticatedData { 460 version CMSVersion, 461 originatorInfo OriginatorInfo, -- Optional 462 recipientInfos RecipientInfos, -- Only SCVP server 463 macAlgorithm MessageAuthenticationCodeAlgorithm, 464 digestAlgorithm DigestAlgorithmIdentifier, -- Optional 465 encapContentInfo EncapsulatedContentInfo, 466 authAttrs AuthAttributes, -- Required 467 mac MessageAuthenticationCode, 468 unauthAttrs UnauthAttributes } -- not used in SCVP 470 EncapsulatedContentInfo { 471 eContentType id-ct-scvp-certValRequest, 472 -- (1.2.840.113549.1.9.16.1.10) 473 eContent OCTET STRING } -- Contains CVRequest 475 All SCVP clients MUST support SignedData for signed requests and 476 responses. An SCVP client SHOULD support authenticatedData for 477 signed requests and responses. 479 If the client uses signedData it MUST have a public key that has 480 been bound to a subject identity by a certificate that conforms to 481 the PKIX profile [PKIX-1] and that certificate MUST be suitable for 482 signing the SCVP request. That is: 484 If the key usage extension is present, either the digital 485 signature or the non-repudiation bit MUST be asserted. 487 If the extended key usage extension is present, it MUST contain 488 either the client authentication OID, the SCVP client OID, or 489 some other OID by agreement with the SCVP server. 491 The client MUST put an unambiguous reference to its certificate in 492 the SignedData or AuthenticatedData request. The client SHOULD 493 include the signers certificate in the request, but MAY omit the 494 certificate to reduce the size of the request. The client MAY 495 include other certificates in the request to aid the validation of 496 the signers certificates by the SCVP server. 498 The syntax and semantics for SignedData, AuthenticatedData, and 499 ContentInfo are defined in [CMS]. The syntax and semantics for 500 CVRequest are defined below. The CVRequest item contains the 501 client request. The CVRequest contains the cvRequestVersion and 502 query items; and the CVRequest MAY also contain the requestorRef, 503 requestNonce, and requestExtensions items. 505 The CVRequest MUST have the following syntax: 507 CVRequest ::= SEQUENCE { 508 cvRequestVersion INTEGER, 509 query Query, 510 requestorRef [0] SEQUENCE SIZE (1..MAX) OF OCTET STRING 511 OPTIONAL, 512 requestNonce [1] OCTET STRING OPTIONAL, 513 requestExtensions [2] Extensions OPTIONAL 514 dhPublicKey [3] DHPublicKey OPTIONAL} 516 Each of the items within the CVRequest is described in the 517 following sections. 519 3.1 cvRequestVersion 521 The cvRequestVersion item defines the version of the SCVP CVRequest 522 used in a request. The subsequent response MUST use the same 523 version number. The value of the cvRequestVersion item MUST be one 524 (1) for a client implementing this specification. Future updates 525 to this specification must specify other values if there are any 526 changes to syntax or semantics. 528 query item specifies one or more certificates that are the object 529 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 sequence of one or more queriedCerts items as well 532 as one checks, one wantBack and one validationPolicy item; and a 533 query MAY also contain responseRefHash, responseValidationPolByRef, 534 signResponse, serverContextInfo, validationTime, intermediateCerts, 535 revInfos, producedAt, and queryExtensions items. 537 Query MUST have the following syntax: 539 Query ::= SEQUENCE { 540 queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, 541 checks CertChecks, 542 wantBack WantBack, 543 validationPolicy ValidationPolicy, 544 responseFlags ResponseFlags OPTIONAL, 545 serverContextInfo [0] OCTET STRING OPTIONAL, 546 validationTime [1] GeneralizedTime OPTIONAL, 547 intermediateCerts [2] CertBundle OPTIONAL, 548 revInfos [3] RevocationInfos OPTIONAL, 549 producedAt [4] GeneralizedTime OPTIONAL, 550 queryExtensions [5] Extensions OPTIONAL } 552 The list of certificate references in the query item tells the 553 server the certificate(s) for which the client wants information. 554 The checks item specifies the checking that the client wants 555 performed. The wantBack item specifies the objects that the client 556 wants the server to return in the response. The validationPolicy 557 item specifies the validation policy that the client wants the 558 server to employ. The requestRefHash, responseValidationPolByRef 559 and signResponse items allow the client to request optional 560 features for the response. The serverContextInfo item tells the 561 server that additional information from a previous request-response 562 is desired. The validationTime item tells the date and time 563 relative to which the client wants the server to perform the checks. 564 The intermediateCerts and revInfos items provide context for the 565 client request. The queryExtensions item provides for future 566 expansion of the query syntax. The syntax and semantics of each of 567 these items is discussed in the following sections. 569 3.1.1 queriedCerts 571 The queriedCerts item, using the CertReference type, identifies the 572 certificate that is the object of the request. The certificate is 573 either a public key certificate or an attribute certificate. The 574 certificate is either directly included or it is referenced. When 575 referenced, a SHA-1 hash value [SHA-1] of the referenced item is 576 included to ensure that the SCVP client and the SCVP server both 577 obtain the same certificate when the referenced certificate is 578 fetched. Certificate references use the ESSCertID type defined in 579 [ESS]. CertReference has the following syntax: 581 CertReference ::= CHOICE { 582 pkc PKCReference, 583 ac ACReference } 585 PKCReference ::= CHOICE { 586 cert [0] Certificate, 587 pkcRef [1] ESSCertID } 589 ACReference ::= CHOICE { 590 attrCert [2] AttributeCertificate, 591 acRef [3] ESSCertID } 593 The ASN.1 definition of Certificate is imported from [PKIX-1]; the 594 definition of AttributeCertificate is imported from [PKIX-AC]; and 595 the definition of ESSCertID is imported from [ESS]. 597 3.1.2 checks 599 The checks item describes the checking that the SCVP client wants 600 the SCVP server to perform on the certificate(s) in the 601 queriedCerts item. The checks item MUST contain a sequence of 602 object identifiers (OIDs). Each OID tells the SCVP server what 603 checking the client expects the server to perform. For each check 604 specified in the request, the SCVP server MUST perform all of the 605 requested checks, or return an error. 607 Revocation status checking inherently includes certification path 608 construction. Also, building a validated certification path does 609 not imply revocation status checks. A server may still choose to 610 perform revocation status checks when performing path construction, 611 although this information cannot be returned to the client. 613 The checks item uses the CertChecks type, which has the following 614 syntax: 616 CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 618 A list of OIDs indicates the checking that the client wants the 619 SCVP server to perform on the certificate(s) in the queriedCerts 620 item. 622 For public key certificates, OIDs are defined for the following 623 checks: 625 - Build a certification path to a trust anchor; 627 - Build a validated certification path to a trust anchor; and 629 - Do revocation status checks on the certification path. 631 For attribute certificates, OIDs are defined for the following 632 checks: 634 - Build a certification path to a trust anchor for the AC 635 issuer; 637 - Build a validated certification path to a trust anchor for the 638 AC issuer; 640 - Do revocation status checks on the certification path for the 641 AC issuer; and 643 - Do revocation status checks on the AC as well as the 644 certification path for the AC issuer. 646 For these purposes, the following OIDs are defined: 648 id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 649 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 } 651 id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 } 652 id-stc-build-status-checked-pkc-path 653 OBJECT IDENTIFIER ::= { id-stc 2 } 654 id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 4 } 655 id-stc-build-status-checked-aa-path 656 OBJECT IDENTIFIER ::= { id-stc 5 } 658 3.1.3 wantBack 660 The wantBack item describes the kind of information the SCVP client 661 wants from the SCVP server for the certificate(s) in the 662 queriedCerts item. The wantBack item MUST contain a sequence of 663 object identifiers (OIDs). Each OID tells the SCVP server what the 664 client wants to know about the queriedCerts item. For each type of 665 information specified in the request, the server MUST return 666 information regarding its finding (in a successful response). 668 For example, a request might include a checks item that only 669 specifies certification path building and include a wantBack item 670 that requests the return of the certification path built by the 671 server. In this case, the response would not include a status for 672 the validation of the certification path, but it would include a 673 certification path that the server considers to be valid. A client 674 that wants to perform its own certification path validation might 675 use a request of this form. 677 Alternatively, a request might include a checks item that requests 678 the server to build a certification path and validate it, including 679 revocation checking, and include a wantBack item that requests the 680 return of the status. In this case, the response would include 681 only a status for the validation of the certification path. A 682 client that completely delegates certification path validation 683 might use a request of this form. 685 The wantBack item uses the WantBack type, which has the following 686 syntax: 688 WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 690 For public key certificates, the types of information that can be 691 requested are: 693 - The certificate that was validated; 694 - The certification path built for the certificate including the 695 certificate that was validated; 697 - Proof of revocation status for each certificate in the 698 certification path; 700 - Status indication; and 702 - The public key from the certificate. 704 For attribute certificates, the types of information that can be 705 requested are: 707 - The attribute certificate that was validated; 709 - The certification path built for the AC issuer certificate; 711 - Proof of revocation status for each certificate in the AC 712 issuer certification path; 714 - Proof of revocation status for the attribute certificate; and 716 - Status indication. 718 The client can also request a non-cached response to the request by 719 including wantback id-swb-non-cached-resp in the request. 721 For these purposes, the following OIDs are defined: 723 id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 724 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 } 726 id-swb-pkc-best-cert-path OBJECT IDENTIFIER ::= { id-swb 1 } 727 id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 } 728 id-swb-pkc-cert-status OBJECT IDENTIFIER ::= { id-swb 3 } 729 id-swb-pkc-public-key-info OBJECT IDENTIFIER ::= { id-swb 4 } 730 id-swb-aa-cert-path OBJECT IDENTIFIER ::= { id-swb 5 } 731 id-swb-aa-revocation-info OBJECT IDENTIFIER ::= { id-swb 6 } 732 id-swb-ac-revocation-info OBJECT IDENTIFIER ::= { id-swb 7 } 733 id-swb-ac-cert-status OBJECT IDENTIFIER ::= { id-swb 8 } 734 id-swb-non-cached-resp OBJECT IDENTIFIER ::= { id-swb 9 } 735 id-swb-pkc-cert OBJECT IDENTIFIER ::= { id-swb 10} 736 id-swb-ac-cert OBJECT IDENTIFIER ::= { id-swb 11} 737 id-swb-pkc-all-valid-cert-paths OBJECT IDENTIFIER ::= { id-swb 13} 739 3.1.4 validationPolicy 741 The validationPolicy item, defines the validation policy The 742 validationPolicy item defines the validation policy that the client 743 wants the SCVP server to use during certificate validation. If 744 this policy cannot be used for any reason, then the server MUST 745 return an error response. 747 The client and server can optionally agree on a set of parameters 748 which may fully or partially define a validation policy. If the 749 policy defines all parameters necessary for processing an SCVP 750 request, then the client need only supply a reference to the policy 751 in this item. If a partial set of parameters has been agreed upon, 752 then the client supplies a reference to the policy plus whatever 753 parameters are necessary to complete the request in this item. 755 The syntax of the validationPolicy item is: 757 ValidationPolicy ::= SEQUENCE { 758 validationPolRef ValidationPolRef, 759 validationAlg [0] ValidationAlg OPTIONAL, 760 userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT 761 IDENTIFIER OPTIONAL, 762 inhibitPolicyMapping [2] BOOLEAN OPTIONAL, 763 requireExplicitPolicy [3] BOOLEAN OPTIONAL, 764 inhibitAnyPolicy [4] BOOLEAN OPTIONAL, 765 isCA [5] BOOLEAN OPTIONAL, 766 trustAnchors [6] TrustAnchors OPTIONAL, 767 keyUsages [7] SEQUENCE SIZE (1..MAX) OF KeyUsage 768 OPTIONAL, 769 extendedKeyUsages [8] ExtKeyUsageSyntax OPTIONAL} 771 The validationPolRef item is required, but the remainder of the 772 items are optional. The optional items are used to provide 773 validation policy parameters. When the validation policy has no 774 parameters, all of the optional items are absent. The 775 validationAlg item specifies the validation algorithm. The 776 userPolicySet item provides an acceptable set of certificate 777 policies. The inhibitPolicyMapping item inhibits certificate 778 policy mapping during certification path validation. The 779 requireExplicitPolicy item requires at least one valid certificate 780 policy in the certificate policies extension. The inhibitAnyPolicy 781 item indicates whether the any-policy certificate policy OID is 782 processed or ignored when evaluating certificate policy. The isCA 783 item indicates whether the client expects the certificate subject 784 to be a CA. The trustAnchors item indicates the trust anchors that 785 are acceptable to the client. The keyUsages item indicates the 786 technical usage of the public key that is to be confirmed by the 787 server as acceptable. The extendedKeyUsages item indicates the 788 application-specific usage of the public key that is to be 789 confirmed by the server as acceptable. The syntax and semantics of 790 each of these items is discussed in the following sections. 792 3.1.4.1 validationPolRef 793 The reference to the validation policy can be either an OID or a 794 URI. In either case, the client and server have agreed that the 795 value represents a particular validation policy. The URI can point 796 to a human readable definition of the policy to facilitate correct 797 configuration. 799 - serverContextInfo; and 801 - the client's signature on the request. 803 The syntax of the ValidationPolRef item is: 805 ValidationPolRef::= CHOICE { 806 valPolRefByOID [0] OBJECT IDENTIFIER, 807 valPolRefByURI [1] IA5String} 809 SCVP servers SHOULD support serverContextInfo. SCVP clients MAY 810 support serverContextInfo 812 3.1.5 validationAlg 814 The validationAlg item, defines the validation algorithm to be used 815 by the SCVP server during certificate validation. The value of 816 this item can be determined by agreement between the client and the 817 server, and is represented as an object identifier. The server 818 might want to assign additional object identifiers that indicate 819 that some settings are used in addition to others given in the 820 request. In this way, the validation algorithm object identifier 821 can be a shorthand for some SCVP options, but not others. 823 The validationAlg item uses the ValidationAlg type, which has the 824 following syntax: 826 ValidationAlg ::= SEQUENCE { 827 valAlgId OBJECT IDENTIFIER, 828 parameters ANY DEFINED BY valAlgId OPTIONAL } 830 3.1.5.1 Default Validation Algorithm 832 The client can request the SCVP server's default validation policy 833 or another validation policy. The object identifier to identify 834 the default validation policy is: 836 id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 837 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 } 839 id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 } 841 The default validation policy MUST use the basic validation 842 algorithm (see section 3.1.5.2.1). 844 When using the default validation policy, the client can override 845 any of the default parameter values by supplying a specific value 846 in the request. The SCVP server MUST make use of the provided 847 parameter values or return an error response. 849 All SCVP servers MUST support the default policy, but local policy 850 MAY require the server to send an error response to all requests 851 using the default policy. 853 Neither the clients nor server MUST dereference the URI during SCVP 854 request processing. The URI is simply used as a reference for the 855 validation policy. Clients and server MAY dereference the URI as 856 part of configuration. 858 The syntax of the validationPolRef is: 860 ValidationPolRef ::= CHOICE { 861 valPolRefByOID [0] OBJECT IDENTIFIER, 862 valPolRefByURI [1] IA5String } 864 If there are any conflicts between the non-default policy 865 referenced in the request and any supplied parameter values in the 866 request, then the server MUST return an error response. 868 3.1.5.2 validationAlg 870 The optional validationAlg item defines the validation algorithm to 871 be used by the SCVP server during certificate validation. The 872 value of this item can be determined by agreement between the 873 client and the server, and the validation algorithm is represented 874 by an object identifier. 876 The syntax of the validationAlg is: 878 ValidationAlg ::= SEQUENCE { 879 valAlgId OBJECT IDENTIFIER, 880 parameters ANY DEFINED BY valAlgId OPTIONAL } 882 The following section specifies the basic validation algorithm and 883 the name validation algorithm. SCVP clients and servers MUST 884 support both validation algorithms defined in this section. Other 885 validation algorithms can be specified in other documents for use 886 with specific applications. SCVP clients and servers MAY support 887 any such validation algorithms. 889 3.1.5.2.1 Basic Validation Algorithm 891 The client can request use of the SCVP basic validation algorithm 892 or another algorithm. The basic validation algorithm implements 893 the full certification path validation algorithm as defined in 894 section 6 of [PKIX-1]. Other validation algorithms MAY implement 895 functions over and above those in the basic algorithm, but 896 validation algorithms MUST generate results compliant with the 897 basic validation algorithm. That is, none of the validation 898 requirements in the basic algorithm can be omitted from any newly 899 defined validation algorithms. However, other validation 900 algorithms MAY reject paths which are valid using the basic 901 validation algorithm. The object identifier to identify the basic 902 validation algorithm is: 904 id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 } 906 When id-svp-basicValAlg appears as in valAlgId, the parameters item 907 MUST be absent. 909 The meaning of the default validation algorithm is: 911 - Trust anchors will come from the trustAnchors item. If no 912 certificates are specified in the trustAnchors item, then 913 the SCVP server will use trust anchors of its own choosing. 915 - The acceptable policy set will come from the userPolicySet 916 item. If no certificate policies are specified in the 917 userPolicySet item, then the SCVP server will use any-policy. 919 - The SCVP server will check for certificate revocation using 920 CRLs, delta CRLs, OCSP responses, or any other source of 921 revocation information that is available. 922 3.1.5.2.2 Basic Validation Algorithm Errors 924 The following errors are defined for the basic validation 925 algorithm: 927 id-bvae OBJECT IDENTIFIER ::= id-svp-basicValAlg 929 id-bvae-expired OBJECT IDENTIFIER ::= { id-bvae 1 } 930 id-bvae-notYetValid OBJECT IDENTIFIER ::= { id-bvae 2 } 931 id-bvae-wrong-Anchor OBJECT IDENTIFIER ::= { id-bvae 3 } 932 id-bvae-partial-chain OBJECT IDENTIFIER ::= { id-bvae 4 } 933 id-bvae-invalid-Key-Usage OBJECT IDENTIFIER ::= { id-bvae 10 } 934 id-bvae-invalid-Purpose OBJECT IDENTIFIER ::= { id-bvae 11 } 935 id-bvae-invalid-Policy OBJECT IDENTIFIER ::= { id-bvae 12 } 936 id-bvae-invalid-Name OBJECT IDENTIFIER ::= { id-bvae 13 } 937 id-bvae-invalid-Entity OBJECT IDENTIFIER ::= { id-bvae 14 } 938 id-bvae-invalid-Depth OBJECT IDENTIFIER ::= { id-bvae 15 } 940 The id-bvae-expired value means that the validation time used for 941 the request was later than the notAfter time in the certificate. 943 The id-bvae-notYetValid value means that the validation time used 944 for the request was before the notBefore time in the certificate. 946 The id-bvae-wrong-Anchor value means that a certification path was 947 able to be constructed but that the trust anchor for the path was 948 not one of the trust anchors required. 950 The id-bvae-partial-chain value means that a certification path was 951 unable to be constructed to any trust anchor. 953 The id-bvae-invalid-Key-Usage value means that one of the 954 certificates in the certification path has the wrong key 955 usage(PKIX-1 section 4.2.1.3). The key in a CA certificate can 956 verify a certificate, but the key usage in the certificate does not 957 contain the cert sign bit. 959 The id-bvae-invalidPurpose value means that one of the certificates 960 in the certification path has the wrong purpose (PKIX-1 section 961 4.2.1.13). 963 The id-bvae-invalidCertPolicy value means that some part of 964 certificate policy evaluation has failed. For example, the 965 requested policy was not valid in the certificate or the request 966 explicit policy is true and there are no valid certificate polices. 968 The id-bvae-invalidName value means that one of the names in one of 969 the certificates in the certification path violates a name 970 constraints extension in a parent certificate. 972 The id-bvae-invalidEntity value means that one of the entity types 973 in the certification pathas defined in the basic constraints 974 extension is invalid. That is, an end entity has signed a 975 certificate. 977 The id-bvae-invalidPathDepth value means that the certification 978 path length violates the path length constraints in the basic 979 constraints extension. 981 3.1.5.2.3 Name Validation Algorithm 983 The name validation algorithm allows the client to supply an 984 application identifier and a name to the server. The application 985 identifier defines the name matching rules to use in comparing the 986 name supplied in the request with the names in the certificate. 988 id-svp-NameValAlg OBJECT IDENTIFIER ::= { id-svp 2 } 989 id-svp-dnValAlg OBJECT IDENTIFIER ::= { id-svp 4 } 991 When the id-svp-NameValAlg appears as a valAlgId, the parameters 992 MUST use the NameValidationAlgParms syntax: 994 NameValidationAlgParms ::= SEQUENCE { 995 keyPurposeId KeyPurposeId, 996 validationNames GeneralNames } 998 KeyPurposeId and GeneralNames are defined in [PKIX-1]. 1000 If more than one name is supplied in the validationNames value, all 1001 names MUST be of the same type and be valid according to the name 1002 matching rules associated with the KeyPurposeId. 1004 If the keyPurposeID supplied in the request is id-svp-dnValAlg, 1005 then GeneralNames supplied in the request MUST be a DN name, and 1006 the matching rules to be used are defined in [PKIX-1]. 1008 If the keyPurposeID supplied in the request is id-kp-serverAuth 1009 [PKIX-1], then GeneralNames supplied in the request MUST be a DNS 1010 name, and the matching rules to be used are defined in [HTTP-TLS]. 1012 If the keyPurposeID supplied in the request is id-kp-mailProtection 1013 [PKIX-1], then GeneralNames supplied in the request MUST be a 1014 rfc822Name, and the matching rules are defined in [SMIME-CERT]. 1016 SCVP server MUST support the name validation algorithms for id-svp- 1017 dnValAlg, id-kp-serverAuth, id-kp-mailProtection. SCVP server may 1018 suport other name validation algorithms. 1020 3.1.5.2.4 Name Validation Algorithm Errors 1022 The following errors are defined for the Name Validation Algorithm 1024 id-nvae OBJECT IDENTIFIER ::= id-svp-NameValAlg 1026 id-nvae-name-mismatch OBJECT IDENTIFIER ::= { id-nvae 1 } 1027 id-nvae-no-name OBJECT IDENTIFIER ::= { id-nvae 2 } 1028 id-nvae-unknown-pupose OBJECT IDENTIFIER ::= { id-nvae 3 } 1029 id-nvae-bad-name OBJECT IDENTIFIER ::= { id-nvae 4 } 1030 id-nvae-bad-name-type OBJECT IDENTIFIER ::= { id-nvae 5 } 1031 id-nvae-mixed-names OBJECT IDENTIFIER ::= { id-nvae 6 } 1033 The id-nvae-nameMismatch value means the client supplied a name 1034 with the validation policy, which the server recognized and the 1035 server found corresponding name type in the certificate, but was 1036 unable to find a match to the name supplied. For example, the 1037 client supplied a DNS name of example1.com, the certificate 1038 contained a DNS name of example.com. 1040 The id-nvae-noCertName value means the client supplied a name with 1041 the validation policy, which the server recognized, but the server 1042 could not find the corresponding name type in the certificate. For 1043 example, the client supplied a DNS name of example1.com, the 1044 certificate only contained a rfc822Name of user@example.com. 1046 The id-nvae-unknownPupose value means the client supplied 1047 KeyPurposeID which the server does not recognize. 1049 The id-nvae-badName value means the client supplied either and 1050 empty or malformed name in the request. 1052 The id-nvae-badNameType value means the client supplied an 1053 inappropriate name type for the key purpose. For example, the 1054 client specified a key purpose ID of id-kp-serverAuth, and a rfc822 1055 name of user@example.com. 1057 The id-nvae-mixedNames value means the client supplied multiple 1058 names in the request of different types. 1060 The userPolicySet item specifies a list of policy identifiers that 1061 the SCVP server MUST use when forming and validating a certificate 1062 If certPolicies is not specified, then any-policy MUST be used. 1064 3.1.5.3 userPolicySet 1066 The userPolicySet item specifies a list of certificate policy 1067 identifiers that the SCVP server MUST use when constructing and 1068 validating a certification path. If userPolicySet is not specified, 1069 then any-policy MUST be used. 1071 SCVP clients SHOULD support userPolicySet item in requests, and 1072 SCVP servers MUST support userPolicySet item in requests. 1074 3.1.5.4 inhibitPolicyMapping 1076 The inihibitPolicyMapping specifies an input to the certification 1077 path validation algorithm, and it controls whether policy mapping 1078 is allowed in the certification path validation (see [PKIX-1], 1079 section 6.1.1). By default the server allows policy mapping as 1080 part of certification path validation. If the client wants the 1081 server to inhibit policy mapping, inhibitPolicyMapping is set to 1082 TRUE in the request. 1084 SCVP clients and servers MUST support the default behavior. SCVP 1085 clients MAY support inhibiting policy mapping. SCVP servers SHOULD 1086 support inhibiting policy mapping. 1088 3.1.5.5 requireExplicitPolicy 1090 The requireExplicitPolicy specifies an input to the certification 1091 path validation algorithm, and it controls whether there must be at 1092 least one valid policy in the certificate policies extension (see 1093 [PKIX], section 6.1.1). By default the server accepts no policies 1094 in the certificate policies extension of valid certificates. If 1095 the client wants the server to require at least one policy, 1096 requireExplicitPolicy is set to TRUE in the request. 1098 SCVP clients and servers MUST support the default behavior. SCVP 1099 clients MAY support requiring explicit policies. SCVP server 1100 SHOULD support requiring explicit policies. 1102 3.1.5.6 inhibitAnyPolicy 1104 The inhibitAnyPolicy specifies an input to the certification path 1105 validation algorithm (see [PKIX], section 6.1.1), and it controls 1106 whether the any-policy OID is processed or ignored when evaluating 1107 certificate policy. By default the server processes the any-policy 1108 OID. If the client wants the server to ignore the any-policy OID, 1109 inhibitAnyPolicy MUST be set to TRUE in the request. If the value 1110 is absent in the request or the value is set to FALSE, the server 1111 MUST process the any-policy OID. 1113 SCVP clients and servers MUST support the default behavior. SCVP 1114 clients MAY support ignoring the any-policy OID. SCVP servers 1115 SHOULD support ignoring the any-policy OID. 1117 3.1.5.7 isCA 1119 The isCA specifies whether the client expects the certificate 1120 subject to be a CA. This corresponds to CA BOOLEAN value in the 1121 basic constraints extension [PKIX-1, 4.2.1.10]. 1123 If the client requires the entity type of certificate being 1124 validated to be a CA, then it MUST set the value of isCA to be TRUE 1125 in the request. 1127 If the client requires the subject to be an end entity, then it 1128 MUST set the value to FALSE. 1130 If the client does not care about the entity type, then it MUST 1131 omit the BOOLEAN value. If the BOOLEAN value is omitted from the 1132 request and the client submits a CA certificate as the subject of 1133 the validation request, then a server MUST NOT treat this as an 1134 error. 1136 SCVP client and server MUST support the default behavior. SCVP 1137 client SHOULD support setting the BOOLEAN value to TRUE, and the 1138 SVCP client MAY support setting the BOOLEAN value to FALSE. SCVP 1139 server MUST support the isCA BOOLEAN being set to either TRUE or 1140 FALSE. 1142 3.1.5.8 trustAnchors 1143 The trustAnchors item specifies the trust anchors at which the 1144 certification path must terminate in if the path is to be 1145 considered valid by the SCVP server for the request. If a 1146 trustAnchors item is present, the server MUST NOT consider any 1147 certification paths ending in other trust anchors as valid. 1149 The TrustAnchors type contains one or more trust anchor 1150 specification. A certificate reference can be used to identify the 1151 trust anchor by certificate hash and optionally a distinguished 1152 name with serial number. Alternatively, trust anchors can be 1153 provided directly. The order of trust anchor specifications within 1154 the sequence is not important. Any CA certificate which meets the 1155 requirements of [PKIX-1] for signing certificates can be provided 1156 as a trust anchor. If a trust anchor is supplied which does not 1157 meet these requirements, the server MUST return an error response. 1159 The trust anchor itself, regardless of its form, MUST NOT be 1160 included in any certification path returned by the SCVP server. 1162 TrustAnchors has the following syntax: 1164 TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF PKCReference 1166 SCVP server MUST support TrustAnchors. SCVP clients SHOULD support 1167 trust anchors. 1169 3.1.5.9 keyUsages 1171 The key usage extension [PKIX-1, section 4.2.1.3] in the 1172 certificate defines the technical purpose (such as encipherment, 1173 signature, and certificate signing) of the key contained in the 1174 certificate. If the client wishes to confirm the technical usage, 1175 then they can communicate the usage they want to validate by the 1176 same structure using the same semantics as defined in [PKIX-1]. 1177 Therefore, if the client obtained the certificate in the context of 1178 a digital signature, they can confirm this use by including a 1179 keyUsage structure with the digital signature bit set. 1181 The keyUsages item can contain one or more keyUsage definitions to 1182 allow the client to search for a set of patterns any one of which 1183 is acceptable to the client. If the client whishes to match 1184 against multiple possibilities that the client pass in a sequence 1185 of possible patterns. Each keyUasge can contain a set of one or 1186 more bits set in the request, all bits MUST be present in the 1187 certificate to match against an instance of the keyUsage in the 1188 SCVP request. If the certificate key usage extension contains more 1189 usages than requested, then the certificate MUST be considered a 1190 match. Therefore if a client whishes to check for either digital 1191 signature or non-repudiation, then the client provides two keyUsage 1192 values, one with digital signature set, and the other with non- 1193 repudiation set. If the key usage extension is absent from the 1194 certificate, the certificate MUST be considered good for all usages 1195 therefore any pattern in the SCVP request will match. 1197 SCVP clients SHOULD support keyUsages, and SCVP servers MUST 1198 support keyUsages. 1200 3.1.5.10 extendedKeyUsages 1202 The extended key usage extension [PKIX-1, section 4.2.1.13] defines 1203 more abstract technical purposes in addition to or in place of the 1204 purposes indicated in the key usage extension for which the 1205 certified public key may be used. If the client wishes to confirm 1206 the extended key usage, then they can communicate the usage they 1207 want to validate by the same extension using the same semantics as 1208 defined in [PKIX-1]. Therefore if the client obtained the 1209 certificate in the context of a TLS server, they can confirm this 1210 usage by including the extended key usage structure with the id-kp- 1211 serverAuth object identifier. If more than one usage is set in the 1212 request, all usages MUST be present in the certificate. If the 1213 certificate extension contains more usages than requested, then the 1214 certificate MUST be considered a match. 1216 SCVP clients SHOULD support extendedKeyUsages, and SCVP servers 1217 MUST support extendedKeyUsages. 1219 3.1.6 responseFlags 1221 The optional response flags item allows the client to indicate 1222 which optional features in the CVResponse it wants the server to 1223 include. If the default values for all of the flags are used, then 1224 the response flags item MUST NOT be included in the request. 1226 The syntax of the responseFlags is: 1228 ResponseFlags ::= SEQUENCE { 1229 responseRefHash BOOLEAN DEFAULT TRUE, 1230 responseValidationPolByRef BOOLEAN DEFAULT TRUE, 1231 signResponse BOOLEAN DEFAULT TRUE } 1233 Each of the response flags is described in the following sections. 1235 3.1.6.1 responseRefHash 1237 The responseRefHash controls how the server identifies the request 1238 to which it is responding. By default, the server includes a hash 1239 of the request in the response. If the client wants the server to 1240 include the full request in the response, responseRefHash is set to 1241 FALSE. The main reason a client would request the server to 1242 include the full request in the response is to archive the request- 1243 response exchange in a single object. That is, the client wants to 1244 archive a single object which includes both request and response. 1246 SCVP clients and servers MUST support the default behavior. SCVP 1247 clients MAY support requesting and processing the full request. 1248 SCVP servers SHOULD support returning the full request. 1250 3.1.6.2 responseValidationPolByRef 1252 The responseValidationPolByRef controls whether the response 1253 includes by reference or by value the validation policy used to 1254 process the request. By default the response will contain 1255 references to the validation policy. If the client wants the 1256 validation policy to be included by value, then the 1257 responseValidationPolByRef is set to FALSE. The main reason a 1258 client would request the server to include validation policy to be 1259 included by value is to archive the request-response exchange in a 1260 single object. That is, the client wants to archive the CVResponse 1261 and have it include every aspect of the validation policy. 1263 SCVP clients and servers MUST support the default behavior. SCVP 1264 clients MAY support requesting and processing the 1265 responseValidationPolByRef. SVCP server SHOULD support returning 1266 the responseValidationPolByRef. 1268 3.1.6.3 signResponse 1270 The signResponse indicates whether the client requires the server 1271 to sign the response. If the client is performing full 1272 certification path validation on the response and it is not 1273 concerned about the source of the response, then the client does 1274 not benefit from a signature on the response. In this case, the 1275 client can indicate to the server that a signature is unnecessary. 1276 However, the server is always permitted to return a signed response. 1278 SCVP clients that support delegated path discovery (DPD) as defined 1279 in [RQMTS] MUST support setting this value to FALSE. 1281 SCVP clients that support delegated path validation (DPV) as 1282 defined in [RQMTS] require a signed response. Such clients MUST 1283 always set this value to TRUE or accept the default behavior, which 1284 requires the server to return a signed response. 1286 SCVP servers MUST support returning signed responses, and SCVP 1287 servers SHOULD support returning unsigned responses. Based on 1288 local policy, the server can be configured return signed or 1289 unsigned responses if this value is set to FALSE. 1291 3.1.7 serverContextInfo 1293 The optional serverContextInfo item, if present, contains context 1294 from a previous request-response exchange with the same SCVP server. 1295 It allows the server to return more than one certification path for 1296 the same certificate to the client. For example, if a server 1297 constructs a particular certification path for a certificate, but 1298 the client finds it unacceptable, the client can then send the same 1299 query back to the server with the serverContextInfo from the first 1300 response, and the server will be able to provide a different 1301 certification path (if another one can be found). 1303 Contents of the serverContextInfo are opaque to the SCVP client. 1304 That is, the client only knows that it needs to return the value 1305 provided by the server with the subsequent request to get a 1306 different certification path. Note that the subsequent query needs 1307 be essentially identical to the previous query. The client MUST 1308 NOT change any items other than: 1310 - requestNonce; 1312 - serverContextInfo; and 1314 - the client's signature on the request. 1316 SCVP clients MAY support serverContextInfo, and SCVP servers SHOULD 1317 support serverContextInfo. 1319 3.1.8 valididationTime 1321 The optional validationTime item, if present, tells the date and 1322 time relative to which the SCVP client wants the server to perform 1323 the checks. If the validationTime is not present, the server MUST 1324 perform the validation using the date and time at which the server 1325 processes the request. If the validationTime is present, it MUST 1326 be encoded as GeneralizedTime. The validationTime provided MUST be 1327 a retrospective time since the server can only perform a validity 1328 check using the current time (default) or previous time. A Server 1329 can ignore the validationTime provided in the request if the time 1330 is within the clock skew of the servers current time. 1332 GeneralizedTime values MUST be expressed Universal Coordinated Time 1333 (UTC) (which is also known as Greenwich Mean Time and Zulu time) 1334 and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even 1335 when the number of seconds is zero. GeneralizedTime values MUST 1336 NOT include fractional seconds. 1338 The information in the corresponding CertReply item in the response 1339 MUST be formatted as if the server created the response at the time 1340 indicated in the validationTime. However, if the server does not 1341 have appropriate historical information, the server MUST return an 1342 error response. 1344 SCVP servers MUST apply a clock skew to the validity time to allow 1345 for minor time synchronization errors. The default value is 10 1346 minutes. If the server uses a value other than the default it MUST 1347 include the clock skew value in the validation policy response. 1349 SCVP clients MAY support validationTime other than the current time. 1350 SCVP servers MUST support using its current time, and SHOULD 1351 support the client setting the validationTime in the request. 1353 3.1.9 intermediateCerts 1355 The optional intermediateCerts item helps the SCVP server create 1356 valid certification paths. The intermediateCerts item, when 1357 present, provides certificates that the server MAY use when forming 1358 a certification path. The certificates in the intermediateCerts 1359 item MAY be used by the server in addition to any other 1360 certificates that the server can access when building certification 1361 paths. When present, the intermediateCerts item MUST contain at 1362 least one certificate, and the intermediateCerts item MUST be 1363 structured as a CertBundle. The certificates in the 1364 intermediateCerts MUST NOT be considered as valid by the server 1365 just because they are present in this item. 1367 The CertBundle type contains one or more certificate references. 1368 The order of the entries in the bundle is not important. 1369 CertBundle has the following syntax: 1371 CertBundle ::= SEQUENCE SIZE (1..MAX) OF Certificate 1373 SCVP clients SHOULD support intermediateCerts, and SCVP servers 1374 MUST support intermediateCerts. 1376 3.1.10 revInfos 1378 The optional revInfo item specifies revocation information such as 1379 CRLs, delta CRLs [PKIX-1], and OCSP responses [OCSP] that the SCVP 1380 server MAY use this information when validating certification paths. 1381 The purpose of the revInfos item is to provide revocation 1382 information to which the server might not otherwise have access, 1383 such as an OCSP response that the client received along with the 1384 certificate. Note that the information in the revInfos item might 1385 not be used by the server. For example, the revocation information 1386 might be associated with certificates that the server does not use 1387 in the certification path that it constructs. 1389 Clients SHOULD be courteous to the SCVP server by separating CRLs 1390 and delta CRLs. However, since the two share a common syntax, SCVP 1391 servers SHOULD accept delta CRLs even if they are identified as 1392 regular CRLs by the SCVP client. 1394 CRLs, delta CRLs, and OCSP responses can be provided as revocation 1395 information. If needed, additional object identifiers can be 1396 assigned for additional revocation information types in the future. 1398 The revInfos item uses the RevocationInfos type, which has the 1399 following syntax: 1401 RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo 1403 RevocationInfo ::= CHOICE { 1404 crl [0] CertificateList, 1405 delta-crl [1] CertificateList, 1406 ocsp [2] OCSPResponse, 1407 other [3] OtherRevInfo } 1409 OtherRevInfo ::= SEQUENCE { 1410 riType OBJECT IDENTIFIER, 1411 riValue ANY DEFINED BY riType } 1413 3.1.11 producedAt 1415 The client MAY allow the server to use a cached SCVP response. 1416 When doing so, the client uses the producedAt item to express 1417 requirements on the freshness of the cached response. The 1418 producedAt item tells the earliest date and time at which an 1419 acceptable cached response could have been produced. The 1420 producedAt item represents the date and time in UTC, using the 1421 GeneralizedTime type. The value in the producedAt item is 1422 independent of the validation time. 1424 GeneralizedTime value MUST be expressed in UTC, as defined in 1425 section 3.1.8. 1427 SCVP client MAY support using producedAt values in the request. 1428 SCVP server SHOULD support the producedAt values in the request. 1430 3.1.12 queryExtensions 1432 The optional queryExtensions item contains Extensions. If present, 1433 each extension in the sequence extends the query. This 1434 specification does not define any extensions, the facility is 1435 provided to allow future specifications to extend SCVP. The syntax 1436 for extensions is imported from [PKIX-1]. The queryExtensions item, 1437 when present, MUST contain a sequence of extension items, and each 1438 of extension MUST contain extnID, critical, and extnValue items. 1439 Each of these is described in the following sections. 1441 3.1.12.1 extnID 1443 The extnID item is an identifier for the extension. It contains 1444 the object identifier that names the extension. 1446 3.1.12.2 critical 1447 The critical item is a BOOLEAN. Each extension is designated as 1448 either critical (with a value of TRUE) or non-critical (with a 1449 value of FALSE). By default, the extension is non-critical. An 1450 SCVP server MUST reject the query if it encounters a critical 1451 extension that it does not recognize; however, a non-critical 1452 extension MAY be ignored if it is not recognized. 1454 3.1.12.3 extnValue 1456 The extnValue item is an octet string, which contains the extension 1457 value. An ASN.1 type is specified for each extension, identified 1458 by the associated extnID object identifier. 1460 3.2 requestorRef 1462 The optional requestorRef item is a local reference to the client, 1463 and it is intended for use in environments where SCVP relay is 1464 employed. As described in [REQMTS], some network environments a 1465 SCVP server might not be able to obtain all of the information that 1466 it needs to process a request. However, the SCVP server might be 1467 configured to use the services of one or more other SCVP servers to 1468 fulfill all requests. In such cases, the client is unaware that 1469 the queried SCVP server is using the services of other SCVP servers, 1470 and the client-queried SCVP server acts as a SCVP client to another 1471 SCVP server. Unlike the original client, the SCVP server is 1472 expected to have moderate computing and memory resources, enabling 1473 the use of relay, re-direct or multicasting mechanisms. The 1474 requestorRef item is needed by SCVP servers that act as client to 1475 other SCVP servers in order to match a response to the original 1476 request which triggered it. The requestorRef item is also needed 1477 to prevent looping in some configurations. The value is of local 1478 significance to the client, and the server MUST threat this as an 1479 opaque value. To detect loops, the server MUST inspect the 1480 sequence of octet strings, looking for values that it inserted as a 1481 client. 1483 If the SCVP client includes a requestorRef value in the request, 1484 then the SCVP server MUST return the same value in a non-cached 1485 response. The SCVP server MAY omit the requestorRef value from 1486 cached SCVP responses. 1488 The requestorRef item MUST be an octet string. No provisions are 1489 made to ensure uniqueness of the requestorRef octet string; however, 1490 all of the octets MUST have values other than zero. 1492 3.3 requestNonce 1494 The optional requestNonce item contains a request identifier 1495 generated by the SCVP client. If the client includes a 1496 requestNonce value in the request, it is expressing a preference 1497 the SCVP server SHOULD return a non-cached response. If the server 1498 returns a non-cached response it MUST include the requestNonce from 1499 the request in the response; however, the server MAY return a 1500 cached success response which MUST NOT have a requestNonce. If the 1501 client includes a requestNonce and also sets a wantBack of id-swb- 1502 nonCachedRespRequired, the client is indicating that the SCVP 1503 server MUST return either a non-cached response including the 1504 requestNonce or an error response. The client SHOULD include a 1505 requestNonce item in every request to prevent an attacker from 1506 acting as a man-in-the-middle by replaying old responses from the 1507 server. The requestNonce value SHOULD change with every request 1508 sent by the client. The client MUST NOT include the wantBack of 1509 id-swb-nonCachedRespRequired without a requestNonce, and a server 1510 receiving such a request SHOULD return an invalidRequest error 1511 response. 1513 The requestNonce item, if present, MUST be an octet string that was 1514 generated exclusively for this request. 1516 3.4 requestExtensions 1518 The OPTIONAL requestExtensions item contains Extensions. If 1519 present, each Extension in the sequence extends the request. This 1520 specification does not define any extensions, the facility is 1521 provided to allow future specifications to extend the SCVP. The 1522 syntax for Extensions is imported from [PKIX-1]. The 1523 requestExtensionscvRequestExtensions item, when present, MUST 1524 contain a sequence of extension items, and each of extension MUST 1525 contain extnID, critical, and extnValue items. Each of these is 1526 described in the following sections. 1528 3.4.1 extnID 1530 The extnID item is an identifier for the extension. It contains 1531 the object identifier that names the extension. 1533 3.4.2 critical 1535 The critical item is a BOOLEAN. Each extension is designated as 1536 either critical (with a value of TRUE) or non-critical (with a 1537 value of FALSE). By default, the extension is non-critical. An 1538 SCVP server MUST reject the query if it encounters a critical 1539 extension it does not recognize. A non-critical extension MAY be 1540 ignored if it is not recognized, but MUST be processed if it is 1541 recognized. 1543 3.4.3 extnValue 1545 The extnValue item contains an octet string. Within the octet 1546 string is the extension value. An ASN.1 type is specified for each 1547 extension, identified by the associated extnID object identifier. 1549 3.5 dhPublicKey 1550 The dhPublicKey item is an optional Diffie-Hellamn public value. It 1551 is defined in PKIX-ALGS. When used in conjunction with the servers 1552 Diffie-Hellamn value it allows the client and server to compute a 1553 shared secret which can be used to integrity protect the SCVP 1554 request-response pair. If the client is not using a protected 1555 transport such as TLS, an does not have another mechanism to 1556 integrity protect the request-response pair such as a Kerberos 1557 session key or a signing public key, then the client SHOULD 1558 generate a DH key with the same parameters as the servers (see 1559 section Error! Reference source not found.) and use this to 1560 generate the shared secret with the servers public values and 1561 submit an authenticatedData request using the calculated shared 1562 secret for the HMAC secret. For the server to compute the shared 1563 secret, it must lean the public values the client generates, 1564 therefore the client MUST include this in the request if it uses 1565 this mechanism to integrity protect the request-response pair. The 1566 reuse by the client of the generated DH key across multiple 1567 requests is a matter of local policy. 1569 3.6 SCVP Request Authentication 1571 It is a matter of local policy what validation policy is used by 1572 the server when validating requests. When validating signed SCVP 1573 requests, the SCVP servers SHOULD use the validation algorithm 1574 defined in section 6 of PKIX-1. 1576 If the certificate used to validate a SignedData validation request 1577 includes the key usage extension [PKIX-1, section 4.2.1.3], it MUST 1578 have either the digital signature bit set, the non-repudiation bit 1579 set, or both bits set. 1581 If the certificate used to validate an AuthenticatedData validation 1582 request includes the key usage extension, it MUST have the key 1583 agreement bit set. 1585 If the certificates used on a validation request contains the 1586 extended Key Usage extension [PKIX-1, section 4.2.1.13], it is a 1587 matter of local policy which OID, if any, the server will check in 1588 the extension. The SCVP server MAY require the following OID 1590 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 1592 id-kp-scvpClient OBJECT IDENTIFIER ::= { id-kp 16 } 1594 If a signed request fails to meet the validation policy of the 1595 server, it MUST be treated as an unauthenticated request. 1597 4 Validation Response 1598 A SCVP server response to the client MUST be a single CVResponse 1599 item. When a CVResponse is encapsulated in a MIME body part, 1600 application/cv-response MUST be used. 1602 There are a number of forms of an SCVP response: 1604 1. A success response to a request made over a protected 1605 transport such as TLS. These responses SHOULD be unsigned by 1606 the server 1608 2. A success response to a request that has SignResponse set to 1609 FALSE. These responses SHOULD be unsigned by the server. 1611 3. All other success responses MUST be signed by the server. If 1612 the server is unable to return a signed success response due 1613 to local policy, then it MUST return an error response. 1615 4. A error response to a request made over a protected 1616 transport such as TLS. These responses SHOULD be unsigned by 1617 the server 1619 5. A error response to a request that has SignResponse set to 1620 FALSE. These responses SHOULD be unsigned by the server. 1622 6. An error response to an authenticated request. These 1623 responses MUST be signed by the server. 1625 7. An error response to an authenticatedData HMAC request where 1626 HMAC is valid. These responses MUST be signed by the server. 1628 8. All other error responses MUST NOT be signed by the server. 1630 Successful responses are be made when the server has fully complied 1631 with the request. That is, the server was able to build a 1632 certification path using the referenced or supplied validation 1633 policy, and it was able to comply with all the requested parameters. 1634 If the server is unable to build a certification path using the 1635 required validation policy or the request contains an unsupported 1636 option, then the server MUST return an error response. 1638 For signed requests and responses, SCVP servers MUST support 1639 SignedData, and AuthenticatedData. It is a matter of local policy 1640 which types are used. 1642 If the server is making a signed response to a signed request, then 1643 the server MUST use the same signature type (SignedData or 1644 AuthenticatedData) as in the request. 1646 An overview of the structure used for an unsigned response is 1647 provided below. Many details are not shown, but the way that SCVP 1648 makes use of CMS is clearly illustrated. 1650 ContentInfo { 1651 contentType id-ct-scvp-certValResponse, 1652 -- (1.2.840.113549.1.9.16.1.11) 1653 content CVResponse } 1655 The signed response consists of a CVResponse encapsulated in either 1656 a SignedData or an AuthenticatedData which is in turn encapsulated 1657 in a ContentInfo. An overview of the structure used for a signed 1658 response is provided below. As above, many details are not shown, 1659 but the way that SCVP makes use of CMS is clearly illustrated. 1661 SignedData Example: 1663 ContentInfo { 1664 contentType id-signedData, -- (1.2.840.113549.1.7.2) 1665 content SignedData } 1667 SignedData { 1668 version CMSVersion, 1669 digestAlgorithms DigestAlgorithmIdentifiers, 1670 encapContentInfo EncapsulatedContentInfo, 1671 certificates [0] IMPLICIT CertificateSet OPTIONAL, 1672 -- MUST include server cert 1673 crls [1] IMPLICIT CertificateRevocationLists 1674 OPTIONAL, 1675 signerInfos SET OF SignerInfos } 1676 -- Only one in SCVP 1678 SignerInfo { 1679 version CMSVersion, 1680 sid SignerIdentifier, 1681 digestAlgorithm DigestAlgorithmIdentifier, 1682 signedAttrs SignedAttributes, 1683 -- Required by CMS 1684 signatureAlgorithm SignatureAlgorithmIdentifier, 1685 signature SignatureValue, 1686 unsignedAttrs UnsignedAttributes } 1687 -- Not used in SCVP 1689 EncapsulatedContentInfo { 1690 eContentType id-ct-scvp-psResponse, 1691 -- (1.2.840.113549.1.9.16.1.11) 1692 eContent OCTET STRING } -- Contains CVResponse 1694 AuthenticatedData Example: 1696 ContentInfo { 1697 contentType id-ct-authData, 1698 -- (1.2.840.113549.1.9.16.1.2) 1699 content AuthenticatedData } 1701 AuthenticatedData ::= SEQUENCE { 1702 version CMSVersion, 1703 originatorInfo OriginatorInfo, 1704 recipientInfos RecipientInfos, 1705 -- Only for SCVP client 1706 macAlgorithm MessageAuthenticationCodeAlgorithm, 1707 digestAlgorithm DigestAlgorithmIdentifier, 1708 encapContentInfo EncapsulatedContentInfo, 1709 authAttrs AuthAttributes, 1710 -- Required by CMS 1711 mac MessageAuthenticationCode, 1712 unauthAttrs UnauthAttributes } 1713 -- Not used in SCVP 1715 EncapsulatedContentInfo { 1716 eContentType id-ct-scvp-psResponse, 1717 -- (1.2.840.113549.1.9.16.1.11) 1718 eContent OCTET STRING } -- Contains CVResponse 1720 The SCVP server MUST include its own certificate in the 1721 certificates field within SignedData. Other certificates can also 1722 be included. The SCVP server MAY also provide one or more CRLs in 1723 the crls field within SignedData. 1725 The signedAttrs within SignerInfo MUST include the content-type and 1726 message-digest attributes defined in [CMS], and it SHOULD include 1727 the signing-certificate attribute as defined in [ESS]. Within the 1728 signing-certificate attribute, the first certificate identified in 1729 the sequence of certificate identifiers MUST be the certificate of 1730 the SCVP server. The inclusion of other certificate identifiers in 1731 the signing-certificate attribute is OPTIONAL. The inclusion of 1732 policies in the signing-certificate is OPTIONAL. 1734 The CVResponse item contains the server response. The CVResponse 1735 MUST contain the cvRespVersion, policyID, producedAt, and 1736 respStatus items. The CVResponse MAY also contain the 1737 respValidationPolicy, requestorRef, requestorName, responder, 1738 replyObjects, respNonce, serverContextInfo, and respExtensions 1739 optional items. The replyObjects item MUST contain exactly one 1740 CertReply item for each certificate requested. The requestorRef 1741 and the responder items MUST be included if the request included a 1742 requestor item. The respNonce item MUST be included if the request 1743 included a requestNonce item and a non-cached response is provided. 1745 The CVResponse MUST have the following syntax: 1747 CVResponse ::= SEQUENCE { 1748 cvResponseVersion cvResponseVersion INTEGER, 1749 policyID INTEGER, 1750 producedAt GeneralizedTime, 1751 responseStatus ResponseStatus, 1752 respValidationPolicy [0] RespValPolicy OPTIONAL, 1753 requestRef [1] RequestReference OPTIONAL, 1754 requestorRef [2] OCTET STRING OPTIONAL, 1755 requestorName [3] GeneralNames OPTIONAL, 1756 responder [4] OCTET STRING OPTIONAL, 1757 replyObjects [5] ReplyObjects OPTIONAL, 1758 respNonce [6] OCTET STRING OPTIONAL, 1759 serverContextInfo [7] OCTET STRING OPTIONAL, 1760 cvResponseExtensions [8] Extensions OPTIONAL } 1762 4.1 cvResponseVersion 1764 The syntax and semantics of cvResponseVersion are the same as 1765 cvRequestVersion item is described in section 3.1. The 1766 cvResponseVersion MUST match the cvRequestVersion in the request. 1767 If the server cannot generate a response with a matching version 1768 number, then the server MUST return an error response that 1769 indicates the highest version number that the server supports as 1770 the version number. 1772 4.2 policyID 1774 The policy ID used by the SCVP server when it processed the request. 1775 See section 6.4 for details. 1777 4.3 producedAt 1779 The producedAt item tells the date and time at which the SCVP 1780 server generated the response. The producedAt item represents the 1781 date and time in UTC, using the GeneralizedTime type, and this 1782 value is independent of the validation time. 1784 GeneralizedTime value MUST be expressed in UTC, and it MUST be 1785 interpreted as defined in section 3.1.8. 1787 4.4 responseStatus 1789 The responseStatus item gives status information to the SCVP client 1790 about its request. The responseStatus item has a numeric status 1791 code and an optional string that is a sequence of characters from 1792 the ISO/IEC 10646-1 character set encoded with the UTF-8 1793 transformation format defined in [UTF8]. 1795 The string MAY be used to transmit status information. The client 1796 MAY choose to display the string to a human user. However, because 1797 there is often no way to know the languages understood by a human 1798 user, the string may be of little or no assistance. 1800 The responseStatus item uses the responseStatus type, which has the 1801 following syntax: 1803 ResponseStatus ::= SEQUENCE { 1804 statusCode CVStatusCode, 1805 errorMessage [0] UTF8String OPTIONAL } 1807 CVStatusCode ::= ENUMERATED { 1808 okay (0), 1809 skipUnrecognizedItems (1), 1810 tooBusy (10), 1811 invalidRequest (11), 1812 internalError (12), 1813 badStructure (20), 1814 unsupportedVersion (21), 1815 abortUnrecognizedItems (22), 1816 unrecognizedSigKey (23), 1817 badSignature (24), 1818 unableToDecode (25), 1819 notAuthorized (26), 1820 unsupportedChecks (27), 1821 unsupportedWantBacks (28), 1822 unsupportedSignature (29), 1823 invalidSignature (30), 1824 relayingLoop (40), 1825 unrecognizedValPol (50), 1826 unrecognizedValAlg (51), 1827 fullRequestRefUnsuported (52), 1828 fullPolResponseUnsuported (53), 1829 inhibitPolMapUnsuported (54), 1830 requireExpPolUnsuported (55), 1831 ignoreAnyPolUnsuported (56), 1832 validityTimeUnsuported (57), 1833 unrecognizedUserPolOID (60), 1834 unrecognizedValPolOID (61), 1835 unrecognizedValAlgOID (62), 1836 unrecognizedCritQueryExt (63), 1837 unrecognizedCritRequestExt (64)} 1839 The CVStatusCode values have the following meaning: 1841 0 The request was fully processed. 1842 1 The request included some unrecognized items; however, 1843 processing was able to continue ignoring them. 1844 10 Too busy; try again later. 1845 11 The server was able to decode the request, but there was 1846 some other problem with the request. 1847 12 An internal server error occurred. 1848 20 The structure of the request was wrong. 1849 21 The version of request is not supported by this server. 1850 22 The request included unrecognized items, and the server was 1851 not able to continue processing. 1852 23 The key given in the RequestSignature is not recognized. 1854 24 The signature or message authentication code did not match 1855 the body of the request. 1856 25 The encoding was not understood. 1857 26 The request was not authorized. 1858 27 The request included unsupported checks items, and the 1859 server was not able to continue processing. 1860 28 The request included unsupported want back items, and the 1861 server was not able to continue processing. 1862 29 The server does not support the signature or message 1863 authentication code algorithm used by the client to sign the 1864 request. 1865 30 The server could not validate the client's signature or 1866 message authentication code on the request. 1867 40 The request was previously relayed by the same server. 1868 50 The request contained an unrecognized validation policy 1869 reference. 1870 51 The request contained an unrecognized validation algorithm 1871 OID. 1872 52 The server does not support returning the full request in 1873 the response. 1874 53 The server does not support returning the full validation 1875 policy by value in the response. 1876 54 The server does not support inhibiting policy mapping. 1877 55 The server does not support requiring explicit policy. 1878 56 The server does not support ignoring the any-policy 1879 certificate policy OID. 1880 57 The server only validates requests using current time. 1881 60 The certificate policy OID is not recognized. 1882 61 The validation policy OID or URI is not recognized. 1883 62 The validation algorithm OID is not recognized. 1884 63 The query item in the request contains a critical extension 1885 whose OID is not recognized. 1886 64 The request contains a critical request extension whose OID 1887 is not recognized. 1889 Status codes 0-9 are reserved for codes where the request was 1890 processed by the server and therefore MUST be sent in a success 1891 response. Status codes 10 and above indicate an error and MUST 1892 therefore be sent in an unsigned error response. 1894 4.5 respValidationPolicy 1896 The respValidationPolicy item contains either a reference to the 1897 full validation policy or the full policy by value used by the 1898 server to validate the request. It MUST be present in success 1899 responses and MUST NOT be present in error responses. The choice 1900 between retuning either the policy by reference or by value is 1901 controlled by the fullPolicyResponse. The resultant validation 1902 policy is the union of the following: 1904 1. Values from the validation policy specified by reference in 1905 the request. 1907 2.. Values from the request. 1909 3. Default values used by the server for any parameter not 1910 specified by 1 or 2. 1912 The respValidationPolicy syntax is: 1914 RespValidationPolicy ::= SEQUENCE { 1915 validationPolRef ValidationPolRef, 1916 validationPolValues [0] ValidationPolValues OPTIONAL, 1917 userFinalPolicySet [1] SEQUENCE SIZE (1..MAX) OF 1918 OBJECT IDENTIFIER OPTIONAL, 1919 permittedSubtrees [2] SEQUENCE SIZE (1..MAX) OF 1920 GeneralNames OPTIONAL, 1921 excludedSubtrees [3] SEQUENCE SIZE (1..MAX) OF 1922 GeneralNames OPTIONAL } 1924 4.5.1 validationPolRef 1926 The validationPolRef item is defined in section 3.1.4.1. 1928 4.5.2 validationPolValues 1930 If a client request the validation policy by values instead of by 1931 reference then the server uses the validationPolicyValues structure 1932 to communicate the policy values it used to validate the request. 1934 The validationPolValues syntax is: 1936 ValidationPolValues ::=SEQUENCE { 1937 validationAlg ValidationAlg, 1938 inhibitPolMap BOOLEAN, 1939 requireExplicitPol BOOLEAN, 1940 inhibitAnyPol BOOLEAN, 1941 isCA BOOLEAN, 1942 trustAnchors TrustAnchors, 1943 keyUsage [0] KeyUsage OPTIONAL, 1944 extendedKeyUsage [1] ExtKeyUsageSyntax OPTIONAL, 1945 validationPolicyAttr [2] SEQUENCE SIZE (1..MAX) OF Attribute 1946 OPTIONAL } 1948 The optional keyUsage and ExtendedKeyUsage values are only 1949 necessary if there defined in the referenced policy or the client 1950 stated some requirements in the request. 1952 Each of these items is discussed in the following sections. 1954 4.5.2.1 validationAlg 1956 The validationAlg item is defined in section 3.1.5.2. 1958 4.5.2.2 inhibitPolMap 1960 The inhibitPolMap item is defined in section 3.1.5.4. 1962 4.5.2.3 requireExplicitPol 1964 The requireExplicitPol item is defined in section 3.1.5.5. 1966 4.5.2.4 inhibitAnyPol 1968 The inhibitAnyPol item is defined in section 3.1.5.6. 1970 4.5.2.5 isCA 1972 The isCA item is defined in section 3.1.5.7. 1974 4.5.2.6 trustAnchors 1976 The trustAnchors item is defined in section 3.1.5.8. 1978 4.5.2.7 keyUsage 1980 The optional keyUsage item is defined in [PKIX-1]. 1982 4.5.2.8 extendedKeyUsage 1984 The optional extendedKeyUsage item is defined in [PKIX-1].]3.1.5.4 1986 4.5.2.9 validationPolicyAttr 1988 The validationPolicyAtt item MAY contain Attributes. If present, 1989 each attribute in the sequence extends the policy values for the 1990 validation policy. This specification does not define any 1991 attributes. The facility is provided to allow future 1992 specifications to extend the SCVP. The syntax for Attribute is 1993 imported from [CMS]. 1995 4.5.3 userFinalPolicySet 1997 The userFinalPolicySet contains the set of valid policy OIDs from 1998 the valid-policy-tree as defined in [PKIX-1] section 6. The 1999 userFinalPolicySet MUST be populated if the valid-policy-tree from 2000 the validation is not NULL. userFinalPolicySet MUST be absent if 2001 the valid-policy-tree from the validation is NULL. 2003 4.5.4 permittedSubtrees 2004 permittedSubtrees is defined in [PKIX-1] section 6.1.2, This field 2005 MUST be populated when isCA is TRUE in the request and the 2006 validated path contains a non empty permitted-subtrees value. This 2007 field MAY be populated for other requests when the validated path 2008 contains a non empty permitted-subtrees value. 2010 4.5.5 excludedSubtrees 2012 excludedSubtrees is defined in [PKIX-1] section 6.1.2, This field 2013 MUST be populated when isCA is TRUE in the request and the 2014 validated path contains a non empty excluded-subtrees value. This 2015 field MAY be populated for other requests when the validated path 2016 contains a non empty excluded-subtrees value. 2018 4.5.6 validationPolicyAtt 2020 The validationPolicyAtt item MAY contain Attributes. If present, 2021 each attribute in the sequence extends the policy values for the 2022 validation policy. This specification does not define any 2023 attributes. The facility is provided to allow future specifications 2024 to extend the SCVP. The syntax for Attributes is imported from 2025 [CMS]. 2027 4.6 requestRef 2029 The requestRef allows the SCVP client to identify the request that 2030 corresponds to this response from the server. It associates the 2031 response to a particular request using either a hash of the request 2032 or a copy of CVRequest from the request. The hash is calculated as 2033 described in [CMS] for SignedData and AuthenticatedData. That is, 2034 it covers the encapsulated content and authenticated attributes but 2035 not the unauthenticated attributes. 2037 The requestRef item does not provide authentication, but the 2038 requestRef does allow the client to determine that the request was 2039 not maliciously modified. 2041 The requestRef item allows the client to associate a response with 2042 a request. The requestNonce provides an alternative mechanism for 2043 matching requests and responses if the client has selected to 2044 include a full response. When the fullRequest alternative is used, 2045 the response provides a single data structure that is suitable for 2046 archive of the transaction. 2048 The requestRef item uses the RequestReference type, which has the 2049 following syntax: 2051 RequestReference ::= CHOICE { 2052 requestHash [0] HashValue, -- hash of CVRequest 2053 fullRequest [1] CVRequest } 2055 SCVP clients MUST support requestHash, and they MAY support 2056 fullRequest. SCVP servers MUST support using requestHash, and they 2057 SHOULD support using fullRequest. 2059 4.6.1 requestHash 2061 The requestHash item is the hash of the CVRequest. By default, 2062 SHA-1 is used as the one-way hash function, but others can be used. 2063 The requestHash item serves two purposes. First, it allows a 2064 client to determine that the request was not maliciously modified. 2065 Second, it allows the client to associate a response with a request 2066 when using connectionless protocols. The requestNonce provides an 2067 alternative mechanism for matching requests and responses. 2069 The requestHash item uses the HashValue type, which has the 2070 following syntax: 2072 HashValue ::= SEQUENCE { 2073 algorithm AlgorithmIdentifier DEFAULT { sha-1 }, 2074 value OCTET STRING } 2076 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 2077 oiw(14) secsig(3) algorithm(2) 26 } 2079 The algorithm identifier for SHA-1 is imported from [PKIX-ALG]. It 2080 is repeated here for convenience. 2082 4.6.2 fullRequest 2084 Like requestHash, the fullRequest alternative allows a client to 2085 determine that the request was not maliciously modified. It also 2086 provides a single data structure that is suitable for archive of 2087 the transaction. 2089 The fullRequest item uses the CVRequest type. The syntax and 2090 semantics of the CVRequest type are described in section 3. 2092 4.7 requestorRef 2094 The optional requestorRef item is used by the client to identify 2095 the original requestor in cases where SCVP relay is used. The 2096 value is only of local significance to the client. If the SCVP 2097 client includes a requestorRef value in the request, then the SCVP 2098 server MUST return the same value if the server is generating a, 2099 non-cached response. 2101 4.8 requestorName 2103 The optional requestorName item is used by the server with signed 2104 requests to return the identity of the client in the response. 2106 Mechanisms for matching this identifier with the authenticated 2107 identity are a matter of local server policy. 2109 In the case of non-cached responses to signed requests, the SCVP 2110 server MUST return a requestor name. A server SHOULD copy the 2111 selected identifier from a certificate or other credential used to 2112 authenticate the request. A SCVP server MAY use a client 2113 identifier from an out-of-band mechanism or omit the identifier 2114 from the response. 2116 In the case of cached responses to signed requests, the 2117 RequestorName MAY be present in the response. 2119 SCVP server that supports signed requests MUST support this item. 2121 4.9 responder 2123 The optional responder item is used to identify the server. The 2124 value chosen is only of local significance to the SCVP server. The 2125 responder item MUST be included if the request included a 2126 requestorRef item. 2128 The responder item MUST be an octet string. No provisions are made 2129 to ensure uniqueness of the requestor octet string; however, all of 2130 the octets MUST have values other than zero. 2132 4.10 replyObjects 2134 The replyObjects item returns requested objects to the SCVP client, 2135 each of which tells the client about a single certificate from the 2136 request. The replyObjects item MUST be present in the response, 2137 unless the response is reporting an error. The CertReply item MUST 2138 contain cert, replyStatus, replyValTime, replyChecks, 2139 replyWantBacks, and valdationPolicy items; and the CertReply item 2140 MAY contain the nextUpdate and certReplyExtensions items. 2142 A success response MUST contain one CertReply for each Query item 2143 in the request. The order is important. The first CertReply in 2144 the sequence MUST correspond to the first Query item in the 2145 request; the second CertReply in the sequence MUST correspond to 2146 the second Query item in the request; and so on. 2148 The checks item in the request determines the content of the 2149 replyChecks item in the response. The wantBack item in the request 2150 determines the content of the replyWantBacks item in the response. 2151 The queryExtensions items in the request controls the absence or 2152 the presence and content of the certReplyExtensions item in the 2153 response. 2155 The replyObjects item uses the ReplyObjects type, which has the 2156 following syntax: 2158 ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply 2160 CertReply ::= SEQUENCE { 2161 cert CertReference, 2162 replyStatus ReplyStatus, 2163 replyValTime GeneralizedTime, 2164 replyChecks ReplyChecks, 2165 replyWantBacks ReplyWantBacks, 2166 validationErrors [0] SEQUENCE SIZE (1..MAX) OF 2167 OBJECT IDENTIFIER OPTIONAL, 2168 nextUpdate [1] GeneralizedTime OPTIONAL, 2169 certReplyExtensions [2] Extensions OPTIONAL } 2171 4.10.1 cert 2173 The cert item contains either the public key certificate or the 2174 attribute certificate or a reference to the certificate about which 2175 the client is requesting information. 2177 The ASN.1 definition of Certificate is imported from [PKIX-1]; and 2178 the definition of AttributeCertificate is imported from [PKIX-AC]. 2180 4.10.2 replyStatus 2182 The replyStatus item gives status information to the client about 2183 the request for the specific certificate. Note that the respStatus 2184 item is different than the replyStatus item. The respStatus item 2185 is the status of the whole request, while the replyStatus item is 2186 the status for the individual query item. 2188 The replyStatus item uses the ReplyStatus type, which has the 2189 following syntax: 2191 ReplyStatus ::= ENUMERATED { 2192 success (0), 2193 malformedPKC (1), 2194 malformedAC (2), 2195 unavailableValidityTime (3), 2196 referenceCertHashFail (4), 2197 certPathConstructFail (5), 2198 certPathNotValid (6), 2199 certPathNotValidNow (7) } 2201 The meaning of the various ReplyStatus values are: 2203 0 Success: a definitive answer follows. 2204 1 Failure: the public key certificate was malformed. 2205 2 Failure: the attribute certificate was malformed. 2206 3 Failure: historical data for the requested validity time is 2207 not available. 2209 4 Failure: the referenced certificate policy OID is not 2210 recognized. 2211 5 Failure: no certification path could be constructed. 2212 6 Failure: the constructed certification path is invalid. 2213 7 Failure: the constructed certification path is invalid, but 2214 a query at a later time may be successful. 2216 Codes 1 and 2 are used to tell the client that the request was 2217 properly formed, but the certificate in question was not. This is 2218 especially useful to clients that do not parse certificates. 2220 4.10.3 replyValTime 2222 The replyValTime item tells the time at which the information in 2223 the CertReply was correct. The replyValTime item represents the 2224 date and time in UTC, using GeneralizedTime type. The encoding 2225 rules for GeneralizedTime in section 3.1.8 MUST be used. 2227 Within the request, the optional validityTime item tells the date 2228 and time relative to which the SCVP client wants the server to 2229 perform the checks. If the validityTime is not present, the server 2230 MUST respond as if the client provided the date and time at which 2231 the server processes the request. 2233 The information in the CertReply item MUST be formatted as if the 2234 server created this portion of the response at the time indicated 2235 in the validityTime item of the query. However, if the server does 2236 not have appropriate historical information, the server MAY either 2237 return an error or return information for a later time. 2239 4.10.4 replyChecks 2241 The replyChecks contains the responses to the checks item in the 2242 query. The replyChecks item repeats the object identifier (OID) 2243 from the query and an integer. The value of the integer indicates 2244 whether the requested check was successful. The OIDs in the checks 2245 item of the query are used to identify the corresponding 2246 replyChecks values. The OIDs in the replyChecks item MUST match 2247 the OIDs in the checks item in the request. 2249 The replyChecks item uses the ReplyChecks type, which has the 2250 following syntax: 2252 ReplyChecks ::= SEQUENCE OF ReplyCheck 2254 ReplyCheck ::= SEQUENCE { 2255 check OBJECT IDENTIFIER, 2256 status INTEGER } 2258 The status value for public key certification path building to a 2259 trusted root, { id-stc 1 }, can be one of the following: 2261 0: Built a path 2262 1: Could not build a path 2264 The status value for public key certification path building to a 2265 trusted root along with simple validation processing, { id-stc 2 }, 2266 can be one of the following: 2268 0: Valid 2269 1: Not valid 2271 The status value for public key certification path building to a 2272 trusted root along with complete status checking, { id-stc 3 }, can 2273 be one of the following: 2275 0: Good 2276 1: Revoked 2277 2: Revocation Offline 2278 3: Revocation Unavailable 2280 Revocation offline means that the server or distribution point for 2281 the revocation information was connected to successfully without a 2282 network error but either no data returned or if data was returned 2283 it was stale. Revocation unavailable means that a network error was 2284 returned when an attempt was made to reach the server or 2285 distribution point. 2287 The status value for AC issuer certification path building to a 2288 trusted root, { id-stc 4 }, can be one of the following: 2290 0: Built a path 2291 1: Could not build a path 2293 The status value for AC issuer certification path building to a 2294 trusted root along with simple validation processing, { id-stc 5 }, 2295 can be one of the following: 2297 0: Valid 2298 1: Not valid 2300 The status value for AC issuer certification path building to a 2301 trusted root along with complete status checking, { id-stc 6 }, can 2302 be one of the following: 2304 0: Good 2305 1: Revoked 2306 2: Revocation Offline 2307 3: Revocation Unavailable 2309 The status value for revocation status checking of an AC as well as 2310 AC issuer certification path building to a trusted root along with 2311 complete status checking, { id-stc 7 }, can be one of the 2312 following: 2314 0: Good 2315 1: Revoked 2316 2: Offline 2317 3: Unavailable 2319 4.10.5 replyWantBack 2321 The replyWantBack contains the responses to the wantBack item in 2322 the request. The replyWantBack item includes the object identifier 2323 (OID) from the wantBack item in the request and an octet string. 2324 Within the octet string is the requested value. The OIDs in the 2325 wantBack item in the request are used to identify the corresponding 2326 reply value. The OIDs in the replyWantBack item MUST match the 2327 OIDs in the wantBack item in the request. 2329 The replyWantBack item uses the ReplyWantBack type, which has the 2330 following syntax: 2332 ReplyWantBacks ::= SEQUENCE OF ReplyWantBack 2334 ReplyWantBack::= SEQUENCE { 2335 wb OBJECT IDENTIFIER, 2336 value OCTET STRING } 2338 The octet string value for the certification path used to verify 2339 the certificate in the request, { id-swb 1 }, contains the 2340 CertBundle type. The syntax and semantics of the CertBundle type 2341 are described in section3.1.9. 2343 The octet string value for the proof of revocation status, { id-swb 2344 2 }, contains the RevocationInfos type. The syntax and semantics 2345 of the RevocationInfo type are described in section 3.1.10. 2347 The octet string value for the public key certificate status, { id- 2348 swb 3 }, contains an ASN.1 BOOLEAN type. The value will be TRUE if 2349 the certificate is valid, and the value will be FALSE if the 2350 certificate is not valid. 2352 The octet string value for the public key information, { id-swb 4 }, 2353 contains the SubjectPublicKeyInfo type. The syntax and semantics 2354 of the SubjectPublicKeyInfo type are described in [PKIX-1]. 2356 The octet string value for the AC issuer certification path used to 2357 verify the certificate in the request, { id-swb 5 }, contains the 2358 CertBundle type. The syntax and semantics of the CertBundle type 2359 are described in section 3.1.9. 2361 The octet string value for the proof of revocation status of the AC 2362 issuer certification path, { id-swb 6 }, contains the 2363 RevocationInfo type. The syntax and semantics of the 2364 RevocationInfo type are described in section 3.1.10. 2366 The octet string value for the proof of revocation status of the 2367 attribute certificate, { id-swb 7 }, contains the RevocationInfo 2368 type. The syntax and semantics of the RevocationInfo type are 2369 described in section 3.1.10. 2371 The octet string value for the attribute certificate status, { id- 2372 swb 8 }, contains an ASN.1 BOOLEAN type. The value will be TRUE if 2373 the certificate is valid, and the value will be FALSE if the 2374 certificate is not valid. 2376 4.10.6 validationAlg 2378 The validationAlg item indicates the validation algorithm used by 2379 the SCVP server. The server MUST include the validation algorithm 2380 that was used. 2382 The syntax and semantics of the validationAlg item are descried in 2383 section 3.1.5.2 2384 4.10.7 validationErrors 2386 The validationErrors item MUST only be present in failure 2387 responses. It MUST contains one or more OID representing the why 2388 the validation failed. 2390 4.10.8 nextUpdate 2392 The nextUpdate item tells the time at which the server expects a 2393 refresh of information regarding the validity of the certificate to 2394 become available. The nextUpdate is especially interesting if the 2395 certificate revocation status information is not available or the 2396 certificate is suspended. The nextUpdate item represents the date 2397 and time in UTC, using the GeneralizedTime type. The encoding 2398 rules for GeneralizedTime in section 3.1.8 MUST be used. 2400 4.10.9 certReplyExtensions 2402 The certReplyExtensions contains the responses to the 2403 queryExtension item in the request. The certReplyExtensions item 2404 uses the Extensions type defined in [PKIX-1]. The object 2405 identifiers (OIDs) in the queryExtension item in the request are 2406 used to identify the corresponding reply value. The 2407 certReplyExtensions item, when present, contains a sequence of 2408 Extension items, each of which contains an extnID item, a critical 2409 item, and an extnValue item. 2411 The extnID item is an identifier for the extension. It contains 2412 the OID that names the extension, and it MUST match one of the OIDs 2413 in the queryExtension item in the request. 2415 The critical item is a BOOLEAN, and it MUST be set to FALSE. 2416 The extnValue item contains an OCTET STRING. Within the OCTET 2417 STRING is the extension value. An ASN.1 type is specified for each 2418 extension, and identified by extnID. 2420 4.11 responseNonce 2422 The responseNonce item contains an identifier to binds the request 2423 to the response. 2425 If the client includes a requestNonce value in the request and 2426 the server is generating a specific non-cached response to the 2427 request then the server MUST return the same value in the 2428 response. 2430 If the server is using a cached response to the request then it 2431 MUST omit the responseNonce field. 2433 If the server is returning a specific non-cached response to a 2434 request without a once, then the server MUST use value of the 2435 message-digest attribute in the signedAttrs within SignerInfo of 2436 the request as the value in the responseNonce field. 2438 The requestNonce item uses the octet string type. 2440 Client SHOULD support and servers MUST support responseNonce. 2442 4.12 serverContextInfo 2444 The serverContextInfo item in a response is a mechanism for the 2445 server to pass some opaque context information to the client. If 2446 the client does not like the certification path retuned, it can 2447 make a new query and pass along this context information. 2449 Section 3.1.6 contains information about the client usage of this 2450 item. 2452 The context information is opaque to the client, but it provides 2453 information to the server that ensures that a different 2454 certification path will be returned (if another one can be found). 2455 The context information could indicate state on the server or it 2456 could contain a sequence of hashes of certification paths that have 2457 already been returned to the client. The protocol does not dictate 2458 any structure or requirements for this item. However, implementers 2459 should review the Security Considerations section of this document 2460 before selecting a structure. 2462 Servers that are incapable of returning additional paths MUST NOT 2463 include the serverContextInfo item in the response. 2465 4.13 respExtensions 2467 The respExtensions item MAY contain Extensions. If present, each 2468 Extension in the sequence extends the response. This specification 2469 does not define any extensions. The facility is provided to allow 2470 future specifications to extend the SCVP. The syntax for 2471 Extensions is imported from [PKIX-1]. The respExtensions item, 2472 when present, contains a sequence of Extension items, each of which 2473 contains an extnID item, a critical item, and an extnValue item. 2475 The extnID item is an identifier for the extension. It contains 2476 the object identifier (OID) that names the extension. 2477 The critical item is a BOOLEAN. Each extension is designated as 2478 either critical (with a value of TRUE) or non-critical (with a 2479 value of FALSE). An SCVP client MUST reject the response if it 2480 encounters a critical extension it does not recognize; however, a 2481 non-critical extension MAY be ignored if it is not recognized. 2483 The extnValue item contains an OCTET STRING. Within the OCTET 2484 STRING is the extension value. An ASN.1 type is specified for each 2485 extension, and identified by extnID. 2487 4.14 SCVP Response Validation 2489 There are two mechanisms for validation of SCVP responses, one 2490 based on the clients knowledge of a specific SCVP server key and 2491 the other based on validation of the certificate which signed the 2492 SCVP response 2494 4.14.1 Simple Key Validation 2496 Simple key validation method is where the SCVP client has a local 2497 policy of one or more SCVP server keys which directly identify the 2498 set of valid SCVP servers. Mechanisms for storage of server keys or 2499 identifiers is a local matter. For example, a client could store 2500 cryptographic hashes of public keys used to verify signedData 2501 responses. Alternatively, a client could store shared symmetric 2502 keys used to HMAC authenticatedData responses. 2504 Simple key validation MUST be used by SCVP clients that cannot 2505 validate PKIX-1 certificates and are therefore making delegated 2506 path validation requests to the SCVP server[RQTMS]. It is a matter 2507 of local policy with these clients whether to use signedData or 2508 authenticatedData. Simple key validation MAY be used by other SCVP 2509 clients for other reasons. 2511 4.14.2 SCVP Server Certificate Validation 2513 It is a matter of local policy what validation policy is used by 2514 the client when validating responses. When validating signed SCVP 2515 responses, SCVP clients SHOULD use the validation algorithm defined 2516 in section 6 of PKIX-1. 2518 If the certificate used to sign the validation policy responses and 2519 signedData validation responses contains the key usage extension 2520 [PKIX-1 section 4.2.1.3] it MUST have either the digital signature 2521 or the non-repudiation bits set or both. 2523 If the certificate for authenticatedData validation responses 2524 contains the key usage extension it MUST have the key agreement bit 2525 set. 2527 If the certificates used on a validation policy response or a 2528 validation response contains the extended Key Usage extension 2529 [PKIX-1 section 4.2.1.13] it MUST contain the following OID 2531 id-kp-scvpServer OBJECT IDENTIFIER ::= { id-kp 15 } 2533 5 Server Policy Request 2535 A SCVP client uses the valPolRequest item to request the list of 2536 validation policies supported by the SCVP server. When a 2537 valPolRequest is encapsulated in a MIME body part, it MUST be 2538 carried in an application/vp-request MIME body part. 2540 The request consists of a valPolRequest encapsulated in a 2541 ContentInfo. The request is not signed by the client. 2543 ContentInfo { 2544 contentType id-ct-scvp-valPolRequest, 2545 -- (1.2.840.113549.1.9.16.1.12) 2546 content valPolRequest } 2548 The valPolRequest type has the following syntax: 2550 VPRequest ::= SEQUENCE { 2551 vpRequestVersion INTEGER, 2552 requestNonce OCTET STRING} 2554 5.1 vpRequestVersion 2556 The vpRequestVersion item is described in section 3.1.requestNonce 2558 5.2 requestNonce 2560 The requestNonce item contains a request identifier generated by 2561 the SCVP client. If the server returns a specific response it MUST 2562 include the requestNonce from the request in the response, but MAY 2563 return a cached response which MUST NOT include a requestNonce. 2565 6 Validation Policy Response 2567 In response to a valPolRequest, the SCVP server provides a 2568 valPolResponse. The valPolResponse MAY not unique to any 2569 valPolRequest, so may be reused by the server in response to 2570 multiple vbalPolRequests. The valPolResponse also has an indication 2571 of how frequently the valPolResponse may be reissued. When a 2572 PolResponse is encapsulated in a MIME body part, it MUST be carried 2573 in an application/vp-response MIME body part. 2575 The response consists of a valPolResponse encapsulated in a 2576 ContentInfo. The response MUST be signed by the server using its 2577 digital signature certificate. 2579 ContentInfo { 2580 contentType id-ct-scvp-valPolResponse, 2581 -- (1.2.840.113549.1.9.16.1.13) 2582 content valPolResponse } 2584 The valPolResponse type has the following syntax: 2586 VPResponse ::= SEQUENCE { 2587 vpResponseVersion INTEGER, 2588 maxCVResponseVersion INTEGER, 2589 maxVPResponseVersion INTEGER, 2590 defaultPolicyID INTEGER, 2591 thisUpdate GeneralizedTime, 2592 nextUpdate GeneralizedTime OPTIONAL, 2593 validationPolices SEQUENCE OF ValidationPolRef, 2594 validationAlgs SEQUENCE OF OBJECT IDENTIFIER, 2595 authPolicies SEQUENCE OF AuthPolicy, 2596 responseTypes ResponseTypes, 2597 defaultPolicyValues ValidationPolValues, 2598 dhPublicKeyInfo SEQUENCE OF DHPublicKeyInfo, 2599 clockSkew [0] INTEGER OPTIONAL, 2600 requestNonce [1] OCTET STRING OPTIONAL } 2602 ResponseTypes ::= ENUMERATED { 2603 cached-only (0), 2604 specific-signed-only (1), 2605 cached-and-specific-signed (2)} 2607 SCVP clients that support validation policy requests MUST support 2608 SCVP responses. SCVP servers MUST support validation policy 2609 responses. 2611 SCVP servers MUST support cached policy responses and MAY support 2612 specific responses to policy request. 2614 6.1 vpResponseVersion 2616 The syntax and semantics of the vpResponseVersion item is described 2617 in section 3.1. The vpResponseVersion used MUST be the same as the 2618 vpRequestVersion unless the client has used a value grater than the 2619 values the server supports. If the client submits a 2620 vpRequestVersion grater then the version supported by the server, 2621 it MUST return an a vpResponseVersion using the highest version 2622 number the server supports as the version number. 2624 6.2 maxCVRequestVersion 2626 The maxCVRequestVersion defines the maximum version number for CV 2627 requests that the server supports 2629 6.3 maxVPRequestVersion 2631 The maxVPRequestVersion defines the maximum version number for VP 2632 requests that the server supports 2634 6.4 defaultPolicyID 2636 An integer that uniquely represents the version of the default 2637 validation policy as represented by the trustAnchors, 2638 validationPolicy, validationAlg, authPolicies, clockSkew and 2639 authDataCerts. If any of these values change, the server MUST 2640 create a new PolResponse with a new defaultPolicyID. If the policy 2641 and therefore the defaultPolicyID has not changed, then the server 2642 may reused defaultPolicyID across multiple PolResponse messages. 2643 However if the server having changed the policy, then reverts to an 2644 earlier policy, the server MUST NOT revert the policy ID as well, 2645 but MUST select another unique value. 2647 6.5 thisUpdate 2649 This field indicates the signing date & time of this policy 2650 response. 2652 GeneralizedTime values MUST be expressed Greenwich Mean Time (Zulu) 2653 and interpreted as defined in section 3.1.8. 2655 6.6 nextUpdate 2657 This optional field indicates the expected publication date & time 2658 of the next policy response. 2660 If this field is omitted it indicates a non-cached response 2661 generated in response to a specific request, then the polResponse 2662 is bound to a specific request. If this filed is omitted the 2663 requestNonce files MUST be present and the value copied from the 2664 request. 2666 If this field is preset it indicates a non-cached response, then 2667 the polResponse is not bound to a specific request. A SCVP server 2668 MUST periodically generate the new response as defined by the next 2669 update time and use the same polResponse used for multiple requests. 2671 It is a matter of local server policy to return a cached or non- 2672 cached specific response. 2674 GeneralizedTime values MUST be expressed Greenwich Mean Time (Zulu) 2675 as specified in section 3.1.8. 2677 6.7 trustAnchors 2679 The trustAnchors item specifies the default trust anchors that the 2680 SCVP server will use if the request references a validation policy 2681 which does not define any trust anchors and no trust anchors are 2682 present in the request. 2684 6.8 validationPolicies 2686 The validationPolicies item contains a sequence of ValidationPolRef 2687 representing the validation policies supported by the server. It is 2688 a matter of local policy if the server whishes to processes 2689 requests using the default validation policy, and if it does not, 2690 then it MUST NOT include the id-svp-defaultValPolicy in this list. 2692 6.9 validationAlgs 2694 The validationAlgs item contains a sequence of OIDs. Each OID 2695 identifies a validation algorithm supported by the server. 2697 6.10 authPolicies 2699 The authPolicies item contains a sequence of policy references for 2700 authenticating to the SCVP server. 2702 The reference to the authentication policy can be either an OID 2703 where the client and server have agreed the OID to represent a 2704 authentication policy or a URI where the URI points to a human 2705 readable definition of the policy. The list of policies is intended 2706 to document to the client if authentication is required for some 2707 requests and if so how. 2709 AuthPolicy ::= CHOICE { 2710 authPolRefByOID [0] OBJECT IDENTIFIER, 2711 authPolRefByURI [1] IA5String} 2713 6.11 responseTypes 2715 Response types allows the server to publish the range of response 2716 types it supports. Cache only means the server will only return 2717 cached responses to requests. Unique signed responses means the 2718 server will return a specific response to the request i.e. 2719 containing the requestors nonce. Both means the server will return 2720 either depending on the request. 2722 6.12 dhPublicKeyInfo 2724 The dhPublicKeyInfo is a sequence of one or more Diffie-Hellman 2725 public keys and associated parameters. It is used by clients making 2726 authenticatedData requests to the server. dhPublicKeyInfo has the 2727 following structure: 2729 DHPublicKeyInfo ::= SEQUENCE { 2730 dhPublicKey DHPublicKey, 2731 domainParameters DomainParameters} 2733 DHPublicKeyInformation MUST be supported by a SCVP server. SCVP 2734 serverS MUST support a 1536-bit MODP group key (group 5) as defined 2735 in [IKE-GROUPS]. SCVP servers MAY support other group keys as 2736 defined in [IKE] or [IKE-GROUPS]. 2738 6.13 clockSkew 2740 The clockSkew item is the number of minutes the server will allow 2741 for clock skew. If absent the server MUST use the default value of 2742 10 minutes. 2744 6.14 defaultValPolicy 2746 This is the default validation policy used by the server. It 2747 contains a VaidationPolValues which is defined in section 4.5 A 2748 server will use these default values when 2750 The request references the default validation policy and the 2751 client does not override the defaults vaues by supplying other 2752 values in the request 2754 The request references a non-default validation policy, which 2755 does not define every parameter necessary as defined by the 2756 validation algorithm and the client further omits these missing 2757 values from request. The server MUST use its default value for 2758 any parameter not defined by the referenced non-default policy, 2759 and not specified in the request. 2761 This allows the client to optimize the request by omitting 2762 parameters which match the server default values. 2764 7 SCVP Server Relay 2766 In some network environments, especially ones that include 2767 firewalls, an SCVP server might not be able to obtain all of the 2768 information that it needs to process a request. However, the 2769 server might be configured to use the services of one or more other 2770 SCVP servers to fulfill all requests. In such cases, the SCVP 2771 client is unaware that the initial SCVP server is using the 2772 services of other SCVP servers. The initial SCVP server acts as a 2773 client to another SCVP server. Unlike the original client, the 2774 SCVP server is expected to have moderate computing and memory 2775 resources. This section describes SCVP server-to-SCVP server 2776 exchanges. This section does not impose any requirements on SCVP 2777 clients that are not also SCVP servers. Further, this section does 2778 not impose any requirements on SCVP servers that do not relay 2779 requests to other SCVP servers. 2781 When one SCVP server relays a request to another server, in an 2782 incorrectly configured system of servers, it is possible that the 2783 same request will be relayed back again. Any SCVP server that 2784 relays requests MUST implement the conventions described in this 2785 section to detect and break loops. 2787 When an SCVP server relays a request, the request MUST include the 2788 requestor item. If the request to be relayed already contains a 2789 requestor item, then server-generated request MUST contain a 2790 requestor item constructed from this value followed by a zero octet 2791 followed by the identifier of the SCVP server. If the request to 2792 be relayed does not contain a requestor item, then server-generated 2793 request MUST contain only the identifier of the SCVP server. 2795 When an SVCP server receives a request that contains a requestor 2796 item, the server MUST check for its own identifier. The identifier 2797 could be located at the beginning of the octet string followed by a 2798 zero octet, or it could be located between two zero octets. If the 2799 server discovers its own identifier in the requestor item, it MUST 2800 respond with an error, setting the cvResponseStatus to 40. 2802 8 SCVP ASN.1 Module 2804 This section defines the syntax for SCVP request-response pairs. 2805 The semantics for the messages are defined in sections 3, 4, 5, and 2806 6. The SCVP ASN.1 module follows. 2808 SCVP 2810 { iso(1) identified-organization(3) dod(6) internet(1) 2811 security(5) mechanisms(5) pkix(7) id-mod(0) 21 } 2812 DEFINITIONS IMPLICIT TAGS ::= BEGIN 2814 IMPORTS 2816 DHPublicKey, DomainParameters 2817 FROM PKIX1Algorithms88 RFC 3279 2818 { iso(1) identified-organization(3) 2819 dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 2820 id-mod-pkix1-algorithms(17) 2822 AlgorithmIdentifier, Certificate, Extensions, GeneralNames, 2823 UTF8String, CertificateList, keyPurposeId 2824 FROM PKIX1Explicit88 -- RFC 3280 2825 { iso(1) identified-organization(3) dod(6) internet(1) 2826 security(5) mechanisms(5) pkix(7) id-mod(0) 18 } 2828 AttributeCertificate 2829 FROM PKIXAttributeCertificate -- RFC 3281 2830 { iso(1) identified-organization(3) dod(6) internet(1) 2831 security(5) mechanisms(5) pkix(7) id-mod(0) 12 } 2833 ESSCertID FROM ExtendedSecurityServices -- RFC 2634 2834 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 2835 pkcs-9(9) smime(16) modules(0) 2 } ; 2837 -- SCVP Certificate Validation Request 2839 id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2840 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2841 id-smime(16) 1 } 2843 id-ct-scvp-certValRequest OBJECT IDENTIFIER ::= { id-ct 10 } 2845 CVRequest ::= SEQUENCE { 2846 cvRequestVersion INTEGER, 2847 query Query, 2848 requestorRef [0] SEQUENCE SIZE (1..MAX) OF OCTET STRING 2849 OPTIONAL, 2850 requestNonce [1] OCTET STRING OPTIONAL, 2851 reqestExtensions [2] Extensions OPTIONAL, 2852 dhPublicKey [3] DHPublicKey OPTIONAL} 2854 Query ::= SEQUENCE { 2855 queriedCerts SEQUENCE SIZE (1..MAX) OF 2856 CertReference, 2857 checks CertChecks, 2858 wantBack WantBack, 2859 validationPolicy ValidationPolicy, 2860 responseFlags ResponseFlags OPTIONAL, 2861 serverContextInfo [0] OCTET STRING OPTIONAL, 2862 validationTime [1] GeneralizedTime OPTIONAL, 2863 intermediateCerts [2] CertBundle OPTIONAL, 2864 revInfos [3] RevocationInfos OPTIONAL, 2865 producedAt [4] GeneralizedTime OPTIONAL, 2866 queryExtensions [5] Extensions OPTIONAL } 2868 CertReference::= CHOICE { 2869 pkc PKCReference, 2870 ac ACReference } 2872 PKCReference ::= CHOICE { 2873 cert [0] Certificate, 2874 pkcRef [1] ESSCertID } 2876 ACReference ::= CHOICE { 2877 attrCert [2] AttributeCertificate, 2878 acRef [3] ESSCertID } 2880 ValidationPolicy ::= SEQUENCE { 2881 validationPolRef ValidationPolRef, 2882 validationAlg [0] ValidationAlg OPTIONAL, 2883 userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT 2884 IDENTIFIER OPTIONAL, 2885 inhibitPolicyMapping [2] BOOLEAN OPTIONAL, 2886 requireExplicitPolicy [3] BOOLEAN OPTIONAL, 2887 inhibitAnyPolicy [4] BOOLEAN OPTIONAL, 2888 isCA [5] BOOLEAN OPTIONAL, 2889 trustAnchors [6] TrustAnchors OPTIONAL, 2890 keyUsages [7] SEQUENCE SIZE (1..MAX) OF KeyUsage 2891 OPTIONAL, 2892 extendedKeyUsages [8] ExtKeyUsageSyntax OPTIONAL} 2894 CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 2896 WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 2898 ValidationPolRef ::= CHOICE { 2899 valPolRefByOID [0] OBJECT IDENTIFIER, 2900 valPolRefByURI [1] IA5String} 2902 ValidationAlg ::= SEQUENCE { 2903 valAlgId OBJECT IDENTIFIER, 2904 parameters ANY DEFINED BY valAlgId OPTIONAL } 2906 nameValidationAlg ::= SEQUENCE { 2907 keyPurposeId OBJECT IDENTIFIER, 2908 validationName GeneralNames } 2910 TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF PKCReference 2911 ResponseFlags ::= SEQUENCE { 2912 responseRefHash BOOLEAN DEFAULT TRUE, 2913 responseValidationPolByRef BOOLEAN DEFAULT TRUE, 2914 signResponse BOOLEAN DEFAULT TRUE } 2916 CertBundle ::= SEQUENCE SIZE (1..MAX) OF PKCReference 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 cvResponseVersion INTEGER, 2936 policyID INTEGER, 2937 producedAt GeneralizedTime, 2938 responseStatus ResponseStatus, 2939 respValidationPolicy [0] RespValPolicy OPTIONAL, 2940 requestRef [1] RequestReference OPTIONAL, 2941 requestorRef [2] OCTET STRING OPTIONAL, 2942 requestorName [3] GeneralNames OPTIONAL, 2943 responder [4] OCTET STRING 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 badSignature (24), 2964 unableToDecode (25), 2965 notAuthorized (26), 2966 unsupportedChecks (27), 2967 unsupportedWantBacks (28), 2968 unsupportedSignature (29), 2969 invalidSignature (30), 2970 relayingLoop (40), 2971 unrecognizedValPol (50), 2972 unrecognizedValAlg (51), 2973 fullRequestRefUnsuported (52}, 2974 fullPolResponseUnsuported (53), 2975 inhibitPolMapUnsuported (54), 2976 requireExpPolUnsuported (55), 2977 ignoreAnyPolUnsuported (56), 2978 validityTimeUnsuported (57), 2979 unrecognizedUserPolOID (60), 2980 unrecognizedValPolOID (61), 2981 unrecognizedValAlgOID (62), 2982 unrecognizedCritQueryExt (63), 2983 unrecognizedCriticalExt (64)} 2985 RespValidationPolicy ::= SEQUENCE { 2986 validationPolRef ValidationPolRef, 2987 validationPolValues [0] ValidationPolValues OPTIONAL 2988 userFinalPolicySet [1] SEQUENCE SIZE (1..MAX) OF 2989 OBJECT IDENTIFIER OPTIONAL 2990 permittedSubtrees [2] SEQUENCE SIZE (1..MAX) OF 2991 GeneralNames OPTIONAL 2992 excludedSubtrees [3] SEQUENCE SIZE (1..MAX) OF 2993 GeneralNames OPTIONAL} 2995 ValidationPolValues ::=SEQUENCE { 2996 validationAlg ValidationAlg, 2997 inhibitPolMap BOOLEAN DEFAULT FALSE, 2998 requireExplicitPol BOOLEAN DEFAULT FALSE, 2999 inhibitAnyPol BOOLEAN DEFAULT FALSE, 3000 isCA BOOLEAN DEFAULT FALSE, 3001 trustAnchors TrustAnchors, 3002 keyUsage [0] KeyUsage OPTIONAL, 3003 extendedKeyUsage [1] ExtKeyUsageSyntax OPTIONAL, 3004 validationPolicyAtt [2] SEQUENCE SIZE (1..MAX) OF Attribute 3005 OPTIONAL } 3007 RequestReference ::= CHOICE { 3008 requestHash [0] HashValue, -- hash of CVRequest 3009 fullRequest [1] CVRequest } 3011 HashValue ::= SEQUENCE { 3012 algorithm AlgorithmIdentifier DEFAULT { sha-1 }, 3013 value OCTET STRING } 3015 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3016 oiw(14) secsig(3) algorithm(2) 26 } 3018 ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply 3020 CertReply ::= SEQUENCE { 3021 cert CertReference, 3022 replyStatus ReplyStatus, 3023 replyValTime GeneralizedTime, 3024 replyChecks ReplyChecks, 3025 replyWantBacks ReplyWantBacks, 3026 validationErrors [0] SEQUENCE SIZE (1..MAX) OF 3027 OBJECT IDENTIFIER OPTIONAL, 3028 nextUpdate [1] GeneralizedTime OPTIONAL, 3029 certReplyExtensions [2] Extensions OPTIONAL } 3031 ReplyCertificate ::= CHOICE { 3032 pkc [1] Certificate, 3033 ac [2] AttributeCertificate } 3035 ReplyStatus ::= ENUMERATED { 3036 success (0), 3037 malformedPKC (1), 3038 malformedAC (2), 3039 unavailableValidityTime (3), 3040 referenceCertHashFail (4), 3041 certPathConstructFail (5), 3042 certPathNotValid (6), 3043 certPathNotValidNow (7)} 3045 ReplyChecks ::= SEQUENCE OF ReplyCheck 3047 ReplyCheck ::= SEQUENCE { 3048 check OBJECT IDENTIFIER, 3049 status INTEGER } 3051 ReplyWantBacks ::= SEQUENCE OF ReplyWantBack 3053 ReplyWantBack::= SEQUENCE { 3054 wb OBJECT IDENTIFIER, 3055 value OCTET STRING } 3057 -- SCVP Validation Policies Request 3059 id-ct-scvp-valPolRequest OBJECT IDENTIFIER ::= { id-ct 12 } 3060 VPRequest ::= SEQUENCE { 3061 scvpVersion INTEGER, 3062 requestNonce OCTET STRING} 3064 -- SCVP Validation Policies Response 3066 id-ct-scvp-valPolResponse OBJECT IDENTIFIER ::= { id-ct 13 } 3068 VPResponse ::= SEQUENCE { 3069 vpResponseVersion INTEGER, 3070 maxCVResponseVersion INTEGER, 3071 maxVPResponseVersion INTEGER, 3072 defaultPolicyID INTEGER, 3073 thisUpdate GeneralizedTime, 3074 nextUpdate GeneralizedTime OPTIONAL, 3075 validationPolices SEQUENCE OF ValidationPolRef, 3076 validationAlgs SEQUENCE OF OBJECT IDENTIFIER, 3077 authPolicies SEQUENCE OF AuthPolicy, 3078 responseTypes ResponseTypes, 3079 defaultValidationPolicy ValidationPolValues, 3080 dhPublicKeyInfo SEQUENCE OF DHPublicKeyInfo, 3081 clockSkew [0] INTEGER OPTIONAL, 3082 requestNonce [1] OCTET STRING OPTIONAL } 3084 ResponseTypes ::= ENUMERATED { 3085 cached-only (0), 3086 specific-signed only (1), 3087 cached-and-specific-signed (2)} 3089 DHPublicKeyInfo ::= SEQUENCE { 3090 dhPublicKey DHPublicKey, 3091 domainParameters DomainParameters} 3093 -- SCVP Check Identifiers 3095 id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3096 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3097 17 } 3099 id-stc-build-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 } 3100 id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 2 } 3101 id-stc-build-status-checked-pkc-path 3102 OBJECT IDENTIFIER ::= { id-stc 3 } 3103 id-stc-build-aa-path OBJECT IDENTIFIER ::= { id-stc 4 } 3104 id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 5 } 3106 -- SCVP WantBack Identifiers 3108 id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3109 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3110 18 } 3111 id-swb-pkc-best-cert-path OBJECT IDENTIFIER ::= { id-swb 1 } 3112 id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 } 3113 id-swb-pkc-cert-status OBJECT IDENTIFIER ::= { id-swb 3 } 3114 id-swb-pkc-public-key-info OBJECT IDENTIFIER ::= { id-swb 4 } 3115 id-swb-aa-cert-path OBJECT IDENTIFIER ::= { id-swb 5 } 3116 id-swb-aa-revocation-info OBJECT IDENTIFIER ::= { id-swb 6 } 3117 id-swb-ac-revocation-info OBJECT IDENTIFIER ::= { id-swb 7 } 3118 id-swb-ac-cert-status OBJECT IDENTIFIER ::= { id-swb 8 } 3119 id-swb-non-cached-resp OBJECT IDENTIFIER ::= { id-swb 9 } 3120 id-swb-pkc-cert OBJECT IDENTIFIER ::= { id-swb 10} 3121 id-swb-ac-cert OBJECT IDENTIFIER ::= { id-swb 11} 3122 id-swb-pkc-all-valid-cert-paths OBJECT IDENTIFIER ::= { id-swb 13} 3124 -- SCVP Validation Algorithm Identifiers 3126 id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3127 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3128 19 } 3130 id-svp-defaultValAlg OBJECT IDENTIFIER ::= { id-svp 1 } 3132 -- SCVP Basic Validation Algorithm Identifier 3134 id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 } 3136 -- SCVP Basic Validation Algorithm Errors 3138 id-bvae OBJECT IDENTIFIER ::= { id-svp-basicValAlg 1 } 3140 id-bvae-expired OBJECT IDENTIFIER ::= { id-bvae 1 } 3141 id-bvae-not-yet-valid OBJECT IDENTIFIER ::= { id-bvae 2 } 3142 id-bvae-wrong-anchor OBJECT IDENTIFIER ::= { id-bvae 3 } 3143 id-bvae-partial-chain OBJECT IDENTIFIER ::= { id-bvae 4 } 3144 id-bvae-invalid-key-usage OBJECT IDENTIFIER ::= { id-bvae 10 } 3145 id-bvae-invalid-Purpose OBJECT IDENTIFIER ::= { id-bvae 11 } 3146 id-bvae-invalid-policy OBJECT IDENTIFIER ::= { id-bvae 12 } 3147 id-bvae-invalid-name OBJECT IDENTIFIER ::= { id-bvae 13 } 3148 id-bvae-invalid-entity OBJECT IDENTIFIER ::= { id-bvae 14 } 3149 id-bvae-invalid-depth OBJECT IDENTIFIER ::= { id-bvae 15 } 3151 -- SCVP Name Validation Algorithm Identifier 3153 id-svp-NameValAlg OBJECT IDENTIFIER ::= { id-svp 2 } 3155 -- SCVP Name Validation Algorithm Errors 3157 id-nvae OBJECT IDENTIFIER ::= { id-svp-NameValPol 1 } 3159 id-nvae-name-mismatch OBJECT IDENTIFIER ::= { id-nvae 1 } 3160 id-nvae-no-name OBJECT IDENTIFIER ::= { id-nvae 2 } 3161 id-nvae-unknown-pupose OBJECT IDENTIFIER ::= { id-nvae 3 } 3162 id-nvae-bad-name OBJECT IDENTIFIER ::= { id-nvae 4 } 3163 id-nvae-bad-name-type OBJECT IDENTIFIER ::= { id-nvae 5 } 3164 id-nvae-mixed-names OBJECT IDENTIFIER ::= { id-nvae 6 } 3166 END 3168 9 Security Considerations 3170 The following are in addition to the [CMS] security considerations 3172 A client that trusts a server's response for validation of a 3173 certificate inherently trusts that server as much as it would trust 3174 its own validation software. This means that if an attacker 3175 compromises a trusted SCVP server, the attacker can change the 3176 validation processing for every client that relies on that server. 3177 Thus, an SCVP server must be protected at least as well as the 3178 trust anchors that the SCVP server trusts. 3180 Clients MUST check the requestRef item in the response and ensure 3181 that it matches their original request. Requests contain a lot of 3182 information that affects the response and clients need to ensure 3183 that the server response corresponds to the expected request. 3185 When the SCVP response is used to determine the validity of a 3186 certificate, the client MUST validate the signature on the response 3187 to ensure that the expected SCVP server generated it. If the 3188 client does not check the signature on the response, a man-in-the- 3189 middle attack could fool the client into believing modified 3190 responses from the server, or responses to questions the client did 3191 not ask. 3193 If the client does not include a requestNonce item, or if the 3194 client does not check that the requestNonce in the response matches 3195 the value in the request, an attacker can replay previous responses 3196 from the SCVP server. 3198 If the server does not require some sort of authorization (such as 3199 signed requests), an attacker can get the server to respond to 3200 arbitrary requests. Such responses may give the attacker 3201 information about weaknesses in the server or about the timeliness 3202 of the server's checking. This information may be valuable for a 3203 future attack. 3205 If the server uses the serverContextInformation to indicate some 3206 server state associated with a requestor, implementers must take 3207 appropriate measures against denial of service attacks where an 3208 attacker sends in a lot of requests at one time to force the server 3209 to keep a lot of state information. 3211 SCVP does not include any confidentiality mechanisms. If 3212 confidentiality is needed, it can be achieved with a lower-layer 3213 security protocol. 3215 The only validation policy references which are truly persistent 3216 are OIDs. If the ownership of the policy could in any way be an 3217 issue, then OIDs should be the type reference of choice. However in 3218 many situations, even though URIs are technically non-persistent, 3219 the use of an URI is much more readily understood because of its 3220 widespread use elsewhere, and with many organizations they may be 3221 viewed as persistent for practical purposes. Therefore in these 3222 situations use of URI many be more attractive. 3224 Certificate validation is expensive and there are performance 3225 benefits in caching and reusing the result of a validation - 3226 - 3227 especially for high volume server processes. Caching end entity 3228 certificate would typically result in low hit rates against the 3229 cashe so is therefore inefficient. Caching CA certificates should 3230 yield much higher hit rates, but this needs to be done carefully 3231 because it could lead to the wrong result. One way this to achieve 3232 caching at the CA certificate level is to build a client which has 3233 enough of the chain validation logic to validate an end entity 3234 certificate to a CA certificate. The client can then use SCVP to 3235 validate the CA certificate, cache the result and locally validate 3236 end entity certificates against the cache of known good CA 3237 certificates. Attempting this kind of optimization with 3238 intermediate CA certificates could cause problems in some edge 3239 cases - 3240 - especially with chains involving self-issued certificates 3241 so caches should only be attempted with end entity issuing CA 3242 certificate. 3244 If an SCVP client is not operating on a network with good physical 3245 protection, it must ensure that there is integrity over the SCVP 3246 request\response pair and ensure that the response cannot be a 3247 replay of a cached response obtained by another client. It can do 3248 this by using a protected transport such as TLS. It can also do 3249 this by using the Diffie-hellman keys to sign the request. It can 3250 also use signing keys and request a fresh response from the server. 3252 10 References 3254 Normative and informative references are provided. 3256 10.1 Normative References 3258 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 3259 Requirement Levels", BCP 14, RFC 2119, March 1997. 3260 http://www.ietf.org/rfc/rfc2119.txt 3262 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 3263 2630,June 1999. 3264 http://www.ietf.org/rfc/rfc2630.txt 3266 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S. and 3267 C. Adams, "X.509 Internet Public Key Infrastructure - 3268 Online Certificate Status Protocol - OCSP", RFC 2560, 3269 June 1999. 3270 http://www.ietf.org/rfc/rfc2560.txt 3272 [PKIX-1] Housley, R., Polk, T, Ford, W. and Solo, D., 3273 "Internet X.509 Public Key Infrastructure Certificate 3274 and Certificate Revocation List (CRL) Profile", RFC 3275 3280, April 2002. 3276 http://www.ietf.org/rfc/rfc3280.txt 3278 [PKIX-AC] Farrell, S., and R. Housley, "An Internet Attribute 3279 Certificate Profile for Authorization", RFC 3281, 3280 April 2002. 3281 http://www.ietf.org/rfc/rfc3281.txt 3283 [PKIX-ALG] Polk, W., Housley, R. and L. Bassham, "Algorithms 3284 and Identifiers for the Internet X.509 Public Key 3285 Infrastructure Certificate and Certificate Revocation 3286 List (CRL) Profile", RFC 3279, April 2002. 3287 http://www.ietf.org/rfc/rfc3280.txt 3289 [SHA-1] National Institute of Standards and Technology, 3290 "Secure Hash Standard", NIST FIPS Pub 180-1, April 3291 1995. 3293 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 3294 10646", RFC 2279, January 1998. 3295 http://www.ietf.org/rfc/rfc2279.txt 3297 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", 3298 RFC 2634, June 1999. 3299 http://www.ietf.org/rfc/rfc2634.txt 3301 [HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC2818, May 2000. 3302 http://www.ietf.org/rfc/rfc2818.txt 3304 [SMIME-CERT] B. Ramsdell, Ed. Secure/Multipurpose Internet Mail 3305 Extensions (S/MIME) Version 3.1 Certificate 3306 Handling RFC3850, July 2004. 3307 http://www.ietf.org/rfc/rfc3850.txt 3309 [IKE] D. Harkins, D. Carrel. The Internet Key Exchange 3310 RFC2409, November 1998 3311 http://www.ietf.org/rfc/rfc2409.txt 3313 [IKE-GROUPS] T. Kivinen, M. Kojo More Modular Exponential (MODP) 3314 Diffie-Hellman groups for Internet Key Exchange (IKE) 3315 RFC3526, May 2003 3316 http://www.ietf.org/rfc/rfc3526.txt 3318 10.2 Informative References 3320 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and 3321 T. Berners-Lee, "Hypertext Transfer Protocol -- 3322 HTTP/1.1", RFC 2068, January 1997. 3324 [RQMTS] Pinkas, D., and R. Housley, "Delegated Path 3325 Validation and Delegated Path Discovery Protocol 3326 Requirements", RFC 3379, September 2002. 3328 11 Acknowledgments 3330 The lively debate in the PKIX Working Group has made a significant 3331 impact on this protocol. Special thanks to the following for their 3332 contributions to this standard and diligence in greatly improving 3333 this document. 3335 Denis Pinkas 3336 Phillip Hallam-Baker 3337 Mike Myers 3338 Frank Balluffi 3339 Ameya Talwalkar 3340 John Thielens 3341 Peter Sylvester 3342 Yuriy Dzambasow 3343 Sean P. Turner 3344 Wen-Cheng Wang 3345 Francis Dupont 3346 Dave Engberg 3347 Faisal Maqsood 3348 David A. Cooper 3350 Thanks also to the workgroup chairs Tim Polk and Steve Kent in 3351 their support and help. 3353 Appendix A -- MIME Registrations 3355 Four MIME type registrations are provided in this appendix. 3357 A.1 application/cv-request 3359 To: ietf-types@iana.org 3360 Subject: Registration of MIME media type application/cv-request 3362 MIME media type name: application 3363 MIME subtype name: cv-request 3365 Required parameters: format 3367 Optional parameters: None 3369 Encoding considerations: binary 3371 Security considerations: Carries a request for information. This 3372 request may optionally be cryptographically signed. 3374 Interoperability considerations: None 3376 Published specification: IETF PKIX Working Group Draft on Simple 3377 Certificate Validation Protocol (SCVP) 3379 Applications which use this media type: SCVP clients 3381 Additional information: 3382 Magic number(s): None 3383 File extension(s): .SCQ 3384 Macintosh File Type Code(s): none 3386 Person & email address to contact for further information: 3387 Ambarish Malpani 3389 Intended usage: COMMON 3391 Author/Change controller: 3392 Ambarish Malpani 3394 A.2 application/cv-response 3396 To: ietf-types@iana.org 3397 Subject: Registration of MIME media type application/cv-response 3399 MIME media type name: application 3401 MIME subtype name: cv-response 3403 Required parameters: format 3405 Optional parameters: None 3407 Encoding considerations: binary 3409 Security considerations: Unless reporting an error, the response is 3410 cryptographically signed 3412 Interoperability considerations: None 3413 Published specification: IETF PKIX Working Group Draft on Simple 3414 Certificate Validation Protocol (SCVP) 3416 Applications which use this media type: SCVP servers 3418 Additional information: 3420 Magic number(s): None 3421 File extension(s): .SCS 3422 Macintosh File Type Code(s): none 3424 Person & email address to contact for further information: 3425 Ambarish Malpani 3427 Intended usage: COMMON 3429 Author/Change controller: Ambarish Malpani 3431 A.3 application/vp-request 3433 To: ietf-types@iana.org 3434 Subject: Registration of MIME media type application/vp-request 3436 MIME media type name: application 3438 MIME subtype name: vp-request 3440 Required parameters: format 3442 Optional parameters: None 3444 Encoding considerations: binary 3446 Security considerations: Carries a request for information. 3448 Interoperability considerations: None 3450 Published specification: IETF PKIX Working Group Draft on Simple 3451 Certificate Validation Protocol (SCVP) 3453 Applications which use this media type: SCVP clients 3455 Additional information: 3457 Magic number(s): None 3458 File extension(s): .SPQ 3459 Macintosh File Type Code(s): none 3461 Person & email address to contact for further information: 3462 Ambarish Malpani 3463 Intended usage: COMMON 3465 Author/Change controller: Ambarish Malpani 3467 A.4 application/vp-response 3469 To: ietf-types@iana.org 3470 Subject: Registration of MIME media type application/vp-response 3472 MIME media type name: application 3474 MIME subtype name: vp-response 3476 Required parameters: format 3478 Optional parameters: None 3480 Encoding considerations: Binary 3482 Security considerations: None 3484 Interoperability considerations: None 3486 Published specification: IETF PKIX Working Group Draft on Simple 3487 Certificate Validation Protocol (SCVP) 3489 Applications which use this media type: SCVP servers 3491 Additional information: 3492 Magic number(s): None 3493 File extension(s): .SPP 3494 Macintosh File Type Code(s): none 3496 Person & email address to contact for further information: 3497 Ambarish Malpani 3499 Intended usage: COMMON 3501 Author/Change controller: 3502 Ambarish Malpani 3504 Appendix B -- SCVP over HTTP 3506 This appendix describes the formatting conventions for the SCVP 3507 request and response when carried by HTTP. 3509 B.1 SCVP Request 3511 HTTP based SCVP requests can use the POST method to submit their 3512 requests. Where privacy is a requirement, SCVP transactions 3513 exchanged using HTTP MAY be protected using either TLS/SSL or some 3514 other lower layer protocol. 3516 An SCVP request using the POST method is constructed as follows: 3518 The Content-Type header MUST have the value "application/cv- 3519 request". 3521 The Content-Length header MUST be present and have the exact 3522 length of the request. 3524 The body of the message is the binary value of the DER encoding 3525 of the VPRequest. Other HTTP headers MAY be present and MAY be 3526 ignored if not understood by the requestor. 3528 Sample Content-Type headers are: 3529 Content-Type: application/cv-policy-request 3531 B.2 SCVP Response 3533 An HTTP-based SCVP response is composed of the appropriate HTTP 3534 headers, followed by the binary value of the DER encoding of the 3535 CVResponse. 3537 The Content-Type header MUST have the value "application/cv- 3538 response". 3540 The Content-Length header MUST be present and specify the length of 3541 the response. 3543 Other HTTP headers MAY be present and MAY be ignored if not 3544 understood by the requestor. 3546 B.3 SCVP Policy Request 3548 HTTP based SCVP policy requests can use the POST method to submit 3549 their requests. Where privacy is a requirement, SCVP transactions 3550 exchanged using HTTP MAY be protected using either TLS/SSL or some 3551 other lower layer protocol. 3553 An SCVP request using the POST method is constructed as follows: 3555 The Content-Type header MUST have the value "application/vp- 3556 request". 3558 The Content-Length header MUST be present and have the exact 3559 length of the request. 3561 The body of the message is the binary value of the DER encoding 3562 of the VPRequest. Other HTTP headers MAY be present and MAY be 3563 ignored if not understood by the requestor. 3565 Sample Content-Type headers are: 3566 Content-Type: application/vp-request 3568 B.4 SCVP Policy Response 3570 An HTTP-based SCVP policy response is composed of the appropriate 3571 HTTP headers, followed by the binary value of the DER encoding of 3572 the VPResponse. 3574 The Content-Type header MUST have the value "application/vp- 3575 response". 3577 The Content-Length header MUST be present and specify the length of 3578 the response. 3580 Other HTTP headers MAY be present and MAY be ignored if not 3581 understood by the requestor. 3583 Appendix C -- Author Contact Information 3585 Trevor Freeman 3586 Microsoft Corporation, 3587 One Microsoft way. 3588 Redmond, WA 98052 3589 USA. 3590 trevorf@microsoft.com 3592 Russell Housley 3593 Vigil Security, LLC 3594 918 Spring Knoll Drive 3595 Herndon, VA 20170 3596 USA 3597 housley@Vigilsec.com 3599 Ambarish Malpani 3600 Malpani Consulting Services 3601 ambarish@malpani.biz 3602 Full Copyright Statement 3604 "Copyright (C) The Internet Society (2004). This document is 3605 subject to the rights, licenses and restrictions contained in BCP 3606 78, and except as set forth therein, the authors retain all their 3607 rights." 3609 "This document and the information contained herein are provided on 3610 An "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 3611 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 3612 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 3613 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 3614 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 3615 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 3616 PARTICULAR PURPOSE." 3618 This document and translations of it may be copied and furnished to 3619 others, and derivative works that comment on or otherwise explain 3620 it or assist in its implementation may be prepared, copied, 3621 published and distributed, in whole or in part, without restriction 3622 of any kind, provided that the above copyright notice and this 3623 paragraph are included on all such copies and derivative works. 3624 In addition, the ASN.1 modules presented may be used in whole or in 3625 part without inclusion of the copyright notice. However, this 3626 document itself may not be modified in any way, such as by removing 3627 the copyright notice or references to the Internet Society or other 3628 Internet organizations, except as needed for the purpose of 3629 developing Internet standards in which case the procedures for 3630 copyrights defined in the Internet Standards process shall be 3631 followed, or as required to translate it into languages other than 3632 English.