idnits 2.17.1 draft-ietf-pkix-scvp-23.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3988. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3670. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3677. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3683. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 3328 -- Looks like a reference, but probably isn't: '1' on line 3330 -- Looks like a reference, but probably isn't: '2' on line 3331 -- Looks like a reference, but probably isn't: '3' on line 3265 -- Looks like a reference, but probably isn't: '4' on line 3266 -- Looks like a reference, but probably isn't: '5' on line 3267 -- Looks like a reference, but probably isn't: '6' on line 3268 -- Looks like a reference, but probably isn't: '7' on line 3269 -- Looks like a reference, but probably isn't: '8' on line 3270 == Missing Reference: 'RQTMS' is mentioned on line 2708, but not defined == Unused Reference: 'SHA' is defined on line 3621, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3369 (ref. 'CMS') (Obsoleted by RFC 3852) ** Obsolete normative reference: RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 3280 (ref. 'PKIX-1') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3281 (ref. 'PKIX-AC') (Obsoleted by RFC 5755) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' ** Obsolete normative reference: RFC 2279 (ref. 'UTF8') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2818 (ref. 'HTTP-TLS') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3850 (ref. 'SMIME-CERT') (Obsoleted by RFC 5750) ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft T. Freeman 3 draft-ietf-pkix-scvp-23.txt Microsoft Corp 4 March 2006 R. Housley 5 Expires in six months Vigil Security 6 A. Malpani 7 Malpani Consulting Services 8 D. Cooper 9 NIST 10 T. Polk 11 NIST 13 Standard Certificate Validation Protocol (SCVP) 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 SCVP allows a client to delegate certificate path construction and 45 certificate path validation to a server. The path construction or 46 validation (e.g. making sure that none of the certificates in the 47 path are revoked) is performed according to a validation policy, 48 which contains one or more trust anchors. It allows simplification 49 of client implementations and use of a set of predefined validation 50 policies. 52 Table of Contents 54 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 55 1.1 SCVP overview . . . . . . . . . . . . . . . . . . . . . 5 56 1.2 SCVP Requirements . . . . . . . . . . . . . . . . . . . 6 57 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . 6 58 1.4 Validation Policies . . . . . . . . . . . . . . . . . . 7 59 1.5 Validation Algorithm . . . . . . . . . . . . . . . . . . 8 60 1.6 Validation Requirements . . . . . . . . . . . . . . . . 8 61 2 Protocol Overview . . . . . . . . . . . . . . . . . . . . . 9 62 3 Validation Request . . . . . . . . . . . . . . . . . . . . . 9 63 3.1 cvRequestVersion . . . . . . . . . . . . . . . . . . . . 12 64 3.2 query . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 3.2.1 queriedCerts . . . . . . . . . . . . . . . . . . . . . 13 66 3.2.2 checks . . . . . . . . . . . . . . . . . . . . . . . . 14 67 3.2.3 wantBack . . . . . . . . . . . . . . . . . . . . . . . 16 68 3.2.4 validationPolicy . . . . . . . . . . . . . . . . . . . 19 69 3.2.4.1 validationPolRef . . . . . . . . . . . . . . . . . 20 70 3.2.4.1.1 Default Validation Policy . . . . . . . . . . 21 71 3.2.4.2 validationAlg . . . . . . . . . . . . . . . . . . 22 72 3.2.4.2.1 Basic Validation Algorithm . . . . . . . . . . 22 73 3.2.4.2.2 Basic Validation Algorithm Errors . . . . . . 23 74 3.2.4.2.3 Name Validation Algorithm . . . . . . . . . . 24 75 3.2.4.2.4 Name Validation Algorithm Errors . . . . . . . 25 76 3.2.4.3 userPolicySet . . . . . . . . . . . . . . . . . . 25 77 3.2.4.4 inhibitPolicyMapping . . . . . . . . . . . . . . . 26 78 3.2.4.5 requireExplicitPolicy . . . . . . . . . . . . . . 26 79 3.2.4.6 inhibitAnyPolicy . . . . . . . . . . . . . . . . . 26 80 3.2.4.7 trustAnchors . . . . . . . . . . . . . . . . . . . 26 81 3.2.4.8 keyUsages . . . . . . . . . . . . . . . . . . . . 27 82 3.2.4.9 extendedKeyUsages . . . . . . . . . . . . . . . . 28 83 3.2.5 responseFlags . . . . . . . . . . . . . . . . . . . . 28 84 3.2.5.1 fullRequestInResponse . . . . . . . . . . . . . . 29 85 3.2.5.2 responseValidationPolByRef . . . . . . . . . . . . 29 86 3.2.5.3 protectResponse . . . . . . . . . . . . . . . . . 29 87 3.2.5.4 cachedResponse . . . . . . . . . . . . . . . . . . 30 88 3.2.6 serverContextInfo . . . . . . . . . . . . . . . . . . 30 89 3.2.7 validationTime . . . . . . . . . . . . . . . . . . . . 31 90 3.2.8 intermediateCerts . . . . . . . . . . . . . . . . . . 32 91 3.2.9 revInfos . . . . . . . . . . . . . . . . . . . . . . . 32 92 3.2.10 producedAt . . . . . . . . . . . . . . . . . . . . . 33 93 3.2.11 queryExtensions . . . . . . . . . . . . . . . . . . . 33 94 3.2.11.1 extnID . . . . . . . . . . . . . . . . . . . . . 34 95 3.2.11.2 critical . . . . . . . . . . . . . . . . . . . . 34 96 3.2.11.3 extnValue . . . . . . . . . . . . . . . . . . . . 34 97 3.3 requestorRef . . . . . . . . . . . . . . . . . . . . . . 34 98 3.4 requestNonce . . . . . . . . . . . . . . . . . . . . . . 35 99 3.5 requestorName . . . . . . . . . . . . . . . . . . . . . 35 100 3.6 responderName . . . . . . . . . . . . . . . . . . . . . 35 101 3.7 requestExtensions . . . . . . . . . . . . . . . . . . . 36 102 3.7.1 extnID . . . . . . . . . . . . . . . . . . . . . . . . 36 103 3.7.2 critical . . . . . . . . . . . . . . . . . . . . . . . 36 104 3.7.3 extnValue . . . . . . . . . . . . . . . . . . . . . . 36 105 3.8 signatureAlg . . . . . . . . . . . . . . . . . . . . . . 37 106 3.9 hashAlg . . . . . . . . . . . . . . . . . . . . . . . . 37 107 3.10 RequestorText . . . . . . . . . . . . . . . . . . . . . 38 108 3.11 SCVP Request Authentication . . . . . . . . . . . . . . 38 109 4 Validation Response . . . . . . . . . . . . . . . . . . . . 39 110 4.1 cvResponseVersion . . . . . . . . . . . . . . . . . . . 41 111 4.2 serverConfigurationID . . . . . . . . . . . . . . . . . 41 112 4.3 producedAt . . . . . . . . . . . . . . . . . . . . . . . 42 113 4.4 responseStatus . . . . . . . . . . . . . . . . . . . . . 42 114 4.5 respValidationPolicy . . . . . . . . . . . . . . . . . . 44 115 4.6 requestRef . . . . . . . . . . . . . . . . . . . . . . . 45 116 4.6.1 requestHash . . . . . . . . . . . . . . . . . . . . . 45 117 4.6.2 fullRequest . . . . . . . . . . . . . . . . . . . . . 46 118 4.7 requestorRef . . . . . . . . . . . . . . . . . . . . . . 46 119 4.8 requestorName . . . . . . . . . . . . . . . . . . . . . 46 120 4.9 replyObjects . . . . . . . . . . . . . . . . . . . . . . 47 121 4.9.1 cert . . . . . . . . . . . . . . . . . . . . . . . . . 47 122 4.9.2 replyStatus . . . . . . . . . . . . . . . . . . . . . 48 123 4.9.3 replyValTime . . . . . . . . . . . . . . . . . . . . . 49 124 4.9.4 replyChecks . . . . . . . . . . . . . . . . . . . . . 49 125 4.9.5 replyWantBacks . . . . . . . . . . . . . . . . . . . . 51 126 4.9.6 validationErrors . . . . . . . . . . . . . . . . . . . 54 127 4.9.7 nextUpdate . . . . . . . . . . . . . . . . . . . . . . 54 128 4.9.8 certReplyExtensions . . . . . . . . . . . . . . . . . 54 129 4.10 respNonce . . . . . . . . . . . . . . . . . . . . . . . 54 130 4.11 serverContextInfo . . . . . . . . . . . . . . . . . . . 55 131 4.12 cvResponseExtensions . . . . . . . . . . . . . . . . . . 55 132 4.13 RequestorText . . . . . . . . . . . . . . . . . . . . . 56 133 4.14 SCVP Response Validation . . . . . . . . . . . . . . . . 56 134 4.14.1 Simple Key Validation . . . . . . . . . . . . . . . . 56 135 4.14.2 SCVP Server Certificate Validation . . . . . . . . . 57 136 5 Server Policy Request . . . . . . . . . . . . . . . . . . . 57 137 5.1 vpRequestVersion . . . . . . . . . . . . . . . . . . . . 58 138 5.2 requestNonce . . . . . . . . . . . . . . . . . . . . . . 58 139 6 Validation Policy Response . . . . . . . . . . . . . . . . . 58 140 6.1 vpResponseVersion . . . . . . . . . . . . . . . . . . . 59 141 6.2 maxCVRequestVersion . . . . . . . . . . . . . . . . . . 60 142 6.3 maxVPRequestVersion . . . . . . . . . . . . . . . . . . 60 143 6.4 serverConfigurationID . . . . . . . . . . . . . . . . . 60 144 6.5 thisUpdate . . . . . . . . . . . . . . . . . . . . . . . 60 145 6.6 nextUpdate and requestNonce . . . . . . . . . . . . . . 60 146 6.7 validationPolicies . . . . . . . . . . . . . . . . . . . 61 147 6.8 validationAlgs . . . . . . . . . . . . . . . . . . . . . 61 148 6.9 authPolicies . . . . . . . . . . . . . . . . . . . . . . 61 149 6.10 responseTypes . . . . . . . . . . . . . . . . . . . . . 61 150 6.11 revocationInfoTypes . . . . . . . . . . . . . . . . . . 62 151 6.12 defaultPolicyValues . . . . . . . . . . . . . . . . . . 62 152 6.13 signatureGeneration . . . . . . . . . . . . . . . . . . 62 153 6.14 signatureVerification . . . . . . . . . . . . . . . . . 62 154 6.15 hashAlgorithms . . . . . . . . . . . . . . . . . . . . . 63 155 6.16 serverPublicKeys . . . . . . . . . . . . . . . . . . . . 63 156 6.17 clockSkew . . . . . . . . . . . . . . . . . . . . . . . 63 157 7 SCVP Server Relay . . . . . . . . . . . . . . . . . . . . . 64 158 8 SCVP ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 65 159 9 Security Considerations . . . . . . . . . . . . . . . . . . 73 160 10 References . . . . . . . . . . . . . . . . . . . . . . . . . 75 161 10.1 Normative References . . . . . . . . . . . . . . . . . . 75 162 10.2 Informative References . . . . . . . . . . . . . . . . . 76 163 11 Intellectual Property Rights . . . . . . . . . . . . . . . . 76 164 12 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 77 165 Appendix A -- MIME Registrations . . . . . . . . . . . . . . . 77 166 A.1 application/cv-request . . . . . . . . . . . . . . . . . 77 167 A.2 application/cv-response . . . . . . . . . . . . . . . . . 78 168 A.3 application/vp-request . . . . . . . . . . . . . . . . . 79 169 A.4 application/vp-response . . . . . . . . . . . . . . . . . 80 170 Appendix B -- SCVP over HTTP . . . . . . . . . . . . . . . . . 80 171 B.1 SCVP Request . . . . . . . . . . . . . . . . . . . . . . 81 172 B.2 SCVP Response . . . . . . . . . . . . . . . . . . . . . . 81 173 B.3 SCVP Policy Request . . . . . . . . . . . . . . . . . . . 81 174 B.4 SCVP Policy Response . . . . . . . . . . . . . . . . . . 82 175 Appendix C -- Authors' Addresses . . . . . . . . . . . . . . . 82 176 1 Introduction 178 Certificate validation is complex. If certificate handling is to be 179 widely deployed in a variety of applications and environments, the 180 amount of processing an application needs to perform before it can 181 accept a certificate needs to be reduced. There are a variety of 182 applications that can make use of public key certificates, but these 183 applications are burdened with the overhead of constructing and 184 validating the certification paths. SCVP reduces this overhead for 185 two classes of certificate-using applications. 187 The first class of applications wants just two things: confirmation 188 that the public key belongs to the identity named in the certificate 189 and confirmation that the public key can be used for the intended 190 purpose. Such clients can completely delegate certification path 191 construction and validation to the SCVP server. This is often 192 referred to as delegated path validation (DPV). 194 The second class of applications can perform certification path 195 validation, but they lack a reliable or efficient method of 196 constructing a valid certification path. Such clients delegate 197 certification path construction to the SCVP server, but not 198 validation of the returned certification path. This is often 199 referred to as delegated path discovery (DPD). 201 1.1 SCVP overview 203 The primary goals of SCVP are to make it easier to deploy PKI- 204 enabled applications by delegating path discovery and/or validation 205 processing to a server, and to allow central administration of 206 validation policies within an organization. SCVP can be used by 207 clients that do much of the certificate processing themselves but 208 simply want an untrusted server to collect information for them. 209 However, when the client has complete trust in the SCVP server, SCVP 210 can be used to delegate the work of certification path construction 211 and validation, and SCVP can be used to ensure that policies are 212 consistently enforced throughout an organization. 214 Untrusted SCVP servers can provide clients the certification paths. 215 They can also provide clients the revocation information, such as 216 CRLs and OCSP responses, that the clients need to validate the 217 certification paths constructed by the SCVP server. These services 218 can be valuable to clients that do not include the protocols needed 219 to find and download intermediate certificates, CRLs, and OCSP 220 responses. 222 Trusted SCVP servers can perform certification path construction and 223 validation for the client. For a client that uses these services, 224 the client inherently trusts the SCVP server as much as it would its 225 own certification path validation software (if it contained such 226 software). There are two main reasons that a client may want to 227 trust such an SCVP server: 229 1. The client does not want to incur the overhead of including 230 certification path validation software and running it for each 231 certificate it receives. 233 2. The client is in an organization or community that wants to 234 centralize management of validation policies. These policies 235 might dictate that particular trust anchors are to be used and 236 the types of policy checking that are to be performed during 237 certification path validation. 239 1.2 SCVP Requirements 241 SCVP meets the mandatory requirements documented in [RQMTS] for DPV 242 and DPD. When SCVP is used to support DPD, the same response is 243 returned when a path is constructed, but some or all of the 244 revocation information is unavailable. 246 Note that RFC 3379 states the following requirement: 247 "The DPD response MUST indicate one of the following status 248 alternatives: 249 1) one or more certification paths was found according to the 250 path discovery policy, with all of the requested revocation 251 information present. 252 2) one or more certification paths was found according to the 253 path discovery policy, with a subset of the requested 254 revocation information present. 255 3) one or more certification paths was found according to the 256 path discovery policy, with none of the requested revocation 257 information present. 258 4) no certification path was found according to the path 259 discovery policy. 260 5) path construction could not be performed due to an error." 262 DPD responses constructed by SCVP servers do not differentiate 263 between states 2) and 3). This property was discussed on list and 264 determined to be conformant with the intent of [RQMTS]. 266 1.3 Terminology 268 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 269 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 270 document are to be interpreted as described in [STDWORDS]. 272 1.4 Validation Policies 274 A validation policy (as defined in RFC 3379 [RQMTS]) specifies the 275 rules and parameters to be used by the SCVP server when validating a 276 certificate. In SCVP, the validation policy to be used by the 277 server can either be fully referenced in the request by the client 278 (and thus no additional parameters are necessary) or it can be 279 referenced in the request by the client with additional parameters. 281 Policy definitions can be quite long and complex, and some policies 282 may allow for the setting of a few parameters. The request can 283 therefore be very simple if an OBJECT IDENTIFIER (OID) is used to 284 specify both the algorithm to be used and all the associated 285 parameters of the validation policy. The request can be more 286 complex if the validation policy fixes many of the parameters but 287 allows the client to specify some of them. When the validation 288 policy defines every parameter necessary, an SCVP request needs only 289 to contain the certificate to be validated, the referenced 290 validation policy, and any run-time parameters for the request. 292 A server publishes the references of the validation policies it 293 supports. When these policies have parameters that may be 294 overridden, the server communicates the default values for these 295 parameters as well. The client can simplify the request by omitting 296 a parameter from a request if the default value published by the 297 server for a given validation policy reference is acceptable. 298 However, if there is a desire to demonstrate to someone else that a 299 specific validation policy with all its parameters has been used, 300 the client will need to ask the server for the inclusion of the full 301 validation policy with all the parameters in the response. 303 The inputs to the basic certification path processing algorithm used 304 by SCVP are defined by [PKIX-1] in section 6.1.1 and comprise: 306 Certificate to be validated (by value or by reference); 308 Validation time; 310 The initial policy set; 312 Initial inhibit policy mapping setting; 314 Initial inhibit anyPolicy setting; and 316 Initial require explicit policy setting. 318 The basic certification path processing algorithm also supports 319 specification of one or more Trust Anchors (by value or reference) 320 as an input. Where the client demands a certification originating 321 with a specific CA, a single Trust Anchor is specified. Where the 322 client is willing to accept paths beginning with any of several CAs, 323 a set of Trust anchors is specified. 325 The basic certification path processing algorithm also supports the 326 following parameters, which are defined in [PKIX-1] section 4: 328 The usage of the key contained in the certificate (e.g., key 329 encipherment, key agreement, signature); and 331 Other application-specific purposes for which the certified public 332 key may be used. 334 1.5 Validation Algorithm 336 The validation algorithm is determined by agreement between the 337 client and the server and is represented as an OID. The algorithm 338 defines the checking that will be performed by the server to 339 determine whether the certificate is valid. A validation algorithm 340 is one of the parameters to a validation policy. SCVP defines a 341 basic validation algorithm that implements the basic path validation 342 algorithm as defined in [PKIX-1], and permits the client to request 343 additional information about the certificate to be validated. New 344 validation algorithms can be specified that define additional checks 345 if needed. These new validation algorithms may specify additional 346 parameters. The values for these parameters may be defined by any 347 validation policy that uses the algorithm or may be included by the 348 client in the request. 350 Application-specific validation algorithms in addition to those 351 defined in this document can be defined to meet specific 352 requirements not covered by the basic validation algorithm. The 353 validation algorithms documented here should serve as a guide for 354 the development of further application-specific validation 355 algorithms. For example, a new application-specific validation 356 algorithm might require the presence of a particular name form in 357 the subject alternative name extension of the certificate. 359 1.6 Validation Requirements 361 For a certification path to be considered valid under a particular 362 validation policy it MUST be a valid certification path as defined 363 in [PKIX-1] and all validation policy constraints that apply to the 364 certification path MUST be verified. 366 Revocation checking is one aspect of certification path validation 367 defined in [PKIX-1]. However, revocation checking is an optional 368 feature in [PKIX-1], and revocation information is distributed in 369 multiple formats. Clients specify in requests whether revocation 370 checking should be performed and whether revocation information 371 should be returned in the response. 373 Servers MUST be capable of indicating the sources of revocation 374 information that they are capable of processing: 376 1. full CRLs (or full Authority Revocation Lists); 378 2. OCSP responses, using [OCSP]; 380 3. delta CRLs; and 382 4. indirect CRLs. 384 2 Protocol Overview 386 SCVP uses a simple request-response model. That is, the SCVP client 387 creates a request and sends it to the SCVP server, and then the SCVP 388 server creates a single response and sends it to the client. The 389 typical use of SCVP is expected to be over HTTP [HTTP], but it can 390 also be used with email or any other protocol that can transport 391 digitally signed objects. Appendices A and B provide the details 392 necessary to use SCVP with HTTP. 394 SCVP includes two request-response pairs. The primary request- 395 response pair handles certificate validation. The secondary 396 request-response pair is used to determine the list of validation 397 policies and default parameters supported by a specific SCVP server. 399 Section 3 defines the certificate validation request. 401 Section 4 defines the corresponding certificate validation response. 403 Section 5 defines the validation policies request. 405 Section 6 defines the corresponding validation policies response. 407 Appendix A registers MIME types for SCVP requests and responses, and 408 Appendix B describes the use of these MIME types with HTTP. 410 3 Validation Request 412 An SCVP client request to the server MUST be a single CVRequest 413 item. When a CVRequest is encapsulated in a MIME body part, 414 application/cv-request MUST be used. 416 There are two forms of SCVP request: unprotected and protected. A 417 protected request is used to authenticate the client to the server 418 or to provide anonymous client integrity over the request-response 419 pair. The protection is provided by a digital signature or message 420 authentication code (MAC). In the later case, the MAC key is 421 derived using a key agreement algorithm, such as Diffie-Hellman. If 422 the client's public key is contained in a certificate, then it may 423 be used to authenticate the client. More commonly, the client's key 424 agreement public key will be ephemeral, supporting anonymous client 425 integrity. 427 A server MAY require all requests to be protected, and a server MAY 428 discard all unprotected requests. Alternatively, a server MAY 429 choose to process unprotected requests. 431 The unprotected request consists of a CVRequest encapsulated in a 432 CMS ContentInfo [CMS]. An overview of this structure is provided 433 below and is only intended as illustrative. The definitive ASN.1 is 434 found in [CMS]. Many details are not shown, but the way that SCVP 435 makes use of CMS is clearly illustrated. 437 ContentInfo { 438 contentType id-ct-scvp-certValRequest, 439 -- (1.2.840.113549.1.9.16.1.10) 440 content CVRequest } 442 The protected request consists of a CVRequest encapsulated in either 443 a SignedData or AuthenticatedData, which is in turn encapsulated in 444 a ContentInfo. That is, the EncapsulatedContentInfo field of either 445 SignedData or AuthenticatedData consists of an eContentType field 446 with a value of id-ct-scvp-certValRequest and an eContent field that 447 contains a DER encoded CVRequest. SignedData is used when the 448 request is digitally signed. AuthenticatedData is used with a 449 message authentication code (MAC). 451 All SCVP clients MUST support SignedData for signed requests and 452 responses. SCVP clients SHOULD support AuthenticatedData for MAC 453 protected requests and responses. 455 If the client uses SignedData it MUST have a public key that has 456 been bound to a subject identity by a certificate that conforms to 457 the PKIX profile [PKIX-1] and that certificate MUST be suitable for 458 signing the SCVP request. That is: 460 1. If the key usage extension is present, either the digital 461 signature or the non-repudiation bit MUST be asserted. 463 2. If the extended key usage extension is present, it MUST 464 contain either the SCVP client OID (see Section 3.10) or 465 another OID acceptable to the SCVP server. 467 The client MUST put an unambiguous reference to its certificate in 468 the SignedData that encapsulates the request. The client SHOULD 469 include its certificate in the request, but MAY omit the certificate 470 to reduce the size of the request. The client MAY include other 471 certificates in the request to aid the validation of its 472 certificates by the SCVP server. The signerInfos field of 473 SignedData MUST include exactly one SignerInfo. The SignedData MUST 474 NOT include the unsignedAttrs field. 476 The client MUST put its key agreement public key or an unambiguous 477 reference to a certificate that contains its key agreement public 478 key in the AuthenticatedData that encapsulates the request. If an 479 ephemeral key agreement key pair is used, then the ephemeral key 480 agreement public key is carried in the originatorKey field of 481 KeyAgreeRecipientInfo, which requires the client to obtain the 482 server's key agreement public key before computing the message 483 authentication code (MAC). The recipientInfos field of 484 AuthenticatedData MUST include exactly one RecipientInfo, which 485 contains information for the SCVP server. The AuthenticatedData 486 MUST NOT include the unauthAttrs field. 488 The syntax and semantics for SignedData, AuthenticatedData, and 489 ContentInfo are defined in [CMS]. The syntax and semantics for 490 CVRequest are defined below. The CVRequest item contains the client 491 request. The CVRequest contains the cvRequestVersion and query 492 items; the CVRequest MAY also contain the requestorRef, 493 requestNonce, requestorName, responderName, requestExtensions, 494 signatureAlg, and hashAlg items. 496 The CVRequest MUST have the following syntax: 498 CVRequest ::= SEQUENCE { 499 cvRequestVersion INTEGER DEFAULT 1, 500 query Query, 501 requestorRef [0] GeneralNames OPTIONAL, 502 requestNonce [1] OCTET STRING OPTIONAL, 503 requestorName [2] GeneralName OPTIONAL, 504 responderName [3] GeneralName OPTIONAL, 505 requestExtensions [4] Extensions OPTIONAL, 506 signatureAlg [5] AlgorithmIdentifier OPTIONAL, 507 hashAlg [6] OBJECT IDENTIFIER OPTIONAL, 508 requestorText [7] UTF8String (SIZE (1..256)) OPTIONAL } 510 Conforming clients MUST be able to construct requests with 511 cvRequestVersion and query. Conforming clients MUST DER-encode the 512 CVRequest in both protected and unprotected messages to facilitate 513 unambiguous hash-based referencing in the corresponding response 514 message. SCVP clients that insist on creation of a fresh response 515 (e.g., to protect against a replay attack or ensure information is 516 up to date) MUST support requestNonce. Support for the remaining 517 items is optional in client implementations. 519 Conforming servers MUST be able to parse CVRequests that contain any 520 or all of the optional items. 522 Each of the items within the CVRequest is described in the following 523 sections. 525 3.1 cvRequestVersion 527 The cvRequestVersion item defines the version of the SCVP CVRequest 528 used in a request. The subsequent response MUST use the same 529 version number. The value of the cvRequestVersion item MUST be one 530 (1) for a client implementing this specification. Future updates to 531 this specification must specify other values if there are any 532 changes to syntax or semantics. 534 SCVP clients MUST support asserting this value and SCVP servers must 535 be capable of processing this value. 537 3.2 query 539 The query item specifies one or more certificates that are the 540 subject of the request; the certificates can be either public key 541 certificates [PKIX-1] or attribute certificates [PKIX-AC]. A query 542 MUST contain a queriedCerts item as well as one checks, and one 543 validationPolicy item; a query MAY also contain wantback, 544 responseFlags, serverContextInfo, validationTime, intermediateCerts, 545 revInfos, producedAt, and queryExtensions items. 547 Query MUST have the following syntax: 549 Query ::= SEQUENCE { 550 queriedCerts CertReferences, 551 checks CertChecks, 552 wantBack [1] WantBack OPTIONAL, 553 validationPolicy ValidationPolicy, 554 responseFlags ResponseFlags OPTIONAL, 555 serverContextInfo [2] OCTET STRING OPTIONAL, 556 validationTime [3] GeneralizedTime OPTIONAL, 557 intermediateCerts [4] CertBundle OPTIONAL, 558 revInfos [5] RevocationInfos OPTIONAL, 559 producedAt [6] GeneralizedTime OPTIONAL, 560 queryExtensions [7] Extensions OPTIONAL } 562 The list of certificate references in the queriedCerts item tells 563 the server the certificate(s) for which the client wants 564 information. The checks item specifies the checking that the client 565 wants performed. The wantBack item specifies the objects that the 566 client wants the server to return in the response. The 567 validationPolicy item specifies the validation policy that the 568 client wants the server to employ. The responseFlags item allows 569 the client to request optional features for the response. The 570 serverContextInfo item tells the server that additional information 571 from a previous request-response is desired. The validationTime 572 item tells the date and time relative to which the client wants the 573 server to perform the checks. The intermediateCerts and revInfos 574 items provide context for the client request. The queryExtensions 575 item provides for future expansion of the query syntax. The syntax 576 and semantics of each of these items is discussed in the following 577 sections. 579 Conforming clients MUST be able to construct a Query with a 580 queriedCerts item that specifies at least one certificate, checks, 581 and validationPolicy. Conforming SCVP clients MAY support 582 specification of multiple certificates and MAY support the optional 583 items in the Query structure. 585 SCVP clients that support delegated path discovery (DPD) as defined 586 in [RQMTS] MUST support wantBack and responseFlags. SCVP clients 587 that insist on creation of a fresh response (e.g., to protect 588 against a replay attack or ensure information is up to date) MUST 589 support responseFlags. 591 Conforming servers MUST be able to process a Query that contains any 592 of the optional items, and MUST be able to process a Query that 593 specifies multiple certificates. 595 3.2.1 queriedCerts 597 The queriedCerts item is a SEQUENCE of one or more certificates, 598 each of which is a subject of the request. The specified 599 certificates are either public key certificates or attribute 600 certificates; if more than one certificate is specified, all must be 601 of the same type. Each certificate is either directly included or 602 it is referenced. When referenced, a hash value of the referenced 603 item is included to ensure that the SCVP client and the SCVP server 604 both obtain the same certificate when the referenced certificate is 605 fetched. Certificate references use the CertID type, which is 606 described below. A single request MAY contain both directly 607 included and referenced certificates. 609 CertReferences has the following syntax: 611 CertReferences ::= CHOICE { 612 pkcRefs [0] SEQUENCE SIZE (1..MAX) OF PKCReference, 613 acRefs [1] SEQUENCE SIZE (1..MAX) OF ACReference } 615 PKCReference ::= CHOICE { 616 cert [0] Certificate, 617 pkcRef [1] CertID } 619 ACReference ::= CHOICE { 620 attrCert [2] AttributeCertificate, 621 acRef [3] CertID } 623 CertID ::= SEQUENCE { 624 certHash OCTET STRING, 625 issuerSerial IssuerSerial, 626 hashAlgorithm AlgorithmIdentifier DEFAULT { sha-1 } } 628 The ASN.1 definition of Certificate is imported from [PKIX-1] and 629 the definition of AttributeCertificate is imported from [PKIX-AC]. 631 When creating a CertID, the certHash is computed over the entire DER 632 encoded certificate including the signature. The hash algorithm 633 used to compute certHash is specified in hashAlgorithm. The hash 634 algorithm used to compute certHash SHOULD be one of the hash 635 algorithms specified in the hashAlgorithms item of the server's 636 validation policy response message. 638 When encoding IssuerSerial, serialNumber is the serial number that 639 uniquely identifies the certificate. For public key certificates, 640 the issuer MUST contain only the issuer name from the certificate 641 encoded in the directoryName choice of GeneralNames. For attribute 642 certificates, the issuer MUST contain the issuer name field from the 643 attribute certificate. 645 Conforming clients MUST be able to reference a certificate by direct 646 inclusion. Clients SHOULD be able to specify a certificate using 647 the CertID. Conforming clients MAY be able to reference multiple 648 certificates and MAY be able to reference both public key and 649 attribute certificates. 651 Conforming SCVP Server implementations MUST be able to process 652 CertReferences with multiple certificates. Conforming SCVP Server 653 implementations MUST be able to parse CertReferences that contain 654 either public key or attribute certificates. Conforming SCVP Server 655 implementations MUST be able to parse both the cert and pkcRef 656 choices in PKCReference. Conforming SCVP Server implementations 657 that process attribute certificates MUST be able to parse both the 658 attrCert and acRef choices in ACReference. 660 3.2.2 checks 661 The checks item describes the checking that the SCVP client wants 662 the SCVP server to perform on the certificate(s) in the queriedCerts 663 item. The checks item contains a sequence of object identifiers 664 (OIDs). Each OID tells the SCVP server what checking the client 665 expects the server to perform. For each check specified in the 666 request, the SCVP server MUST perform the requested check, or return 667 an error. A server may choose to perform additional checks (e.g., a 668 server that is only asked to build a validated certification path 669 may choose to also perform revocation status checks), although the 670 server cannot indicate in the response that the additional checks 671 have been performed. 673 The checks item uses the CertChecks type, which has the following 674 syntax: 676 CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 678 For public key certificates, the following checks are defined: 680 - id-stc-build-pkc-path: Build a prospective certification path to 681 a trust anchor (as defined in section 6.1 of [PKIX-1]); 683 - id-stc-build-valid-pkc-path: Build a validated certification path 684 to a trust anchor (revocation checking not required); 686 - id-stc-build-status-checked-pkc-path: Build a validated 687 certification path to a trust anchor and perform revocation 688 status checks on the certification path. 690 Conforming SCVP server implementations that support delegated path 691 discovery (DPD) as defined in [RQMTS] MUST support the id-stc-build- 692 pkc-path check. Conforming SCVP server implementations that support 693 delegated path validation (DPV) as defined in [RQMTS] MUST support 694 the id-stc-build-valid-pkc-path and id-stc-build-status-checked-pkc- 695 path checks. 697 For attribute certificates, the following checks are defined: 699 - id-stc-build-aa-path: Build a certification path to a trust 700 anchor for the AC issuer; 702 - id-stc-build-valid-aa-path: Build a validated certification path 703 to a trust anchor for the AC issuer; 705 - id-stc-build-status-checked-aa-path: Build a validated 706 certification path to a trust anchor for the AC issuer and 707 perform revocation status checks on the certification path for 708 the AC issuer; 710 - id-stc-status-check-ac-and-build-status-checked-aa-path: Build a 711 validated certification path to a trust anchor for the AC 712 issuer and perform revocation status checks on the AC as well 713 as the certification path for the AC issuer. 715 Conforming SCVP server implementations MAY support the attribute 716 certificates checks. 718 For these purposes, the following OIDs are defined: 720 id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 721 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 } 723 id-stc-build-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 } 724 id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 2 } 725 id-stc-build-status-checked-pkc-path 726 OBJECT IDENTIFIER ::= { id-stc 3 } 727 id-stc-build-aa-path OBJECT IDENTIFIER ::= { id-stc 4 } 728 id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 5 } 729 id-stc-build-status-checked-aa-path 730 OBJECT IDENTIFIER ::= { id-stc 6 } 731 id-stc-status-check-ac-and-build-status-checked-aa-path 732 OBJECT IDENTIFIER ::= { id-stc 7 } 734 Conforming client implementations MUST be able to assert at least 735 one of the standard checks. Conforming clients MAY be able to 736 assert multiple checks. Conforming clients need not support all of 737 the checks defined in this section. 739 3.2.3 wantBack 741 The optional wantBack item describes any information the SCVP client 742 wants from the SCVP server for the certificate(s) in the 743 queriedCerts item in addition to the results of the checks specified 744 in certChecks. If present, the wantBack item MUST contain a 745 sequence of object identifiers (OIDs). Each OID tells the SCVP 746 server what the client wants to know about the queriedCerts item. 747 For each type of information specified in the request, the server 748 MUST return information regarding its finding (in a successful 749 response). 751 For example, a request might include a checks item that only 752 specifies certification path building and include a wantBack item 753 that requests the return of the certification path built by the 754 server. In this case, the response would not include a status for 755 the validation of the certification path, but it would include a 756 certification path that the server considers to be valid. A client 757 that wants to perform its own certification path validation might 758 use a request of this form. 760 Alternatively, a request might include a checks item that requests 761 the server to build a certification path and validate it, including 762 revocation checking, and not include a wantBack item. In this case, 763 the response would include only a status for the validation of the 764 certification path. A client that completely delegates 765 certification path validation might use a request of this form. 767 The wantBack item uses the WantBack type, which has the following 768 syntax: 770 WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 772 For public key certificates, the types of information that can be 773 requested are: 775 - id-swb-pkc-cert: The certificate that was the subject of the 776 request; 778 - id-swb-pkc-best-cert-path: The certification path built for the 779 certificate including the certificate that was validated; 781 - id-swb-pkc-revocation-info: Proof of revocation status for each 782 certificate in the certification path; 784 - id-swb-pkc-public-key-info: The public key from the certificate; 786 - id-swb-pkc-all-cert-paths: A set of certification paths for the 787 certificate; 789 - id-swb-pkc-ee-revocation-info: Proof of revocation status for the 790 end entity certificate in the certification path; and 792 - id-swb-pkc-CAs-revocation-info: Proof of revocation status for 793 each CA certificate in the certification path. 795 All conforming SCVP server implementations MUST support the id-swb- 796 pkc-cert and id-swb-pkc-public-key-info wantBacks. Conforming SCVP 797 server implementations that support delegated path discovery (DPD) 798 as defined in [RQMTS] MUST support the id-swb-pkc-best-cert-path and 799 id-swb-pkc-revocation-info wantBacks. 801 The SCVP protocol provides two methods for a client to obtain 802 multiple certification paths for a certificate. The client could 803 use serverContextInfo to request one path at a time (see section 804 3.2.6). After obtaining each path, the client could submit the 805 serverContextInfo from the previous request to obtain another path 806 until the client either found a suitable path or the server 807 indicated (by not returning a serverContextInfo) that no more paths 808 were available. Alternatively, the client could send a single 809 request with an id-swb-pkc-all-cert-paths wantBack, in which case 810 the server would return all of the available paths in a single 811 response. 813 The server may, at its discretion, limit the number of paths that it 814 returns in response to the id-swb-pkc-all-cert-paths. When the 815 request includes an id-swb-pkc-all-cert-paths wantBack, the response 816 should not include a serverContextInfo. 818 For attribute certificates, the types of information that can be 819 requested are: 821 - id-swb-ac-cert: The attribute certificate that was the subject of 822 the request; 824 - id-swb-aa-cert-path: The certification path built for the AC 825 issuer certificate; 827 - id-swb-ac-revocation-info: Proof of revocation status for each 828 certificate in the AC issuer certification path; and 830 - id-swb-aa-revocation-info: Proof of revocation status for the 831 attribute certificate. 833 Conforming SCVP server implementations MAY support the attribute 834 certificate wantbacks. 836 The following wantBack can be used for either public key or 837 attribute certificates: 839 - id-swb-relayed-responses: Any SCVP responses received by the 840 server that were used to generate the response to this query. 842 Conforming SCVP servers MAY support the id-swb-relayed-responses 843 wantBack. 845 For these purposes, the following OIDs are defined: 847 id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 848 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 } 850 id-swb-pkc-best-cert-path OBJECT IDENTIFIER ::= { id-swb 1 } 851 id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 } 852 id-swb-pkc-public-key-info OBJECT IDENTIFIER ::= { id-swb 4 } 853 id-swb-aa-cert-path OBJECT IDENTIFIER ::= { id-swb 5 } 854 id-swb-aa-revocation-info OBJECT IDENTIFIER ::= { id-swb 6 } 855 id-swb-ac-revocation-info OBJECT IDENTIFIER ::= { id-swb 7 } 856 id-swb-relayed-responses OBJECT IDENTIFIER ::= { id-swb 9 } 857 id-swb-pkc-cert OBJECT IDENTIFIER ::= { id-swb 10} 858 id-swb-ac-cert OBJECT IDENTIFIER ::= { id-swb 11} 859 id-swb-pkc-all-cert-paths OBJECT IDENTIFIER ::= { id-swb 12} 860 id-swb-pkc-ee-revocation-info OBJECT IDENTIFIER ::= { id-swb 13} 861 id-swb-pkc-CAs-revocation-info OBJECT IDENTIFIER ::= { id-swb 14} 863 Conforming client implementations that support delegated path 864 validation (DPV) as defined in [RQMTS] SHOULD be able to assert at 865 least one wantback. Conforming client implementations that support 866 delegated path discovery (DPD) as defined in [RQMTS] MUST be able to 867 assert at least one wantBack. Conforming clients MAY be able to 868 assert multiple wantbacks. Conforming clients need not support all 869 of the wantbacks defined in this section. 871 3.2.4 validationPolicy 873 The validationPolicy item defines the validation policy that the 874 client wants the SCVP server to use during certificate validation. 875 If this policy cannot be used for any reason, then the server MUST 876 return an error response. 878 A validation policy MUST define default values for all parameters 879 necessary for processing an SCVP request. For each parameter, a 880 validation policy may either allow the client to specify a non- 881 default value or forbid the use of a non-default value. If the 882 client wishes to use the default values for all of the parameters, 883 then the client need only supply a reference to the policy in this 884 item. If the client wishes to use non-default values for one or 885 more parameters, then the client supplies a reference to the policy 886 plus whatever parameters are necessary to complete the request in 887 this item. If there are any conflicts between the policy referenced 888 in the request and any supplied parameter values in the request, 889 then the server MUST return an error response. 891 The syntax of the validationPolicy item is: 893 ValidationPolicy ::= SEQUENCE { 894 validationPolRef ValidationPolRef, 895 validationAlg [0] ValidationAlg OPTIONAL, 896 userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT 897 IDENTIFIER OPTIONAL, 898 inhibitPolicyMapping [2] BOOLEAN OPTIONAL, 899 requireExplicitPolicy [3] BOOLEAN OPTIONAL, 900 inhibitAnyPolicy [4] BOOLEAN OPTIONAL, 901 trustAnchors [5] TrustAnchors OPTIONAL, 902 keyUsages [6] SEQUENCE OF KeyUsage OPTIONAL, 903 extendedKeyUsages [7] SEQUENCE OF KeyPurposeId OPTIONAL } 905 The validationPolRef item is required, but the remaining items are 906 optional. The optional items are used to provide validation policy 907 parameters. When the client uses the validation policy's default 908 values for all parameters, all of the optional items are absent. 910 At a minimum, conforming SCVP client implementations MUST support 911 the ValidationPolRef item. Conforming client implementations MAY 912 support any or all of the optional items in ValidationPolicy. 914 Conforming SCVP servers MUST be able to process a ValidationPolicy 915 that contains any or all of the optional items. 917 The validationAlg item specifies the validation algorithm. The 918 userPolicySet item provides an acceptable set of certificate 919 policies. The inhibitPolicyMapping item inhibits certificate policy 920 mapping during certification path validation. The 921 requireExplicitPolicy item requires at least one valid certificate 922 policy in the certificate policies extension. The inhibitAnyPolicy 923 item indicates whether the anyPolicy certificate policy OID is 924 processed or ignored when evaluating certificate policy. The 925 trustAnchors item indicates the trust anchors that are acceptable to 926 the client. The keyUsages item indicates the technical usage of the 927 public key that is to be confirmed by the server as acceptable. The 928 extendedKeyUsages item indicates the application-specific usage of 929 the public key that is to be confirmed by the server as acceptable. 930 The syntax and semantics of each of these items is discussed in the 931 following sections. 933 3.2.4.1 validationPolRef 935 The reference to the validation policy is an OID that the client and 936 server have agreed represents a particular validation policy. 938 The syntax of the ValidationPolRef item is: 940 ValidationPolRef::= SEQUENCE { 941 valPolId OBJECT IDENTIFIER, 942 valPolParams ANY DEFINED BY valPolId OPTIONAL } 944 Where a validation policy supports additional policy-specific 945 parameter settings, these values are specified using the 946 valPolParams item. The syntax and semantics of the parameters 947 structure is defined by the object identifier encoded as the 948 valPolId. Where a validation policy has no parameters, such as the 949 default validation policy (see 3.2.4.1.1), this item MUST be 950 omitted. 952 Parameters specified in this item are independent of the validation 953 algorithm and the validation algorithm's parameters (see Section 954 3.2.4.2). For example, a server may support a validation policy 955 where it validates a certificate using the name validation algorithm 956 and also makes a determination regarding the creditworthiness of the 957 subject. In this case, the validation policy parameters could be 958 used to specify the value of the transaction. The validation 959 algorithm parameters are used to specify the application identifier 960 and name for the name validation algorithm. 962 Conforming SCVP client implementations MUST be able to specify a 963 validation policy. Conforming SCVP client implementations MAY be 964 able to specify parameters for a validation policy. Conforming SCVP 965 server implementations MUST be able to process valPolId and MAY be 966 able to process valPolParams. 968 3.2.4.1.1 Default Validation Policy 970 The client can request the SCVP server's default validation policy 971 or another validation policy. The default validation policy 972 corresponds to standard certification path processing as defined in 973 [PKIX-1] with server chosen default values (e.g., with a server 974 determined policy set and trust anchors). The default values can be 975 distributed out of band or using the policy request mechanism (see 976 Section 5). This mechanism permits the deployment of an SCVP server 977 without obtaining a new object identifier. 979 The object identifier that identifies the default validation policy 980 is: 982 id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 983 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 } 985 id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 } 987 The default validation policy MUST use the basic validation 988 algorithm as its default validation algorithm (see section 989 3.2.4.2.1), and has no validation policy parameters (see section 990 3.2.4.1). 992 When using the default validation policy, the client can override 993 any of the default parameter values by supplying a specific value in 994 the request. The SCVP server MUST make use of the provided 995 parameter values or return an error response. 997 Conforming implementations of SCVP servers MUST support the default 998 policy. However, an SCVP server may be configured to send an error 999 response to all requests using the default policy to meet local 1000 security requirements. 1002 3.2.4.2 validationAlg 1004 The optional validationAlg item defines the validation algorithm to 1005 be used by the SCVP server during certificate validation. The value 1006 of this item can be determined by agreement between the client and 1007 the server. The validation algorithm is represented by an object 1008 identifier. 1010 The syntax of the validationAlg is: 1012 ValidationAlg ::= SEQUENCE { 1013 valAlgId OBJECT IDENTIFIER, 1014 parameters ANY DEFINED BY valAlgId OPTIONAL } 1016 The following section specifies the basic validation algorithm and 1017 the name validation algorithm. 1019 SCVP servers MUST recognize and support both validation algorithms 1020 defined in this section. SCVP clients that support explicit 1021 assertion of the validation algorithm MUST support the basic 1022 validation algorithm and SHOULD support the name validation 1023 algorithm. Other validation algorithms can be specified in other 1024 documents for use with specific applications. SCVP clients and 1025 servers MAY support any such validation algorithms. 1027 3.2.4.2.1 Basic Validation Algorithm 1029 The client can request use of the SCVP basic validation algorithm or 1030 another algorithm. For identity certificates, the basic validation 1031 algorithm MUST implement the certification path validation algorithm 1032 as defined in section 6 of [PKIX-1]. For attribute certificates, 1033 the basic validation algorithm MUST implement certificate path 1034 validation as defined in section 5 of [PKIX-AC]. Other validation 1035 algorithms MAY implement functions over and above those in the basic 1036 algorithm, but validation algorithms MUST generate results compliant 1037 with the basic validation algorithm. That is, none of the 1038 validation requirements in the basic algorithm may be omitted from 1039 any newly defined validation algorithms. However, other validation 1040 algorithms MAY reject paths that are valid using the basic 1041 validation algorithm. The object identifier to identify the basic 1042 validation algorithm is: 1044 id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 } 1046 When id-svp-basicValAlg appears in valAlgId, the parameters item 1047 MUST be absent. 1049 3.2.4.2.2 Basic Validation Algorithm Errors 1051 The following errors are defined for the basic validation algorithm 1052 for inclusion in the validationErrors item in the response (see 1053 section 4.9.6). These errors can be used by any other validation 1054 algorithm since all validation algorithms MUST implement the 1055 functionality of the basic validation algorithm. 1057 id-bvae OBJECT IDENTIFIER ::= id-svp-basicValAlg 1059 id-bvae-expired OBJECT IDENTIFIER ::= { id-bvae 1 } 1060 id-bvae-not-yet-valid OBJECT IDENTIFIER ::= { id-bvae 2 } 1061 id-bvae-wrongTrustAnchor OBJECT IDENTIFIER ::= { id-bvae 3 } 1062 id-bvae-noValidCertPath OBJECT IDENTIFIER ::= { id-bvae 4 } 1063 id-bvae-revoked OBJECT IDENTIFIER ::= { id-bvae 5 } 1064 id-bvae-invalidKeyPurpose OBJECT IDENTIFIER ::= { id-bvae 9 } 1065 id-bvae-invalidKeyUsage OBJECT IDENTIFIER ::= { id-bvae 10 } 1066 id-bvae-invalidCertPolicy OBJECT IDENTIFIER ::= { id-bvae 11 } 1068 The id-bvae-expired value means that the validation time used for 1069 the request was later than the notAfter time in the end certificate 1070 (the certificate specified in the queriedCerts item). 1072 The id-bvae-not-yet-valid value means that the validation time used 1073 for the request was before the notBefore time in the end 1074 certificate. 1076 The id-bvae-wrongTrustAnchor value means that a certification path 1077 could not be constructed for the client specified trust anchor(s), 1078 but a path exists for one of the trust anchors specified in the 1079 server's default validation policy. 1081 The id-bvae-invalidKeyUsage value means that the keyUsage extension 1082 (PKIX-1 section 4.2.1.3) in the end certificate does not satisfy the 1083 validation policy. For example, the keyUsage extension in the 1084 certificate may assert only the keyEncipherment bit, but the 1085 validation policy specifies in the keyUsages item that 1086 digitalSignature is required. 1088 The id-bvae-invalidCertPolicy value means that the path is not valid 1089 under any of the policies specified in the user policy set and 1090 explicit policies are required. That is, the valid_policy_tree is 1091 NULL and the explicit_policy variable is zero (PKIX-1 section 1092 6.1.5). 1094 The id-bvae-invalidKeyPurpose value means that the extended key 1095 usage extension (PKIX-1 section 4.2.1.13) in the end certificate 1096 does not satisfy the validation policy. 1098 The id-bvae-revoked value means that the end certificate was 1099 revoked. 1101 3.2.4.2.3 Name Validation Algorithm 1103 The name validation algorithm allows the client to specify one or 1104 more subject names that MUST appear in the end certificate in 1105 addition to the requirements specified for the basic validation 1106 algorithm. The name validation algorithm allows the client to 1107 supply an application identifier and a name to the server. The 1108 application identifier defines the name matching rules to use in 1109 comparing the name supplied in the request with the names in the 1110 certificate. 1112 id-svp-nameValAlg OBJECT IDENTIFIER ::= { id-svp 2 } 1114 When the id-svp-nameValAlg appears as a valAlgId, the parameters 1115 MUST use the NameValidationAlgParms syntax: 1117 NameValidationAlgParms ::= SEQUENCE { 1118 nameCompAlgId OBJECT IDENTIFIER, 1119 validationNames GeneralNames } 1121 GeneralNames is defined in [PKIX-1]. 1123 If more than one name is supplied in the validationNames value, all 1124 names MUST be of the same type. The certificate must contain a 1125 matching name for each of the names supplied in validationNames 1126 according to the name matching rules associated with the 1127 nameCompAlgId. This specification defines three sets of name 1128 matching rules. 1130 If the nameCompAlgId supplied in the request is id-nva-dnCompAlg, 1131 then GeneralNames supplied in the request MUST be a directoryName, 1132 and the matching rules to be used are defined in [PKIX-1]. The 1133 certificate must contain a matching name in either the subject field 1134 or a directoryName in the subjectAltName extension. This 1135 specification defines the OID for id-nva-dnCompAlg as follows: 1137 id-nva-dnCompAlg OBJECT IDENTIFIER ::= { id-svp 4 } 1139 If the nameCompAlgId supplied in the request is id-kp-serverAuth 1140 [PKIX-1], then GeneralNames supplied in the request MUST be a 1141 dNSName, and the matching rules to be used are defined in [HTTP- 1142 TLS]. 1144 If the nameCompAlgId supplied in the request is id-kp-mailProtection 1145 [PKIX-1], then GeneralNames supplied in the request MUST be an 1146 rfc822Name, and the matching rules are defined in [SMIME-CERT]. 1148 Conforming SCVP servers MUST support the name validation algorithm 1149 and the matching rules associated with id-nva-dnCompAlg, id-kp- 1150 serverAuth, id-kp-mailProtection. SCVP server MAY support other 1151 name matching rules. 1153 3.2.4.2.4 Name Validation Algorithm Errors 1155 The following errors are defined for the Name Validation Algorithm: 1157 id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg 1159 id-nvae-name-mismatch OBJECT IDENTIFIER ::= { id-nvae 1 } 1160 id-nvae-no-name OBJECT IDENTIFIER ::= { id-nvae 2 } 1161 id-nvae-unknown-alg OBJECT IDENTIFIER ::= { id-nvae 3 } 1162 id-nvae-bad-name OBJECT IDENTIFIER ::= { id-nvae 4 } 1163 id-nvae-bad-name-type OBJECT IDENTIFIER ::= { id-nvae 5 } 1164 id-nvae-mixed-names OBJECT IDENTIFIER ::= { id-nvae 6 } 1166 The id-nvae-name-mismatch value means the client supplied a name 1167 with the request, which the server recognized and the server found a 1168 corresponding name type in the certificate, but was unable to find a 1169 match to the name supplied. For example, the client supplied a DNS 1170 name of example1.com, the certificate contained a DNS name of 1171 example.com. 1173 The id-nvae-no-name value means the client supplied a name with the 1174 request, which the server recognized, but the server could not find 1175 the corresponding name type in the certificate. For example, the 1176 client supplied a DNS name of example1.com, the certificate only 1177 contained a rfc822Name of user@example.com. 1179 The id-nvae-unknown-alg value means the client supplied a 1180 nameCompAlgId which the server does not recognize. 1182 The id-nvae-bad-name value means the client supplied either an empty 1183 or malformed name in the request. 1185 The id-nvae-bad-name-type value means the client supplied an 1186 inappropriate name type for the application identifier. For 1187 example, the client specified a nameCompAlgId of id-kp-serverAuth, 1188 and an rfc822Name of user@example.com. 1190 The id-nvae-mixed-names value means the client supplied multiple 1191 names in the request of different types. 1193 3.2.4.3 userPolicySet 1194 The userPolicySet item specifies a list of certificate policy 1195 identifiers that the SCVP server MUST use when constructing and 1196 validating a certification path. The userPolicySet item specifies 1197 the user-initial-policy-set as defined in Section 6 of [PKIX-1]. A 1198 userPolicySet containing the anyPolicy OID indicates a user-initial- 1199 policy-set of any-policy. 1201 SCVP clients SHOULD support userPolicySet item in requests, and SCVP 1202 servers MUST support userPolicySet item in requests. 1204 3.2.4.4 inhibitPolicyMapping 1206 The inihibitPolicyMapping item specifies an input to the 1207 certification path validation algorithm, and it controls whether 1208 policy mapping is allowed during certification path validation (see 1209 [PKIX-1], section 6.1.1). If the client wants the server to inhibit 1210 policy mapping, inhibitPolicyMapping is set to TRUE in the request. 1212 SCVP clients MAY support inhibiting policy mapping. SCVP servers 1213 SHOULD support inhibiting policy mapping. 1215 3.2.4.5 requireExplicitPolicy 1217 The requireExplicitPolicy item specifies an input to the 1218 certification path validation algorithm, and it controls whether 1219 there must be at least one valid policy in the certificate policies 1220 extension (see [PKIX-1], section 6.1.1). If the client wants the 1221 server to require at least one policy, requireExplicitPolicy is set 1222 to TRUE in the request. 1224 SCVP clients MAY support requiring explicit policies. SCVP servers 1225 SHOULD support requiring explicit policies. 1227 3.2.4.6 inhibitAnyPolicy 1229 The inhibitAnyPolicy item specifies an input to the certification 1230 path validation algorithm (see [PKIX-1], section 6.1.1), and it 1231 controls whether the anyPolicy OID is processed or ignored when 1232 evaluating certificate policy. If the client wants the server to 1233 ignore the anyPolicy OID, inhibitAnyPolicy MUST be set to TRUE in 1234 the request. 1236 SCVP clients MAY support ignoring the anyPolicy OID. SCVP servers 1237 SHOULD support ignoring the anyPolicy OID. 1239 3.2.4.7 trustAnchors 1241 The trustAnchors item specifies the trust anchors at which the 1242 certification path must terminate if the path is to be considered 1243 valid by the SCVP server for the request. If a trustAnchors item is 1244 present, the server MUST NOT consider any certification paths ending 1245 in other trust anchors as valid. 1247 The TrustAnchors type contains one or more trust anchor 1248 specifications. A certificate reference can be used to identify the 1249 trust anchor by certificate hash and distinguished name with serial 1250 number. Alternatively, trust anchors can be provided directly. The 1251 order of trust anchor specifications within the sequence is not 1252 important. Any CA certificate that meets the requirements of [PKIX- 1253 1] for signing certificates can be provided as a trust anchor. If a 1254 trust anchor is supplied that does not meet these requirements, the 1255 server MUST return an error response. 1257 The trust anchor itself, regardless of its form, MUST NOT be 1258 included in any certification path returned by the SCVP server. 1260 TrustAnchors has the following syntax: 1262 TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF PKCReference 1264 SCVP server MUST support trustAnchors. SCVP clients SHOULD support 1265 trustAnchors. 1267 3.2.4.8 keyUsages 1269 The key usage extension [PKIX-1, section 4.2.1.3] in the certificate 1270 defines the technical purpose (such as encipherment, signature, and 1271 CRL signing) of the key contained in the certificate. If the client 1272 wishes to confirm the technical usage, then it can communicate the 1273 usage it wants to validate by the same structure using the same 1274 semantics as defined in [PKIX-1]. For example, if the client 1275 obtained the certificate in the context of a digital signature, it 1276 can confirm this use by including a keyUsage structure with the 1277 digital signature bit set. 1279 If the keyUsages item is present and contains an empty sequence, it 1280 indicates that the client does not require any particular key usage. 1282 If the keyUsages item contains one or more keyUsage definitions, 1283 then the certificate MUST satisfy at least one of the specified 1284 keyUsage definitions. If the client is willing to accept multiple 1285 possibilities then the client passes in a sequence of possible 1286 patterns. Each keyUsage can contain a set of one or more bits set 1287 in the request, all bits MUST be present in the certificate to match 1288 against an instance of the keyUsage in the SCVP request. If the 1289 certificate key usage extension contains more usages than requested, 1290 then the certificate MUST be considered a match. For example, if a 1291 client wishes to check for either digital signature or non- 1292 repudiation, then the client provides two keyUsage values, one with 1293 digital signature set and the other with non-repudiation set. If 1294 the key usage extension is absent from the certificate, the 1295 certificate MUST be considered good for all usages and therefore any 1296 pattern in the SCVP request will match. 1298 SCVP clients SHOULD support keyUsages, and SCVP servers MUST support 1299 keyUsages. 1301 3.2.4.9 extendedKeyUsages 1303 The extended key usage extension [PKIX-1, section 4.2.1.13] defines 1304 more specific technical purposes, in addition to or in place of the 1305 purposes indicated in the key usage extension, for which the 1306 certified public key may be used. If the client wishes to confirm 1307 the extended key usage, then it can communicate the usage it wants 1308 to validate by the same extension using the same semantics as 1309 defined in [PKIX-1]. For example, if the client obtained the 1310 certificate in the context of a TLS server, it can confirm this 1311 usage by including the extended key usage structure with the id-kp- 1312 serverAuth object identifier. If the extension is absent or is 1313 present and asserts the anyExtendedKeyUsage OID, then all usages 1314 specified in the request are a match. If the extension is present 1315 and more than one usage is set in the request, all usages MUST be 1316 present in the certificate. If the certificate extension contains 1317 more usages than requested, then the certificate MUST be considered 1318 a match. 1320 Where the client does not require any particular extended key usage, 1321 the client can specify an empty SEQUENCE. This may be used to 1322 override extended key usage requirements imposed in the validation 1323 policy specified by valPolId. 1325 SCVP clients SHOULD support extendedKeyUsages, and SCVP servers MUST 1326 support extendedKeyUsages. 1328 3.2.5 responseFlags 1330 The optional response flags item allows the client to indicate which 1331 optional features in the CVResponse it wants the server to include. 1332 If the default values for all of the flags are used, then the 1333 response flags item MUST NOT be included in the request. 1335 The syntax of the responseFlags is: 1337 ResponseFlags ::= SEQUENCE { 1338 fullRequestInResponse [0] BOOLEAN DEFAULT FALSE, 1339 responseValidationPolByRef [1] BOOLEAN DEFAULT TRUE, 1340 protectResponse [2] BOOLEAN DEFAULT TRUE, 1341 cachedResponse [3] BOOLEAN DEFAULT TRUE } 1343 Each of the response flags is described in the following sections. 1345 3.2.5.1 fullRequestInResponse 1347 By default, the server includes a hash of the request in non-cached 1348 responses to allow the client to identify the response. If the 1349 client wants the server to include the full request in the non- 1350 cached response, fullRequestInResponse is set to TRUE. The main 1351 reason a client would request the server to include the full request 1352 in the response is to archive the request-response exchange in a 1353 single object. That is, the client wants to archive a single object 1354 that includes both request and response. 1356 SCVP clients and servers MUST support the default behavior. SCVP 1357 clients MAY support requesting and processing the full request. 1358 SCVP servers SHOULD support returning the full request. 1360 3.2.5.2 responseValidationPolByRef 1362 The responseValidationPolByRef item controls whether the response 1363 includes just a reference to the policy or a reference to the policy 1364 plus all the parameters by value of the policy used to process the 1365 request. The response MUST contain a reference to the validation 1366 policy. If the client wants the validation policy parameters to be 1367 also included by value, then responseValidationPolByRef is set to 1368 FALSE. The main reason a client would request the server to include 1369 validation policy to be included by value is to archive the request- 1370 response exchange in a single object. That is, the client wants to 1371 archive the CVResponse and have it include every aspect of the 1372 validation policy. 1374 SCVP clients and servers MUST support the default behavior. SCVP 1375 clients MAY support requesting and processing the validation policy 1376 by values. SVCP server SHOULD support returning the validation 1377 policy by values. 1379 3.2.5.3 protectResponse 1381 The protectResponse item indicates whether the client requires the 1382 server to protect the response. If the client is performing full 1383 certification path validation on the response and it is not 1384 concerned about the source of the response, then the client does not 1385 benefit from a digital signature or MAC on the response. In this 1386 case, the client can indicate to the server that protecting the 1387 message is unnecessary. However, the server is always permitted to 1388 return a protected response. 1390 SCVP clients that support delegated path discovery (DPD) as defined 1391 in [RQMTS] MUST support setting this value to FALSE. 1393 SCVP clients that support delegated path validation (DPV) as defined 1394 in [RQMTS] require an authenticated response. Unless a protected 1395 transport mechanism (such a TLS) is used, such clients MUST always 1396 set this value to TRUE or omit the responseFlags item entirely, 1397 which requires the server to return a protected response. 1399 SCVP servers MUST support returning protected responses, and SCVP 1400 servers SHOULD support returning unprotected responses. Based on 1401 local policy, the server can be configured to return protected or 1402 unprotected responses if this value is set to FALSE. If based on 1403 local policy the server is unable to return protected responses, 1404 then the server MUST return an error if this value is set to TRUE. 1406 3.2.5.4 cachedResponse 1408 The cachedResponse item indicates whether the client will accept a 1409 cached response. To enhance performance and limit the exposure of 1410 signing keys, an SCVP service may be designed to cache responses 1411 until new revocation information is expected. Where cachedResponse 1412 is set to TRUE, the client will accept a previously cached response. 1414 Clients may insist on creation of a fresh response to protect 1415 against a replay attack and ensure information is up to date. Where 1416 cachedResponse is FALSE, the client will not accept a cached 1417 response. To ensure that a response is fresh, the client MUST also 1418 include the requestNonce as defined in Section 3.4. 1420 Servers MUST process the cachedResponse flag. Where cachedResponse 1421 is FALSE, servers that cannot produce fresh responses MUST reply 1422 with an error message. Servers MAY choose to provide fresh 1423 responses even where cachedResponse is set to TRUE. 1425 3.2.6 serverContextInfo 1427 The optional serverContextInfo item, if present, contains context 1428 from a previous request-response exchange with the same SCVP server. 1429 It allows the server to return more than one certification path for 1430 the same certificate to the client. For example, if a server 1431 constructs a particular certification path for a certificate, but 1432 the client finds it unacceptable, the client can then send the same 1433 query back to the server with the serverContextInfo from the first 1434 response, and the server will be able to provide a different 1435 certification path (if another one can be found). 1437 Contents of the serverContextInfo are opaque to the SCVP client. 1438 That is, the client only knows that it needs to return the value 1439 provided by the server with the subsequent request to get a 1440 different certification path. Note that the subsequent query needs 1441 to be identical to the previous query with the exception of the 1442 following: 1444 - requestNonce; 1446 - serverContextInfo; and 1448 - the client's digital signature or MAC on the request. 1450 SCVP clients MAY support serverContextInfo, and SCVP servers SHOULD 1451 support serverContextInfo. 1453 3.2.7 validationTime 1455 The optional validationTime item, if present, tells the date and 1456 time relative to which the SCVP client wants the server to perform 1457 the checks. If the validationTime is not present, the server MUST 1458 perform the validation using the date and time at which the server 1459 processes the request. If the validationTime is present, it MUST be 1460 encoded as GeneralizedTime. The validationTime provided MUST be a 1461 retrospective time since the server can only perform a validity 1462 check using the current time (default) or previous time. A server 1463 can ignore the validationTime provided in the request if the time is 1464 within the clock skew of the server's current time. 1466 The revocation status information is obtained with respect to the 1467 validation time. When specifying a validation time other than the 1468 current time, the validation time should not necessarily be 1469 identical to the time when the private key was used. The validation 1470 time specified by the client may be adjusted to compensate for: 1472 1) time for the end-entity to realize that its private key has 1473 been or could possibly be compromised, and/or 1475 2) time for the end-entity to report the key compromise, and/or 1477 3) time for the revocation authority to process the revocation 1478 request from the end-entity, and/or 1480 4) time for the revocation authority to update and distribute 1481 the revocation status information. 1483 GeneralizedTime values MUST be expressed in Universal Coordinated 1484 Time (UTC) (which is also known as Greenwich Mean Time and Zulu 1485 time) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), 1486 even when the number of seconds is zero. GeneralizedTime values 1487 MUST NOT include fractional seconds. 1489 The information in the corresponding CertReply item in the response 1490 MUST be formatted as if the server created the response at the time 1491 indicated in the validationTime. However, if the server does not 1492 have appropriate historical information, the server MUST return an 1493 error response. 1495 SCVP servers MUST apply a clock skew to the validity time to allow 1496 for minor time synchronization errors. The default value is 10 1497 minutes. If the server uses a value other than the default it MUST 1498 include the clock skew value in the validation policy response. 1500 SCVP clients MAY support validationTime other than the current time. 1501 SCVP servers MUST support using its current time, and SHOULD support 1502 the client setting the validationTime in the request. 1504 3.2.8 intermediateCerts 1506 The optional intermediateCerts item may help the SCVP server create 1507 valid certification paths. The intermediateCerts item, when 1508 present, provides certificates that the server MAY use when forming 1509 a certification path. When building certification paths, the server 1510 MAY use the certificates in the intermediateCerts item in addition 1511 to any other certificates that the server can access. When present, 1512 the intermediateCerts item MUST contain at least one certificate, 1513 and the intermediateCerts item MUST be structured as a CertBundle. 1514 The certificates in the intermediateCerts item MUST NOT be 1515 considered as valid by the server just because they are present in 1516 this item. 1518 The CertBundle type contains one or more certificates. The order of 1519 the entries in the bundle is not important. CertBundle has the 1520 following syntax: 1522 CertBundle ::= SEQUENCE SIZE (1..MAX) OF Certificate 1524 SCVP clients SHOULD support intermediateCerts, and SCVP servers MUST 1525 support intermediateCerts. 1527 3.2.9 revInfos 1529 The optional revInfos item specifies revocation information such as 1530 CRLs, delta CRLs [PKIX-1], and OCSP responses [OCSP] that the SCVP 1531 server MAY use when validating certification paths. The purpose of 1532 the revInfos item is to provide revocation information to which the 1533 server might not otherwise have access, such as an OCSP response 1534 that the client received along with the certificate. Note that the 1535 information in the revInfos item might not be used by the server. 1536 For example, the revocation information might be associated with 1537 certificates that the server does not use in the certification path 1538 that it constructs. 1540 Clients SHOULD be courteous to the SCVP server by separating CRLs 1541 and delta CRLs. However, since the two share a common syntax, SCVP 1542 servers SHOULD accept delta CRLs even if they are identified as 1543 regular CRLs by the SCVP client. 1545 CRLs, delta CRLs, and OCSP responses can be provided as revocation 1546 information. If needed, additional object identifiers can be 1547 assigned for additional revocation information types in the future. 1549 The revInfos item uses the RevocationInfos type, which has the 1550 following syntax: 1552 RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo 1554 RevocationInfo ::= CHOICE { 1555 crl [0] CertificateList, 1556 delta-crl [1] CertificateList, 1557 ocsp [2] OCSPResponse, 1558 other [3] OtherRevInfo } 1560 OtherRevInfo ::= SEQUENCE { 1561 riType OBJECT IDENTIFIER, 1562 riValue ANY DEFINED BY riType } 1564 3.2.10 producedAt 1566 The client MAY allow the server to use a cached SCVP response. When 1567 doing so, the client MAY use the producedAt item to express 1568 requirements on the freshness of the cached response. The 1569 producedAt item tells the earliest date and time at which an 1570 acceptable cached response could have been produced. The producedAt 1571 item represents the date and time in UTC, using the GeneralizedTime 1572 type. The value in the producedAt item is independent of the 1573 validation time. 1575 GeneralizedTime value MUST be expressed in UTC, as defined in 1576 section 3.2.7. 1578 SCVP clients MAY support using producedAt values in the request. 1579 SCVP servers MAY support the producedAt values in the request. SCVP 1580 servers that support cached responses SHOULD support the producedAt 1581 value in requests. 1583 3.2.11 queryExtensions 1584 The optional queryExtensions item contains Extensions. If present, 1585 each extension in the sequence extends the query. This 1586 specification does not define any extensions; the facility is 1587 provided to allow future specifications to extend SCVP. The syntax 1588 for extensions is imported from [PKIX-1]. The queryExtensions item, 1589 when present, MUST contain a sequence of extension items, and each 1590 of the extensions MUST contain extnID, critical, and extnValue 1591 items. Each of these is described in the following sections. 1593 3.2.11.1 extnID 1595 The extnID item is an identifier for the extension. It contains the 1596 object identifier that names the extension. 1598 3.2.11.2 critical 1600 The critical item is a BOOLEAN. Each extension is designated as 1601 either critical (with a value of TRUE) or non-critical (with a value 1602 of FALSE). By default, the extension is non-critical. An SCVP 1603 server MUST reject the query if it encounters a critical extension 1604 that it does not recognize; however, a non-critical extension MAY be 1605 ignored if it is not recognized, but MUST be processed if it is 1606 recognized. 1608 3.2.11.3 extnValue 1610 The extnValue item is an octet string, which contains the extension 1611 value. An ASN.1 type is specified for each extension, identified by 1612 the associated extnID object identifier. 1614 3.3 requestorRef 1616 The optional requestorRef item contains a list of names identifying 1617 SCVP servers, and it is intended for use in environments where SCVP 1618 relay is employed. Although requestorRef is encoded as a SEQUENCE, 1619 no order is implied. The requestorRef item is used to detect 1620 looping in some configurations. The value and use of requestorRef 1621 is defined in section 7. 1623 Conforming SCVP clients MAY support specification of the 1624 requestorRef value. Conforming SCVP server implementations MUST 1625 process the requestorRef value if present. If the SCVP client 1626 includes a requestorRef value in the request, then the SCVP server 1627 MUST return the same value in a non-cached response. The SCVP 1628 server MAY omit the requestorRef value from cached SCVP responses. 1630 The requestorRef item MUST be a sequence of GeneralName. No 1631 provisions are made to ensure uniqueness of the requestorRef 1632 GeneralName values. 1634 3.4 requestNonce 1636 The optional requestNonce item contains a request identifier 1637 generated by the SCVP client. If the client includes a requestNonce 1638 value in the request, it is expressing a preference that the SCVP 1639 server SHOULD return a non-cached response. If the server returns a 1640 non-cached response it MUST include the value of requestNonce from 1641 the request in the response as the respNonce item; however, the 1642 server MAY return a cached response which MUST NOT have a respNonce. 1644 SCVP clients that insist on creation of a fresh response (e.g., to 1645 protect against a replay attack or ensure information is up to date) 1646 MUST support requestNonce. Conforming SCVP server implementations 1647 MUST process the requestNonce value if present. 1649 If the client includes a requestNonce and also sets the 1650 cachedResponse flag to FALSE as defined in section 3.2.5.4, the 1651 client is indicating that the SCVP server MUST return either a non- 1652 cached response including the respNonce or an error response. The 1653 client SHOULD include a requestNonce item in every request to 1654 prevent an attacker from acting as a man-in-the-middle by replaying 1655 old responses from the server. The requestNonce value SHOULD change 1656 with every request sent by the client. 1658 The client MUST NOT set the cachedResponse flag to FALSE without 1659 also including a requestNonce. A server receiving such a request 1660 SHOULD return an invalidRequest error response. 1662 The requestNonce item, if present, MUST be an octet string that was 1663 generated exclusively for this request. 1665 3.5 requestorName 1667 The optional requestorName item is used by the client to include an 1668 identifier in the request. The client MAY include this information 1669 for the DPV server to copy into the response. 1671 Conforming SCVP clients MAY support specification of this item in 1672 requests. SCVP servers MUST be able to process requests that 1673 include this item. 1675 3.6 responderName 1677 The optional responderName item is used by the client to indicate 1678 the identity of the SCVP server that the client expects to sign the 1679 SCVP response if the response is digitally signed. The 1680 requestorName item SHOULD only be included if: 1682 1. the request is either unprotected or digitally signed (i.e., is 1683 not protected using a MAC); and 1684 2. the responseFlags item is either absent or present with the 1685 protectResponse set to TRUE. 1687 Conforming SCVP clients MAY support specification of this item in 1688 requests. SCVP servers MUST be able to process requests that 1689 include this item. SCVP servers that maintain a single private key 1690 for signing SCVP responses or that are unable to return digitally 1691 signed responses MAY ignore the value in this item. SCVP servers 1692 that maintain more than one private key for signing SCVP responses 1693 SHOULD either (a) digitally sign the response using a private key 1694 that corresponds to a certificate that includes the name specified 1695 in responderName in either subject field or subjectAltName extension 1696 or (b) return a error indicating that the server does not possess a 1697 certificate that asserts the specified name. 1699 3.7 requestExtensions 1701 The OPTIONAL requestExtensions item contains Extensions. If 1702 present, each Extension in the sequence extends the request. This 1703 specification does not define any extensions; the facility is 1704 provided to allow future specifications to extend SCVP. The syntax 1705 for Extensions is imported from [PKIX-1]. The requestExtensions 1706 item, when present, MUST contain a sequence of extension items, and 1707 each of extension MUST contain extnID, critical, and extnValue 1708 items. Each of these is described in the following sections. 1710 3.7.1 extnID 1712 The extnID item is an identifier for the extension. It contains the 1713 object identifier that names the extension. 1715 3.7.2 critical 1717 The critical item is a BOOLEAN. Each extension is designated as 1718 either critical (with a value of TRUE) or non-critical (with a value 1719 of FALSE). By default, the extension is non-critical. An SCVP 1720 server MUST reject the query if it encounters a critical extension 1721 it does not recognize. A non-critical extension MAY be ignored if it 1722 is not recognized, but MUST be processed if it is recognized. 1724 3.7.3 extnValue 1726 The extnValue item contains an octet string. Within the octet 1727 string is the extension value. An ASN.1 type is specified for each 1728 extension, identified by the associated extnID object identifier. 1730 3.8 signatureAlg 1732 The signatureAlg item contains an AlgorithmIdentifier indicating 1733 which algorithm the server should use to sign the response message. 1734 The signatureAlg item SHOULD only be included if: 1736 1. the request is either unprotected or digitally signed (i.e., is 1737 not protected using a MAC); and 1738 2. the responseFlags item is either absent or present with the 1739 protectResponse set to TRUE. 1741 If included, the signatureAlg item SHOULD specify one of the 1742 signature algorithms specified in the signatureGeneration item of 1743 the server's validation policy response message. 1745 SCVP servers MUST be able to process requests that include this 1746 item. If the server is returning a digitally signed response to 1747 this message, then: 1749 1. If the signatureAlg item is present and specifies an algorithm 1750 that is included in the signatureGeneration item of the 1751 server's validation policy response message, the server MUST 1752 sign the response using the signature algorithm specified in 1753 signatureAlg. 1755 2. Otherwise, if the signatureAlg item is absent or is present but 1756 specifies an algorithm that is not supported by the server, the 1757 server MUST sign the response using the server's default 1758 signature algorithm as specified in the signatureGeneration 1759 item of the server's validation policy response message. 1761 3.9 hashAlg 1763 The hashAlg item contains an OBJECT IDENTIFIER indicating which hash 1764 algorithm the server should use to compute the hash value for the 1765 requestHash item in the response. SCVP clients SHOULD NOT include 1766 this item if fullRequestInResponse is set to TRUE. If included, the 1767 hashAlg item SHOULD specify one of the hash algorithms specified in 1768 the hashAlgorithms item of the server's validation policy response 1769 message. 1771 SCVP servers MUST be able to process requests that include this 1772 item. If the server is returning a response to this message that 1773 includes a requestHash then: 1775 1. If the hashAlg item is present and specifies an algorithm that 1776 is included in the hashAlgorithms item of the server's 1777 validation policy response message, the server MUST use the 1778 algorithm specified in hashAlg to compute the requestHash. 1780 2. Otherwise, if the hashAlg item is absent or is present but 1781 specifies an algorithm that is not supported by the server, the 1782 server MUST compute the requestHash using the server's default 1783 hash algorithm as specified in the hashAlgorithms item of the 1784 server's validation policy response message. 1786 3.10 RequestorText 1788 SCVP clients MAY use the requestor Text item to provide text for 1789 inclusion in the corresponding response. For example, this field 1790 may describe the nature or reason for the request. 1792 Conforming SCVP client implementations MAY support inclusion of this 1793 item in requests. Conforming SCVP Server implementations MUST 1794 accept requests that include this item. When generating non-cached 1795 responses, conforming SCVP Server implementations MUST copy the 1796 contents of this item into the requestorText item in the 1797 corresponding response (see Section 4.13). 1799 3.11 SCVP Request Authentication 1801 It is a matter of local policy what validation policy the server 1802 uses when authenticating requests. When authenticating protected 1803 SCVP requests, the SCVP servers SHOULD use the validation algorithm 1804 defined in section 6 of [PKIX-1]. 1806 If the certificate used to validate a SignedData validation request 1807 includes the key usage extension [PKIX-1, section 4.2.1.3], it MUST 1808 have either the digital signature bit set, the non-repudiation bit 1809 set, or both bits set. 1811 If the certificate used to validate an AuthenticatedData validation 1812 request includes the key usage extension, it MUST have the key 1813 agreement bit set. 1815 If the certificate used on a validation request contains the 1816 extended key usage extension [PKIX-1, section 4.2.1.13], the server 1817 SHALL verify that it contains the SCVP client OID or another OID 1818 acceptable to the server. The SCVP client OID is defined as 1819 follows: 1821 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 1823 id-kp-scvpClient OBJECT IDENTIFIER ::= { id-kp 16 } 1825 If a protected request fails to meet the validation policy of the 1826 server, it MUST be treated as an unauthenticated request. 1828 4 Validation Response 1830 An SCVP server response to the client MUST be a single CVResponse 1831 item. When a CVResponse is encapsulated in a MIME body part, 1832 application/cv-response MUST be used. 1834 There are a number of forms of an SCVP response: 1836 1. A success response to a request made over a protected transport 1837 such as TLS. These responses SHOULD NOT be protected by the 1838 server. 1840 2. A success response to a request that has protectResponse set to 1841 FALSE. These responses SHOULD NOT be protected by the server. 1843 3. The server MUST protect all other success responses. If the 1844 server is unable to return a protected success response due to 1845 local policy, then it MUST return an error response. 1847 4. An error response to a request made over a protected transport 1848 such as TLS. These responses SHOULD NOT be protected by the 1849 server 1851 5. An error response to a request that has protectResponse set to 1852 FALSE. These responses SHOULD NOT be protected by the server. 1854 6. An error response to an authenticated request. The server 1855 SHOULD protect these responses. 1857 7. An error response to an AuthenticatedData request where MAC is 1858 valid. The server MUST protect these responses. 1860 8. All other error responses MUST NOT be protected by the server. 1862 Successful responses are made when the server has fully complied 1863 with the request. That is, the server was able to build a 1864 certification path using the referenced or supplied validation 1865 policy, and it was able to comply with all the requested parameters. 1866 If the server is unable to perform validations using the required 1867 validation policy or the request contains an unsupported option, 1868 then the server MUST return an error response. 1870 For protected requests and responses, SCVP servers MUST support 1871 SignedData and SHOULD support AuthenticatedData. It is a matter of 1872 local policy which types are used. 1874 If the server is making a protected response to a protected request, 1875 then the server MUST use the same protection mechanism (SignedData 1876 or AuthenticatedData) as in the request. 1878 An overview of the structure used for an unprotected response is 1879 provided below. Many details are not shown, but the way that SCVP 1880 makes use of CMS is clearly illustrated. 1882 ContentInfo { 1883 contentType id-ct-scvp-certValResponse, 1884 -- (1.2.840.113549.1.9.16.1.11) 1885 content CVResponse } 1887 The protected response consists of a CVResponse encapsulated in 1888 either a SignedData or an AuthenticatedData, which is in turn 1889 encapsulated in a ContentInfo. That is, the EncapsulatedContentInfo 1890 field of either SignedData or AuthenticatedData consists of an 1891 eContentType field with a value of id-ct-scvp-certValResponse and an 1892 eContent field that contains a DER encoded CVResponse. 1894 The SCVP server MUST include its own certificate in the certificates 1895 field within SignedData. Other certificates MAY also be included. 1896 The SCVP server MAY also provide one or more CRLs in the crls field 1897 within SignedData. The signerInfos field of SignedData MUST include 1898 exactly one SignerInfo. The SignedData MUST NOT include the 1899 unsignedAttrs field. 1901 The signedAttrs field within SignerInfo MUST include the content- 1902 type and message-digest attributes defined in [CMS], and it SHOULD 1903 include the signing-certificate attribute as defined in [ESS]. 1904 Within the signing-certificate attribute, the first certificate 1905 identified in the sequence of certificate identifiers MUST be the 1906 certificate of the SCVP server. The inclusion of other certificate 1907 identifiers in the signing-certificate attribute is OPTIONAL. The 1908 inclusion of policies in the signing-certificate is OPTIONAL. 1910 The recipientInfos field of AuthenticatedData MUST include exactly 1911 one RecipientInfo, which contains information for the client that 1912 sent the request. The AuthenticatedData MUST NOT include the 1913 unauthAttrs field. 1915 The CVResponse item contains the server's response. The CVResponse 1916 MUST contain the cvResponseVersion, serverConfigurationID, 1917 producedAt, and responseStatus items. The CVResponse MAY also 1918 contain the respValidationPolicy, requestRef, requestorRef, 1919 requestorName, replyObjects, respNonce, serverContextInfo, and 1920 cvResponseExtensions items. The replyObjects item MUST contain 1921 exactly one CertReply item for each certificate requested. The 1922 requestorRef item MUST be included if the request included a 1923 requestorRef item and a non-cached response is provided. The 1924 respNonce item MUST be included if the request included a 1925 requestNonce item and a non-cached response is provided. 1927 The CVResponse MUST have the following syntax: 1929 CVResponse ::= SEQUENCE { 1930 cvResponseVersion INTEGER, 1931 serverConfigurationID INTEGER, 1932 producedAt GeneralizedTime, 1933 responseStatus ResponseStatus, 1934 respValidationPolicy [0] RespValidationPolicy OPTIONAL, 1935 requestRef [1] RequestReference OPTIONAL, 1936 requestorRef [2] GeneralNames OPTIONAL, 1937 requestorName [3] GeneralNames OPTIONAL, 1938 replyObjects [4] ReplyObjects OPTIONAL, 1939 respNonce [5] OCTET STRING OPTIONAL, 1940 serverContextInfo [6] OCTET STRING OPTIONAL, 1941 cvResponseExtensions [7] Extensions OPTIONAL, 1942 requestorText [8] UTF8String (SIZE (1..256)) OPTIONAL } 1944 Conforming SCVP servers MAY be capable of constructing a CVResponse 1945 that includes the serverContextInfo or cvResponseExtensions items. 1946 Conforming SCVP servers MUST be capable of constructing a CVResponse 1947 with any of the remaining optional items. Conforming SCVP clients 1948 MUST be capable of processing a CVResponse with the following 1949 optional items: respValidationPolicy; requestRef; requestorName; 1950 replyObjects; and respNonce. 1952 Conforming SCVP clients that are capable of including requestorRef 1953 in a request MUST be capable of processing a CVResponse that 1954 includes the requestorRef item. Conforming SCVP clients MUST be 1955 capable of processing a CVResponse that includes the 1956 serverContextInfo or cvResponseExtensions items. Conforming clients 1957 MUST be able to determine if critical extensions are present in the 1958 cvResponseExtensions item. 1960 4.1 cvResponseVersion 1962 The syntax and semantics of cvResponseVersion are the same as 1963 cvRequestVersion as described in section 3.1. The cvResponseVersion 1964 MUST match the cvRequestVersion in the request. If the server 1965 cannot generate a response with a matching version number, then the 1966 server MUST return an error response that indicates the highest 1967 version number that the server supports as the version number. 1969 4.2 serverConfigurationID 1971 The server configuration ID represents the version of the SCVP 1972 server configuration when it processed the request. See section 6.4 1973 for details. 1975 4.3 producedAt 1977 The producedAt item tells the date and time at which the SCVP server 1978 generated the response. The producedAt item MUST be expressed in 1979 UTC, and it MUST be interpreted as defined in section 3.2.7. This 1980 value is independent of the validation time. 1982 4.4 responseStatus 1984 The responseStatus item gives status information to the SCVP client 1985 about its request. The responseStatus item has a numeric status 1986 code and an optional string that is a sequence of characters from 1987 the ISO/IEC 10646-1 character set encoded with the UTF-8 1988 transformation format defined in [UTF8]. 1990 The string MAY be used to transmit status information. The client 1991 MAY choose to display the string to a human user. However, because 1992 there is often no way to know the languages understood by a human 1993 user, the string may be of little or no assistance. 1995 The responseStatus item uses the ResponseStatus type, which has the 1996 following syntax: 1998 ResponseStatus ::= SEQUENCE { 1999 statusCode CVStatusCode DEFAULT okay, 2000 errorMessage UTF8String OPTIONAL } 2002 CVStatusCode ::= ENUMERATED { 2003 okay (0), 2004 skipUnrecognizedItems (1), 2005 tooBusy (10), 2006 invalidRequest (11), 2007 internalError (12), 2008 badStructure (20), 2009 unsupportedVersion (21), 2010 abortUnrecognizedItems (22), 2011 unrecognizedSigKey (23), 2012 badSignatureOrMAC (24), 2013 unableToDecode (25), 2014 notAuthorized (26), 2015 unsupportedChecks (27), 2016 unsupportedWantBacks (28), 2017 unsupportedSignatureOrMAC (29), 2018 invalidSignatureOrMAC (30), 2019 protectedResponseUnsupported (31), 2020 unrecognizedResponderName (32), 2021 relayingLoop (40), 2022 unrecognizedValPol (50), 2023 unrecognizedValAlg (51), 2024 fullRequestInResponseUnsupported (52), 2025 fullPolResponseUnsupported (53), 2026 inhibitPolicyMappingUnsuported (54), 2027 requireExplicitPolicyUnsupported (55), 2028 inhibitAnyPolicyUnsupported (56), 2029 validityTimeUnsupported (57), 2030 unrecognizedCritQueryExt (63), 2031 unrecognizedCritRequestExt (64) } 2033 The CVStatusCode values have the following meaning: 2035 0 The request was fully processed. 2036 1 The request included some unrecognized non-critical extensions; 2037 however, processing was able to continue ignoring them. 2038 10 Too busy; try again later. 2039 11 The server was able to decode the request, but there was some 2040 other problem with the request. 2041 12 An internal server error occurred. 2042 20 The structure of the request was wrong. 2043 21 The version of request is not supported by this server. 2044 22 The request included unrecognized items, and the server was not 2045 able to continue processing. 2046 23 The server could not validate the key used to protect the 2047 request. 2048 24 The signature or message authentication code did not match the 2049 body of the request. 2050 25 The encoding was not understood. 2051 26 The request was not authorized. 2052 27 The request included unsupported checks items, and the server 2053 was not able to continue processing. 2054 28 The request included unsupported want back items, and the 2055 server was not able to continue processing. 2056 29 The server does not support the signature or message 2057 authentication code algorithm used by the client to protect the 2058 request. 2059 30 The server could not validate the client's signature or message 2060 authentication code on the request. 2061 31 The server could not generate a protected response as requested 2062 by the client. 2063 32 The server does not have a certificate matching the requested 2064 responder name. 2065 40 The request was previously relayed by the same server. 2066 50 The request contained an unrecognized validation policy 2067 reference. 2068 51 The request contained an unrecognized validation algorithm OID. 2069 52 The server does not support returning the full request in the 2070 response. 2071 53 The server does not support returning the full validation 2072 policy by value in the response. 2074 54 The server does not support inhibiting policy mapping. 2075 55 The server does not support requiring explicit policy. 2076 56 The server does not support ignoring the anyPolicy certificate 2077 policy OID. 2078 57 The server only validates requests using current time. 2079 63 The query item in the request contains a critical extension 2080 whose OID is not recognized. 2081 64 The request contains a critical request extension whose OID is 2082 not recognized. 2084 Status codes 0-9 are reserved for codes that indicate the request 2085 was processed by the server and therefore MUST be sent in a success 2086 response. Status codes 10 and above indicate an error and MUST 2087 therefore be sent in an error response. 2089 4.5 respValidationPolicy 2091 The respValidationPolicy item contains either a reference to the 2092 full validation policy or the full policy by value used by the 2093 server to validate the request. It MUST be present in success 2094 responses and MUST NOT be present in error responses. The choice 2095 between returning the policy by reference or by value is controlled 2096 by the responseValidationPolByRef item in the request. The 2097 resultant validation policy is the union of the following: 2099 1. Values from the request. 2101 2. For values that are not explicitly included in the request, 2102 values from the validation policy specified by reference in 2103 the request. 2105 The RespValidationPolicy syntax is: 2107 RespValidationPolicy ::= ValidationPolicy 2109 The validationPolicy item is defined in section 3.2.4. When 2110 responseValidationPolByRef is set to FALSE in the request, all items 2111 in the validationPolicy item MUST be populated. When 2112 responseValidationPolByRef is set to TRUE, OPTIONAL items in the 2113 validationPolicy item only need to be populated for items for which 2114 the value in the request differs from the value from the referenced 2115 validation policy. 2117 Conforming SCVP clients MUST be capable of processing the validation 2118 policy by reference. SCVP clients MAY be capable of processing the 2119 optional items in the validation policy. 2121 Conforming SCVP server implementations MUST be capable of asserting 2122 the policy by reference, and MUST be capable of including the 2123 optional items. 2125 4.6 requestRef 2127 The requestRef item allows the SCVP client to identify the request 2128 that corresponds to this response from the server. It associates 2129 the response to a particular request using either a hash of the 2130 request or a copy of CVRequest from the request. 2132 The requestRef item does not provide authentication, but does allow 2133 the client to determine that the request was not maliciously 2134 modified. 2136 The requestRef item allows the client to associate a response with a 2137 request. The requestNonce provides an alternative mechanism for 2138 matching requests and responses. When the fullRequest alternative 2139 is used, the response provides a single data structure that is 2140 suitable for archive of the transaction. 2142 The requestRef item uses the RequestReference type, which has the 2143 following syntax: 2145 RequestReference ::= CHOICE { 2146 requestHash [0] HashValue, -- hash of CVRequest 2147 fullRequest [1] CVRequest } 2149 SCVP clients MUST support requestHash, and they MAY support 2150 fullRequest. SCVP servers MUST support using requestHash, and they 2151 SHOULD support using fullRequest. 2153 4.6.1 requestHash 2155 The requestHash item is the hash of the CVRequest. The one-way hash 2156 function used to compute the hash of the CVRequest is as specified 2157 in section 3.9. The requestHash item serves two purposes. First, 2158 it allows a client to determine that the request was not maliciously 2159 modified. Second, it allows the client to associate a response with 2160 a request when using connectionless protocols. The requestNonce 2161 provides an alternative mechanism for matching requests and 2162 responses. 2164 The requestHash item uses the HashValue type, which has the 2165 following syntax: 2167 HashValue ::= SEQUENCE { 2168 algorithm AlgorithmIdentifier DEFAULT { sha-1 }, 2169 value OCTET STRING } 2171 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 2172 oiw(14) secsig(3) algorithm(2) 26 } 2174 The algorithm identifier for SHA-1 is imported from [PKIX-ALG]. It 2175 is repeated here for convenience. 2177 4.6.2 fullRequest 2179 Like requestHash, the fullRequest alternative allows a client to 2180 determine that the request was not maliciously modified. It also 2181 provides a single data structure that is suitable for archive of the 2182 transaction. 2184 The fullRequest item uses the CVRequest type. The syntax and 2185 semantics of the CVRequest type are described in section 3. 2187 4.7 requestorRef 2189 The optional requestorRef item is used by the client to identify the 2190 original requestor in cases where SCVP relay is used. The value is 2191 only of local significance to the client. If the SCVP client 2192 includes a requestorRef value in the request, then the SCVP server 2193 MUST return the same value if the server is generating a non-cached 2194 response. 2196 4.8 requestorName 2198 The optional requestorName item is used by the server to return one 2199 or more identities associated with the client in the response. 2201 The SCVP server MAY choose to include any or all of the following: 2203 (1) the identity asserted by the client in the requestorName item 2204 of the request, 2205 (2) an authenticated identity for the client from a certificate or 2206 other credential used to authenticate the request, or 2207 (3) a client identifier from an out-of-band mechanism. 2209 Alternatively, the SCVP server MAY omit this item. 2211 In the case of non-cached responses to authenticated requests, the 2212 SCVP server SHOULD return a requestor name. 2214 SCVP servers that support authenticated requests SHOULD support this 2215 item. 2217 SCVP clients MUST be able to process responses that include this 2218 item, although the item value might not impact the processing in any 2219 manner. 2221 4.9 replyObjects 2223 The replyObjects item returns requested objects to the SCVP client, 2224 each of which tells the client about a single certificate from the 2225 request. The replyObjects item MUST be present in the response, 2226 unless the response is reporting an error. The CertReply item MUST 2227 contain cert, replyStatus, replyValTime, replyChecks, and 2228 replyWantBacks items; and the CertReply item MAY contain the 2229 validationErrors, nextUpdate, and certReplyExtensions items. 2231 A success response MUST contain one CertReply for each certificate 2232 specified in the queriedCerts item in the request. The order is 2233 important. The first CertReply in the sequence MUST correspond to 2234 the first certificate in the request; the second CertReply in the 2235 sequence MUST correspond to the second certificate in the request; 2236 and so on. 2238 The checks item in the request determines the content of the 2239 replyChecks item in the response. The wantBack item in the request 2240 determines the content of the replyWantBacks item in the response. 2241 The queryExtensions items in the request controls the absence or the 2242 presence and content of the certReplyExtensions item in the 2243 response. 2245 The replyObjects item uses the ReplyObjects type, which has the 2246 following syntax: 2248 ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply 2250 CertReply ::= SEQUENCE { 2251 cert CertReference, 2252 replyStatus ReplyStatus DEFAULT success, 2253 replyValTime GeneralizedTime, 2254 replyChecks ReplyChecks, 2255 replyWantBacks ReplyWantBacks, 2256 validationErrors [0] SEQUENCE SIZE (1..MAX) OF 2257 OBJECT IDENTIFIER OPTIONAL, 2258 nextUpdate [1] GeneralizedTime OPTIONAL, 2259 certReplyExtensions [2] Extensions OPTIONAL } 2261 4.9.1 cert 2263 The cert item contains either the certificate or a reference to the 2264 certificate about which the client is requesting information. If 2265 the certificate was specified by reference in the request, the 2266 request included either the id-swb-pkc-cert or id-swb-aa-cert 2267 wantBack, and the server was able to obtain the referenced 2268 certificate then this item MUST include the certificate. Otherwise, 2269 this item MUST include the same value as was used in the 2270 queriedCerts item in the request. 2272 CertReference has the following syntax: 2274 CertReference ::= CHOICE { 2275 pkc PKCReference, 2276 ac ACReference } 2278 4.9.2 replyStatus 2280 The replyStatus item gives status information to the client about 2281 the request for the specific certificate. Note that the 2282 responseStatus item is different than the replyStatus item. The 2283 responseStatus item is the status of the whole request, while the 2284 replyStatus item is the status for the individual query item. 2286 The replyStatus item uses the ReplyStatus type, which has the 2287 following syntax: 2289 ReplyStatus ::= ENUMERATED { 2290 success (0), 2291 malformedPKC (1), 2292 malformedAC (2), 2293 unavailableValidityTime (3), 2294 referenceCertHashFail (4), 2295 certPathConstructFail (5), 2296 certPathNotValid (6), 2297 certPathNotValidNow (7), 2298 wantBackUnsatisfied (8) } 2300 The meaning of the various ReplyStatus values are: 2302 0 Success: all checks were performed successfully. 2303 1 Failure: the public key certificate was malformed. 2304 2 Failure: the attribute certificate was malformed. 2305 3 Failure: historical data for the requested validity time is not 2306 available. 2307 4 Failure: the server could not locate the reference certificate or 2308 the referenced certificate did not match the hash value 2309 provided. 2310 5 Failure: no certification path could be constructed. 2311 6 Failure: the constructed certification path is not valid with 2312 respect to the validation policy. 2314 7 Failure: the constructed certification path is not valid with 2315 respect to the validation policy, but a query at a later time 2316 may be successful. 2317 8 Failure: all checks were performed successfully, however one or 2318 more of the wantBacks could not be satisfied. 2320 Codes 1 and 2 are used to tell the client that the request was 2321 properly formed, but the certificate in question was not. This is 2322 especially useful to clients that do not parse certificates. 2324 Code 7 is used to tell the client that a valid certification path 2325 was found with the exception that a certificate in the path is on 2326 hold, current revocation information is unavailable, or the 2327 validation time precedes the notBefore time in one or more 2328 certificates in the path. 2330 For codes 1, 2, 3, and 4, the replyChecks and replyWantBacks items 2331 are not populated (i.e., they MUST be an empty sequence). For codes 2332 5, 6, 7, and 8 replyChecks MUST include an entry corresponding to 2333 each check in the request; the replyWantBacks item is not populated. 2335 4.9.3 replyValTime 2337 The replyValTime item tells the time at which the information in the 2338 CertReply was correct. The replyValTime item represents the date 2339 and time in UTC, using GeneralizedTime type. The encoding rules for 2340 GeneralizedTime in section 3.2.7 MUST be used. 2342 Within the request, the optional validityTime item tells the date 2343 and time relative to which the SCVP client wants the server to 2344 perform the checks. If the validityTime is not present, the server 2345 MUST respond as if the client provided the date and time at which 2346 the server processes the request. 2348 The information in the CertReply item MUST be formatted as if the 2349 server created this portion of the response at the time indicated in 2350 the validityTime item of the query. However, if the server does not 2351 have appropriate historical information, the server MAY either 2352 return an error or return information for a later time. 2354 4.9.4 replyChecks 2356 The replyChecks item contains the responses to the checks item in 2357 the query. The replyChecks item includes the object identifier 2358 (OID) from the query and an integer. The value of the integer 2359 indicates whether the requested check was successful. The OIDs in 2360 the checks item of the query are used to identify the corresponding 2361 replyChecks values. Each OID specified in the checks item in the 2362 request MUST be matched by an OID in the replyChecks item of the 2363 response. In the case of an error response, the server MAY include 2364 additional checks in the response to further explain the error. 2365 Clients MUST ignore any unrecognized ReplyCheck included in the 2366 response. 2368 The replyChecks item uses the ReplyChecks type, which has the 2369 following syntax: 2371 ReplyChecks ::= SEQUENCE OF ReplyCheck 2373 ReplyCheck ::= SEQUENCE { 2374 check OBJECT IDENTIFIER, 2375 status INTEGER DEFAULT 0 } 2377 The status value for public key certification path building to a 2378 trusted root, { id-stc 1 }, can be one of the following: 2380 0: Built a path 2381 1: Could not build a path 2383 The status value for public key certification path building to a 2384 trusted root along with simple validation processing, { id-stc 2 }, 2385 can be one of the following: 2387 0: Valid 2388 1: Not valid 2390 The status value for public key certification path building to a 2391 trusted root along with complete status checking, { id-stc 3 }, can 2392 be one of the following: 2394 0: Valid 2395 1: Not valid 2396 2: Revocation Offline 2397 3: Revocation Unavailable 2398 4: No known source for revocation information 2400 Revocation offline means that the server or distribution point for 2401 the revocation information was connected to successfully without a 2402 network error but either no data was returned or if data was 2403 returned it was stale. Revocation unavailable means that a network 2404 error was returned when an attempt was made to reach the server or 2405 distribution point. No known source for revocation information 2406 means that the server was able to build a valid certification path 2407 but was unable to locate a source for revocation information for one 2408 or more certificates in the path. 2410 The status value for AC issuer certification path building to a 2411 trusted root, { id-stc 4 }, can be one of the following: 2413 0: Built a path 2414 1: Could not build a path 2416 The status value for AC issuer certification path building to a 2417 trusted root along with simple validation processing, { id-stc 5 }, 2418 can be one of the following: 2420 0: Valid 2421 1: Not valid 2423 The status value for AC issuer certification path building to a 2424 trusted root along with complete status checking, { id-stc 6 }, can 2425 be one of the following: 2427 0: Valid 2428 1: Not Valid 2429 2: Revocation Offline 2430 3: Revocation Unavailable 2431 4: No known source for revocation information 2433 The status value for revocation status checking of an AC as well as 2434 AC issuer certification path building to a trusted root along with 2435 complete status checking, { id-stc 7 }, can be one of the following: 2437 0: Valid 2438 1: Not Valid 2439 2: Revocation Offline 2440 3: Revocation Unavailable 2441 4: No known source for revocation information 2443 4.9.5 replyWantBacks 2445 The replyWantBacks item contains the responses to the wantBack item 2446 in the request. The replyWantBacks item includes the object 2447 identifier (OID) from the wantBack item in the request and an octet 2448 string. Within the octet string is the requested value. The OIDs 2449 in the wantBack item in the request are used to identify the 2450 corresponding reply value. The OIDs in the replyWantBacks item MUST 2451 match the OIDs in the wantBack item in the request. For a non-error 2452 response, replyWantBacks MUST include exactly one replyWantBack for 2453 each wantBack specified in the request (excluding id-swb-pkc-cert 2454 and id-swb-ac-cert, where the requested information is included in 2455 the cert item). 2457 The replyWantBacks item uses the ReplyWantBacks type, which has the 2458 following syntax: 2460 ReplyWantBacks ::= SEQUENCE OF ReplyWantBack 2461 ReplyWantBack::= SEQUENCE { 2462 wb OBJECT IDENTIFIER, 2463 value OCTET STRING } 2465 The octet string value for the certification path used to verify the 2466 certificate in the request, { id-swb 1 }, contains the CertBundle 2467 type. The syntax and semantics of the CertBundle type are described 2468 in section 3.2.8. This CertBundle includes all the certificates in 2469 the path, starting with the end certificate and ending with the 2470 certificate issued by the trust anchor. 2472 The octet string value for the proof of revocation status, { id-swb 2473 2 }, contains the RevInfoWantBack type. The RevInfoWantBack type is 2474 a SEQUENCE of the RevocationInfos type and an optional CertBundle. 2475 The syntax and semantics of the RevocationInfos type are described 2476 in section 3.2.9. The CertBundle MUST be included if any 2477 certificates required to validate the revocation information were 2478 not returned in the id-swb-pkc-best-cert-path or id-swb-pkc-all- 2479 cert-paths want back. The CertBundle MUST include all such 2480 certificates but there are no ordering requirements. 2482 RevInfoWantBack ::= SEQUENCE { 2483 revocationInfo RevocationInfos, 2484 extraCerts CertBundle OPTIONAL } 2486 The octet string value for the public key information, { id-swb 4 }, 2487 contains the SubjectPublicKeyInfo type. The syntax and semantics of 2488 the SubjectPublicKeyInfo type are described in [PKIX-1]. 2490 The octet string value for the AC issuer certification path used to 2491 verify the certificate in the request, { id-swb 5 }, contains the 2492 CertBundle type. The syntax and semantics of the CertBundle type 2493 are described in section 3.2.8. This CertBundle includes all the 2494 certificates in the path, beginning with the AC issuer certificate 2495 and ending with the certificate issued by the trust anchor. 2497 The octet string value for the proof of revocation status of the AC 2498 issuer certification path, { id-swb 6 }, contains the 2499 RevInfoWantBack type. The RevInfoWantBack type is a SEQUENCE of the 2500 RevocationInfos type and an optional CertBundle. The syntax and 2501 semantics of the RevocationInfos type are described in section 2502 3.2.9. The CertBundle MUST be included if any certificates required 2503 to validate the revocation information were not returned in the id- 2504 aa-cert-path want back. The CertBundle MUST include all such 2505 certificates but there are no ordering requirements. 2507 The octet string value for the proof of revocation status of the 2508 attribute certificate, { id-swb 7 }, contains the RevInfoWantBack 2509 type. The RevInfoWantBack type is a SEQUENCE of the RevocationInfos 2510 type and an optional CertBundle. The syntax and semantics of the 2511 RevocationInfos type are described in section 3.2.9. The CertBundle 2512 MUST be included if any certificates required to validate the 2513 revocation information were not returned in the id-swb-aa-cert-path 2514 want back. The CertBundle MUST include all such certificates but 2515 there are no ordering requirements. 2517 The octet string value for returning all paths, { id-swb 12 }, 2518 contains an ASN.1 type CertBundles, as defined below. The syntax 2519 and semantics of the CertBundle type are described in section 3.2.8. 2520 Each CertBundle includes all the certificates in one path, starting 2521 the end certificate and ending with the certificate issued by the 2522 trust anchor. 2524 CertBundles ::= SEQUENCE SIZE (1..MAX) OF CertBundle 2526 The octet string value for relayed responses, { id-swb 9 }, contains 2527 an ASN.1 type SCVPResponses, as defined below. If the SCVP server 2528 used information obtained from other SCVP servers when generating 2529 this response, then SCVPResponses MUST include each of the SCVP 2530 responses received from those servers. If the SCVP server did not 2531 use information obtained from other SCVP servers when generating the 2532 response, then SCVPResponses MUST be an empty sequence. 2534 SCVPResponses ::= SEQUENCE OF ContentInfo 2536 The octet string value for the proof of revocation status of the 2537 path's target certificate, { id-swb-13 }, contains the 2538 RevInfoWantBack type. The RevInfoWantBack type is a SEQUENCE of the 2539 RevocationInfos type and an optional CertBundle. The syntax and 2540 semantics of the RevocationInfos type are described in section 2541 3.2.9. The CertBundle MUST be included if any certificates required 2542 to validate the revocation information were not returned in the id- 2543 swb-pkc-best-cert-path or id-swb-pkc-all-cert-paths want back. The 2544 CertBundle MUST include all such certificates but there are no 2545 ordering requirements. 2547 The octet string value for the proof of revocation status of the 2548 intermediate certificates in the path, { id-swb 14 }, contains the 2549 RevInfoWantBack type. The RevInfoWantBack type is a SEQUENCE of the 2550 RevocationInfos type and an optional CertBundle. The syntax and 2551 semantics of the RevocationInfos type are described in section 2552 3.2.9. The CertBundle MUST be included if any certificates required 2553 to validate the revocation information were not returned in the id- 2554 swb-pkc-best-cert-path or id-swb-pkc-all-cert-paths want back. The 2555 CertBundle MUST include all such certificates but there are no 2556 ordering requirements. 2558 4.9.6 validationErrors 2560 The validationErrors item MUST only be present in failure responses. 2561 If present, it MUST contain one or more OIDs representing the reason 2562 the validation failed (validation errors for the basic validation 2563 algorithm and name validation algorithm are defined in sections 2564 3.2.4.2.2 and 3.2.4.2.4). The validationErrors item SHOULD only be 2565 included when the replyStatus is 3, 5, 6, 7, or 8. SCVP servers are 2566 not required to specify all of the reasons that validation failed. 2567 SCVP clients MUST NOT assume that the OIDs included in 2568 validationErrors represent all of the validation errors for the 2569 certification path. 2571 4.9.7 nextUpdate 2573 The nextUpdate item tells the time at which the server expects a 2574 refresh of information regarding the validity of the certificate to 2575 become available. The nextUpdate item is especially interesting if 2576 the certificate revocation status information is not available or 2577 the certificate is suspended. The nextUpdate item represents the 2578 date and time in UTC, using the GeneralizedTime type. The encoding 2579 rules for GeneralizedTime in section 3.2.7 MUST be used. 2581 4.9.8 certReplyExtensions 2583 The certReplyExtensions contains the responses to the 2584 queryExtensions item in the request. The certReplyExtensions item 2585 uses the Extensions type defined in [PKIX-1]. The object 2586 identifiers (OIDs) in the queryExtensions item in the request are 2587 used to identify the corresponding reply values. The 2588 certReplyExtensions item, when present, contains a sequence of 2589 Extension items, each of which contains an extnID item, a critical 2590 item, and an extnValue item. 2592 The extnID item is an identifier for the extension. It contains the 2593 OID that names the extension, and it MUST match one of the OIDs in 2594 the queryExtensions item in the request. 2596 The critical item is a BOOLEAN, and it MUST be set to FALSE. 2598 The extnValue item contains an OCTET STRING. Within the OCTET 2599 STRING is the extension value. An ASN.1 type is specified for each 2600 extension, identified by the associated extnID object identifier. 2602 4.10 respNonce 2604 The respNonce item contains an identifier to bind the request to the 2605 response. 2607 If the client includes a requestNonce value in the request and the 2608 server is generating a specific non-cached response to the request 2609 then the server MUST return the same value in the response. 2611 If the server is using a cached response to the request then it MUST 2612 omit the respNonce item. 2614 If the server is returning a specific non-cached response to a 2615 request without a nonce, then the server MAY include a message 2616 specific nonce. For digitally signed messages, the server MAY use 2617 the value of the message-digest attribute in the signedAttrs within 2618 SignerInfo of the request as the value in the respNonce item. 2620 The requestNonce item uses the octet string type. 2622 Conforming client implementations MUST be able to process a response 2623 that includes this item. Conforming servers MUST support respNonce. 2625 4.11 serverContextInfo 2627 The serverContextInfo item in a response is a mechanism for the 2628 server to pass some opaque context information to the client. If 2629 the client does not like the certification path returned, it can 2630 make a new query and pass along this context information. 2632 Section 3.2.6 contains information about the client's usage of this 2633 item. 2635 The context information is opaque to the client, but it provides 2636 information to the server that ensures that a different 2637 certification path will be returned (if another one can be found). 2638 The context information could indicate state of the server or it 2639 could contain a sequence of hashes of certification paths that have 2640 already been returned to the client. The protocol does not dictate 2641 any structure or requirements for this item. However, implementers 2642 should review the Security Considerations section of this document 2643 before selecting a structure. 2645 Servers that are incapable of returning additional paths MUST NOT 2646 include the serverContextInfo item in the response. 2648 4.12 cvResponseExtensions 2650 If present, the cvResponseExtensions item contains a sequence of 2651 Extensions that extend the response. This specification does not 2652 define any extensions. The facility is provided to allow future 2653 specifications to extend SCVP. The syntax for Extensions is 2654 imported from [PKIX-1]. The cvResponseExtensions item, when 2655 present, contains a sequence of Extension items, each of which 2656 contains an extnID item, a critical item, and an extnValue item. 2658 The extnID item is an identifier for the extension. It contains the 2659 object identifier (OID) that names the extension. 2661 The critical item is a BOOLEAN. Each extension is designated as 2662 either critical (with a value of TRUE) or non-critical (with a value 2663 of FALSE). An SCVP client MUST reject the response if it encounters 2664 a critical extension it does not recognize; however, a non-critical 2665 extension MAY be ignored if it is not recognized. 2667 The extnValue item contains an OCTET STRING. Within the OCTET 2668 STRING is the extension value. An ASN.1 type is specified for each 2669 extension, identified by the associated extnID object identifier. 2671 4.13 RequestorText 2673 The requestorText item contains a text field supplied by the client. 2675 If the client includes a requestorText value in the request and the 2676 server is generating a specific non-cached response to the request 2677 then the server MUST return the same value in the response. 2679 If the server is using a cached response to the request then it MUST 2680 omit the requestorText item. 2682 The requestNonce item uses the UTF8 string type. 2684 Conforming client implementations that support the requestorText 2685 item in requests (see Section 3.10) MUST be able to process a 2686 response that includes this item. Conforming servers MUST support 2687 requestorText in responses. 2689 4.14 SCVP Response Validation 2691 There are two mechanisms for validation of SCVP responses, one based 2692 on the client's knowledge of a specific SCVP server key and the 2693 other based on validation of the certificate corresponding to the 2694 private key used to protect the SCVP response. 2696 4.14.1 Simple Key Validation 2698 The simple key validation method is where the SCVP client has a 2699 local policy of one or more SCVP server keys that directly identify 2700 the set of valid SCVP servers. Mechanisms for storage of server 2701 keys or identifiers are a local matter. For example, a client could 2702 store cryptographic hashes of public keys used to verify SignedData 2703 responses. Alternatively, a client could store shared symmetric 2704 keys used to verify MACs in AuthenticatedData responses. 2706 Simple key validation MUST be used by SCVP clients that cannot 2707 validate PKIX-1 certificates and are therefore making delegated path 2708 validation requests to the SCVP server [RQTMS]. It is a matter of 2709 local policy with these clients whether to use SignedData or 2710 AuthenticatedData. Simple key validation MAY be used by other SCVP 2711 clients for other reasons. 2713 4.14.2 SCVP Server Certificate Validation 2715 It is a matter of local policy what validation policy the client 2716 uses when validating responses. When validating protected SCVP 2717 responses, SCVP clients SHOULD use the validation algorithm defined 2718 in section 6 of [PKIX-1]. SCVP clients may impose additional 2719 limitations on the algorithm, such as limiting the number of 2720 certificates in the path or establishing initial name constraints, 2721 as specified in section 6.2 of [PKIX-1]. 2723 If the certificate used to sign the validation policy responses and 2724 SignedData validation responses contains the key usage extension 2725 [PKIX-1 section 4.2.1.3] it MUST have either the digital signature 2726 bit set, the non-repudiation bit set, or both bits set. 2728 If the certificate for AuthenticatedData validation responses 2729 contains the key usage extension it MUST have the key agreement bit 2730 set. 2732 If the certificate used on a validation policy response or a 2733 validation response contains the extended key usage extension [PKIX- 2734 1 section 4.2.1.13] it MUST contain the following OID: 2736 id-kp-scvpServer OBJECT IDENTIFIER ::= { id-kp 15 } 2738 5 Server Policy Request 2740 An SCVP client uses the ValPolRequest item to request information 2741 about an SCVP server's policies and configuration information, 2742 including the list of validation policies supported by the SCVP 2743 server. When a ValPolRequest is encapsulated in a MIME body part, 2744 it MUST be carried in an application/vp-request MIME body part. 2746 The request consists of a ValPolRequest encapsulated in a 2747 ContentInfo. The client does not sign the request. 2749 ContentInfo { 2750 contentType id-ct-scvp-valPolRequest, 2751 -- (1.2.840.113549.1.9.16.1.12) 2753 content ValPolRequest } 2755 The ValPolRequest type has the following syntax: 2757 ValPolRequest ::= SEQUENCE { 2758 vpRequestVersion INTEGER DEFAULT 1, 2759 requestNonce OCTET STRING } 2761 Conforming SCVP server implementations MUST recognize and process 2762 the server policy request. Conforming clients SHOULD support the 2763 server policy request. 2765 5.1 vpRequestVersion 2767 The syntax and semantics of vpRequestVersion are the same as 2768 cvRequestVersion as described in section 3.1. 2770 5.2 requestNonce 2772 The requestNonce item contains a request identifier generated by the 2773 SCVP client. If the server returns a specific response it MUST 2774 include the requestNonce from the request in the response, but the 2775 server MAY return a cached response which MUST NOT include a 2776 requestNonce. 2778 6 Validation Policy Response 2780 In response to a ValPolRequest, the SCVP server provides a 2781 ValPolResponse. The ValPolResponse MAY not be unique to any 2782 ValPolRequest, so may be reused by the server in response to 2783 multiple ValPolRequests. The ValPolResponse also has an indication 2784 of how frequently the ValPolResponse may be reissued. The server 2785 MUST sign the response using its digital signature certificate. 2786 When a ValPolResponse is encapsulated in a MIME body part, it MUST 2787 be carried in an application/vp-response MIME body part. 2789 The response consists of a ValPolResponse encapsulated in a 2790 SignedData, which is in turn encapsulated in a ContentInfo. That 2791 is, the EncapsulatedContentInfo field of SignedData consists of an 2792 eContentType field with a value of id-ct-scvp-valPolResponse 2793 (1.2.840.113549.1.9.16.1.13) and an eContent field that contains a 2794 DER encoded ValPolResponse. The SCVP server MUST include it's own 2795 certificate in the certificates field within SignedData and the 2796 signerInfos field of SignedData MUST include exactly one SignerInfo. 2797 The SignedData MUST NOT include the unsignedAttrs field. 2799 The ValPolResponse type has the following syntax: 2801 ValPolResponse ::= SEQUENCE { 2802 vpResponseVersion INTEGER, 2803 maxCVResponseVersion INTEGER, 2804 maxVPResponseVersion INTEGER, 2805 serverConfigurationID INTEGER, 2806 thisUpdate GeneralizedTime, 2807 nextUpdate GeneralizedTime OPTIONAL, 2808 validationPolicies SEQUENCE OF OBJECT IDENTIFIER, 2809 validationAlgs SEQUENCE OF OBJECT IDENTIFIER, 2810 authPolicies SEQUENCE OF AuthPolicy, 2811 responseTypes ResponseTypes, 2812 defaultPolicyValues RespValidationPolicy, 2813 revocationInfoTypes RevocationInfoTypes, 2814 signatureGeneration SEQUENCE OF AlgorithmIdentifier, 2815 signatureVerification SEQUENCE OF AlgorithmIdentifier, 2816 hashAlgorithms SEQUENCE SIZE (1..MAX) OF 2817 OBJECT IDENTIFIER, 2818 serverPublicKeys SEQUENCE OF KeyAgreePublicKey 2819 OPTIONAL, 2820 clockSkew INTEGER DEFAULT 10, 2821 requestNonce OCTET STRING OPTIONAL } 2823 ResponseTypes ::= ENUMERATED { 2824 cached-only (0), 2825 non-cached-only (1), 2826 cached-and-non-cached (2) } 2828 RevocationInfoTypes ::= BIT STRING { 2829 fullCRLs (0), 2830 deltaCRLs (1), 2831 indirectCRLs (2), 2832 oCSPResponses (3) } 2834 SCVP clients that support validation policy requests MUST support 2835 validation policy responses. SCVP servers MUST support validation 2836 policy responses. 2838 SCVP servers MUST support cached policy responses and MAY support 2839 specific responses to policy requests. 2841 6.1 vpResponseVersion 2843 The syntax and semantics of the vpResponseVersion item are the same 2844 as cvRequestVersion as described in section 3.1. The 2845 vpResponseVersion used MUST be the same as the vpRequestVersion 2846 unless the client has used a value greater than the values the 2847 server supports. If the client submits a vpRequestVersion greater 2848 than the version supported by the server, the server MUST return a 2849 vpResponseVersion using the highest version number the server 2850 supports as the version number. 2852 6.2 maxCVRequestVersion 2854 The maxCVRequestVersion defines the maximum version number for CV 2855 requests that the server supports. 2857 6.3 maxVPRequestVersion 2859 The maxVPRequestVersion defines the maximum version number for VP 2860 requests that the server supports. 2862 6.4 serverConfigurationID 2864 An integer that uniquely represents the version of the server 2865 configuration as represented by the validationPolicies, 2866 validationAlgs, authPolicies, defaultPolicyValues, and clockSkew. 2867 If any of these values change, the server MUST create a new 2868 ValPolResponse with a new serverConfigurationID. If the 2869 configuration has not changed, then the server may reuse 2870 serverConfigurationID across multiple ValPolResponse messages. 2871 However if the server reverts to an earlier configuration, the 2872 server MUST NOT revert the configuration ID as well, but MUST select 2873 another unique value. 2875 6.5 thisUpdate 2877 This item indicates the signing date and time of this policy 2878 response. 2880 GeneralizedTime values MUST be expressed Greenwich Mean Time (Zulu) 2881 and interpreted as defined in section 3.2.7. 2883 6.6 nextUpdate and requestNonce 2885 These items are used to indicate whether policy responses are 2886 specific to policy requests. Where policy responses are cached, 2887 these items indicate when the information will be updated. The 2888 optional nextUpdate item indicates the time by which the next policy 2889 response will be published. The optional requestNonce item links 2890 the response to a specific request by returning the nonce provided 2891 in the request. 2893 If the nextUpdate item is omitted it indicates a non-cached response 2894 generated in response to a specific request (i.e. the ValPolResponse 2895 is bound to a specific request). If this item is omitted the 2896 requestNonce item MUST be present and MUST include the requestNonce 2897 value from the request. 2899 If the nextUpdate item is present it indicates a cached response 2900 that is not bound to a specific request. An SCVP server MUST 2901 periodically generate a new response as defined by the next update 2902 time, but MAY use the same ValPolResponse to respond to multiple 2903 requests. The requestNonce is omitted if the nextUpdate item is 2904 present. 2906 It is a matter of local server policy to return a cached or non- 2907 cached specific response. 2909 GeneralizedTime values in nextUpdate MUST be expressed Greenwich 2910 Mean Time (Zulu) as specified in section 3.2.7. 2912 6.7 validationPolicies 2914 The validationPolicies item contains a sequence of object 2915 identifiers representing the validation policies supported by the 2916 server. It is a matter of local policy if the server wishes to 2917 process requests using the default validation policy, and if it does 2918 not, then it MUST NOT include the id-svp-defaultValPolicy in this 2919 list. 2921 6.8 validationAlgs 2923 The validationAlgs item contains a sequence of OIDs. Each OID 2924 identifies a validation algorithm supported by the server. 2926 6.9 authPolicies 2928 The authPolicies item contains a sequence of policy references for 2929 authenticating to the SCVP server. 2931 The reference to the authentication policy is an OID that the client 2932 and server have agreed represents an authentication policy. The 2933 list of policies is intended to document to the client if 2934 authentication is required for some requests and if so how. 2936 AuthPolicy ::= OBJECT IDENTIFIER 2938 6.10 responseTypes 2940 responseTypes allows the server to publish the range of response 2941 types it supports. Cached only means the server will only return 2942 cached responses to requests. Non-cached only means the server will 2943 return a specific response to the request i.e. containing the 2944 requestor's nonce. Both means the server will return either, 2945 depending on the request. 2947 6.11 revocationInfoTypes 2949 revocationInfoTypes allows the server to indicate the sources of 2950 revocation information that it is capable of processing. For each 2951 bit in the RevocationInfoTypes bit string, the server MUST set the 2952 bit to one if it is capable of processing the corresponding 2953 revocation information type and to zero if it can not. 2955 6.12 defaultPolicyValues 2957 This is the default validation policy used by the server. It 2958 contains a RespValidationPolicy, which is defined in section 4.5. 2959 All OPTIONAL items in the validationPolicy item MUST be populated. 2960 A server will use these default values when the request references 2961 the default validation policy and the client does not override the 2962 default values by supplying other values in the request. 2964 This allows the client to optimize the request by omitting 2965 parameters that match the server default values. 2967 6.13 signatureGeneration 2969 This sequence specifies the set of digital signature algorithms 2970 supported by an SCVP server for signing CVResponse messages. Each 2971 digital signature algorithm is specified as an AlgorithmIdentifier, 2972 using the encoding rules associated with the signatureAlgorithm 2973 field in a public key certificate [PKIX-1]. Supported algorithms 2974 are defined in [PKIX-ALG] and [PKIX-ALG2], but other signature 2975 algorithms may also be supported. 2977 By including an algorithm (e.g., RSA with SHA-1) in this list, the 2978 server states that it has a private key and corresponding certified 2979 public key for that asymmetric algorithm, and supports the specified 2980 hash algorithm. The list is ordered; the first digital signature 2981 algorithm is the server's default algorithm. The default algorithm 2982 will be used by the server to protect signed messages unless the 2983 client specifies another algorithm. 2985 For servers that do not have an online private key, and cannot sign 2986 CVResponse messages, the signatureGeneration item is encoded as an 2987 empty sequence. 2989 6.14 signatureVerification 2991 This sequence specifies the set of digital signature algorithms that 2992 can be verified by this SCVP server. Each digital signature 2993 algorithm is specified as an AlgorithmIdentifier, using the encoding 2994 rules associated with the signatureAlgorithm field in a public key 2995 certificate [PKIX-1]. Supported algorithms are defined in [PKIX- 2996 ALG] and [PKIX-ALG2], but other signature algorithms may also be 2997 supported. 2999 For servers that do not verify signatures on CVRequest messages, the 3000 signatureVerification item is encoded as an empty sequence. 3002 6.15 hashAlgorithms 3004 This sequence specifies the set of hash algorithms that the server 3005 can use to hash certificates and requests. The list is ordered; the 3006 first hash algorithm is the server's default algorithm. The default 3007 algorithm will be used by the server to compute hashes included in 3008 responses unless the client specifies another algorithm. Each hash 3009 algorithm is specified as an object identifier. [PKIX-ALG2] 3010 specifies object identifiers for SHA-1, SHA-224, SHA-256, SHA-384, 3011 and SHA-512. Other hash algorithms may also be supported. 3013 6.16 serverPublicKeys 3015 The serverPublicKeys item is a sequence of one or more key agreement 3016 public keys and associated parameters. It is used by clients making 3017 AuthenticatedData requests to the server. Each item in the 3018 serverPublicKeys sequence is of the KeyAgreePublicKey type: 3020 KeyAgreePublicKey ::= SEQUENCE { 3021 algorithm AlgorithmIdentifier, 3022 publicKey BIT STRING, 3023 macAlgorithm AlgorithmIdentifier, 3024 kDF AlgorithmIdentifier OPTIONAL } 3026 The KeyAgreePublicKey includes the algorithm identifier and the 3027 server's public key. SCVP servers that support the key agreement 3028 mode of AuthenticatedData for SCVP requests MUST support 3029 serverPublicKeys and the Diffie-Hellman key agreement algorithm as 3030 specified in [PKIX-ALG]. SCVP servers that support serverPublicKeys 3031 MUST support the 1024-bit MODP group key (group 2) as defined in 3032 [IKE]. SCVP servers that support serverPublicKeys MAY support other 3033 Diffie-Hellman groups [IKE-GROUPS], as well as other key agreement 3034 algorithms. 3036 The macAlgorithm item specifies the symmetric algorithm the server 3037 expects the client to use with the result of the key agreement 3038 algorithm. A key derivation function (KDF), which derives symmetric 3039 key material from the key agreement result, may be implied by the 3040 macAlgorithm. Alternatively, the KDF may be explicitly specified 3041 using the optional kDF item. 3043 6.17 clockSkew 3044 The clockSkew item is the number of minutes the server will allow 3045 for clock skew. The default value of 10 minutes. 3047 7 SCVP Server Relay 3049 In some network environments, especially ones that include 3050 firewalls, an SCVP server might not be able to obtain all of the 3051 information that it needs to process a request. However, the server 3052 might be configured to use the services of one or more other SCVP 3053 servers to fulfill all requests. In such cases, the SCVP client is 3054 unaware that the initial SCVP server is using the services of other 3055 SCVP servers. The initial SCVP server acts as a client to another 3056 SCVP server. Unlike the original client, the SCVP server is 3057 expected to have moderate computing and memory resources. This 3058 section describes SCVP server-to-SCVP server exchanges. This 3059 section does not impose any requirements on SCVP clients that are 3060 not also SCVP servers. Further, this section does not impose any 3061 requirements on SCVP servers that do not relay requests to other 3062 SCVP servers. 3064 When one SCVP server relays a request to another server, in an 3065 incorrectly configured system of servers, it is possible that the 3066 same request will be relayed back again. Any SCVP server that 3067 relays requests MUST implement the conventions described in this 3068 section to detect and break loops. 3070 When an SCVP server relays a request, the request MUST include the 3071 requestorRef item. If the request to be relayed already contains a 3072 requestorRef item, then the server-generated request MUST contain a 3073 requestorRef item constructed from this value and an additional 3074 GeneralName that contains an identifier of the SCVP server. If the 3075 request to be relayed does not contain a requestorRef item, then the 3076 server-generated request MUST contain a requestorRef item that 3077 includes a GeneralName that contains an identifier of the SCVP 3078 server. 3080 To prevent false loop detection, servers should use identifiers that 3081 are unique within their network of cooperating SCVP servers. SCVP 3082 servers that support relay SHOULD populate this item with the DNS 3083 name of the server or the distinguished name in the server's 3084 certificate. SCVP servers MAY choose other procedures for 3085 generating identifiers that are unique within their community. 3087 When an SVCP server receives a request that contains a requestorRef 3088 item, the server MUST check the sequence of names in the 3089 requestorRef item for its own identifier. If the server discovers 3090 its own identifier in the requestor item, it MUST respond with an 3091 error, setting the cvResponseStatus to 40. 3093 When an SCVP server generates a non-cached response to a relayed 3094 request, the server MUST include the requestorRef item from the 3095 request in the response. 3097 8 SCVP ASN.1 Module 3099 This section defines the syntax for SCVP request-response pairs. 3100 The semantics for the messages are defined in sections 3, 4, 5, and 3101 6. The SCVP ASN.1 module follows. 3103 SCVP 3105 { iso(1) identified-organization(3) dod(6) internet(1) 3106 security(5) mechanisms(5) pkix(7) id-mod(0) 21 } 3108 DEFINITIONS IMPLICIT TAGS ::= BEGIN 3110 IMPORTS 3112 AlgorithmIdentifier, Attribute, Certificate, Extensions, 3113 -- Import UTF8String if required by compiler 3114 -- UTF8String, -- CertificateList, CertificateSerialNumber 3115 FROM PKIX1Explicit88 -- RFC 3280 3116 { iso(1) identified-organization(3) dod(6) internet(1) 3117 security(5) mechanisms(5) pkix(7) id-mod(0) 18 } 3119 GeneralNames, GeneralName, KeyUsage, KeyPurposeId 3120 FROM PKIX1Implicit88 -- RFC 3280 3121 { iso(1) identified-organization(3) dod(6) internet(1) 3122 security(5) mechanisms(5) pkix(7) id-mod(0) 19 } 3124 AttributeCertificate 3125 FROM PKIXAttributeCertificate -- RFC 3281 3126 { iso(1) identified-organization(3) dod(6) internet(1) 3127 security(5) mechanisms(5) pkix(7) id-mod(0) 12 } 3129 OCSPResponse 3130 FROM OCSP -- RFC 2560 3131 { iso(1) identified-organization(3) dod(6) internet(1) 3132 security(5) mechanisms(5) pkix(7) id-mod(0) 14 } 3134 ContentInfo 3135 FROM CryptographicMessageSyntax -- RFC 3369 3136 { iso(1) member-body(2) us(840) rsadsi(113549) 3137 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) } ; 3139 -- SCVP Certificate Validation Request 3140 id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3141 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3142 id-smime(16) 1 } 3144 id-ct-scvp-certValRequest OBJECT IDENTIFIER ::= { id-ct 10 } 3146 CVRequest ::= SEQUENCE { 3147 cvRequestVersion INTEGER DEFAULT 1, 3148 query Query, 3149 requestorRef [0] GeneralNames OPTIONAL, 3150 requestNonce [1] OCTET STRING OPTIONAL, 3151 requestorName [2] GeneralName OPTIONAL, 3152 responderName [3] GeneralName OPTIONAL, 3153 reqestExtensions [4] Extensions OPTIONAL, 3154 signatureAlg [5] AlgorithmIdentifier OPTIONAL, 3155 hashAlg [6] OBJECT IDENTIFIER OPTIONAL, 3156 requestorText [7] UTF8String (SIZE (1..256)) OPTIONAL } 3158 Query ::= SEQUENCE { 3159 queriedCerts CertReferences, 3160 checks CertChecks, 3161 wantBack [1] WantBack OPTIONAL, 3162 validationPolicy ValidationPolicy, 3163 responseFlags ResponseFlags OPTIONAL, 3164 serverContextInfo [2] OCTET STRING OPTIONAL, 3165 validationTime [3] GeneralizedTime OPTIONAL, 3166 intermediateCerts [4] CertBundle OPTIONAL, 3167 revInfos [5] RevocationInfos OPTIONAL, 3168 producedAt [6] GeneralizedTime OPTIONAL, 3169 queryExtensions [7] Extensions OPTIONAL } 3171 CertReferences ::= CHOICE { 3172 pkcRefs [0] SEQUENCE SIZE (1..MAX) OF PKCReference, 3173 acRefs [1] SEQUENCE SIZE (1..MAX) OF ACReference } 3175 CertReference::= CHOICE { 3176 pkc PKCReference, 3177 ac ACReference } 3179 PKCReference ::= CHOICE { 3180 cert [0] Certificate, 3181 pkcRef [1] CertID } 3183 ACReference ::= CHOICE { 3184 attrCert [2] AttributeCertificate, 3185 acRef [3] CertID } 3187 CertID ::= SEQUENCE { 3188 certHash OCTET STRING, 3189 issuerSerial IssuerSerial, 3190 hashAlgorithm AlgorithmIdentifier DEFAULT { sha-1 } } 3192 IssuerSerial ::= SEQUENCE { 3193 issuer GeneralNames, 3194 serialNumber CertificateSerialNumber 3195 } 3197 ValidationPolicy ::= SEQUENCE { 3198 validationPolRef ValidationPolRef, 3199 validationAlg [0] ValidationAlg OPTIONAL, 3200 userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT 3201 IDENTIFIER OPTIONAL, 3202 inhibitPolicyMapping [2] BOOLEAN OPTIONAL, 3203 requireExplicitPolicy [3] BOOLEAN OPTIONAL, 3204 inhibitAnyPolicy [4] BOOLEAN OPTIONAL, 3205 trustAnchors [5] TrustAnchors OPTIONAL, 3206 keyUsages [6] SEQUENCE OF KeyUsage OPTIONAL, 3207 extendedKeyUsages [7] SEQUENCE OF KeyPurposeId OPTIONAL } 3209 CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 3211 WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 3213 ValidationPolRef ::= SEQUENCE { 3214 valPolId OBJECT IDENTIFIER, 3215 valPolParams ANY DEFINED BY valPolId OPTIONAL } 3217 ValidationAlg ::= SEQUENCE { 3218 valAlgId OBJECT IDENTIFIER, 3219 parameters ANY DEFINED BY valAlgId OPTIONAL } 3221 NameValidationAlgParms ::= SEQUENCE { 3222 nameCompAlgId OBJECT IDENTIFIER, 3223 validationNames GeneralNames } 3225 TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF PKCReference 3227 KeyAgreePublicKey ::= SEQUENCE { 3228 algorithm AlgorithmIdentifier, 3229 publicKey BIT STRING, 3230 macAlgorithm AlgorithmIdentifier, 3231 kDF AlgorithmIdentifier OPTIONAL } 3233 ResponseFlags ::= SEQUENCE { 3234 fullRequestInResponse [0] BOOLEAN DEFAULT FALSE, 3235 responseValidationPolByRef [1] BOOLEAN DEFAULT TRUE, 3236 protectResponse [2] BOOLEAN DEFAULT TRUE, 3237 cachedResponse [3] BOOLEAN DEFAULT TRUE } 3239 CertBundle ::= SEQUENCE SIZE (1..MAX) OF Certificate 3241 RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo 3243 RevocationInfo ::= CHOICE { 3244 crl [0] CertificateList, 3245 delta-crl [1] CertificateList, 3246 ocsp [2] OCSPResponse, 3247 other [3] OtherRevInfo } 3249 OtherRevInfo ::= SEQUENCE { 3250 riType OBJECT IDENTIFIER, 3251 riValue ANY DEFINED BY riType } 3253 -- SCVP Certificate Validation Response 3255 id-ct-scvp-certValResponse OBJECT IDENTIFIER ::= { id-ct 11 } 3257 CVResponse ::= SEQUENCE { 3258 cvResponseVersion INTEGER, 3259 serverConfigurationID INTEGER, 3260 producedAt GeneralizedTime, 3261 responseStatus ResponseStatus, 3262 respValidationPolicy [0] RespValidationPolicy OPTIONAL, 3263 requestRef [1] RequestReference OPTIONAL, 3264 requestorRef [2] GeneralNames OPTIONAL, 3265 requestorName [3] GeneralNames OPTIONAL, 3266 replyObjects [4] ReplyObjects OPTIONAL, 3267 respNonce [5] OCTET STRING OPTIONAL, 3268 serverContextInfo [6] OCTET STRING OPTIONAL, 3269 cvResponseExtensions [7] Extensions OPTIONAL, 3270 requestorText [8] UTF8String (SIZE (1..256)) OPTIONAL } 3272 ResponseStatus ::= SEQUENCE { 3273 statusCode CVStatusCode DEFAULT okay, 3274 errorMessage UTF8String OPTIONAL } 3276 CVStatusCode ::= ENUMERATED { 3277 okay (0), 3278 skipUnrecognizedItems (1), 3279 tooBusy (10), 3280 invalidRequest (11), 3281 internalError (12), 3282 badStructure (20), 3283 unsupportedVersion (21), 3284 abortUnrecognizedItems (22), 3285 unrecognizedSigKey (23), 3286 badSignatureOrMAC (24), 3287 unableToDecode (25), 3288 notAuthorized (26), 3289 unsupportedChecks (27), 3290 unsupportedWantBacks (28), 3291 unsupportedSignatureOrMAC (29), 3292 invalidSignatureOrMAC (30), 3293 protectedResponseUnsupported (31), 3294 unrecognizedResponderName (32), 3295 relayingLoop (40), 3296 unrecognizedValPol (50), 3297 unrecognizedValAlg (51), 3298 fullRequestInResponseUnsupported (52), 3299 fullPolResponseUnsupported (53), 3300 inhibitPolicyMappingUnsuported (54), 3301 requireExplicitPolicyUnsupported (55), 3302 inhibitAnyPolicyUnsupported (56), 3303 validityTimeUnsupported (57), 3304 unrecognizedCritQueryExt (63), 3305 unrecognizedCritRequestExt (64) } 3307 RespValidationPolicy ::= ValidationPolicy 3309 RequestReference ::= CHOICE { 3310 requestHash [0] HashValue, -- hash of CVRequest 3311 fullRequest [1] CVRequest } 3313 HashValue ::= SEQUENCE { 3314 algorithm AlgorithmIdentifier DEFAULT { sha-1 }, 3315 value OCTET STRING } 3317 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3318 oiw(14) secsig(3) algorithm(2) 26 } 3320 ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply 3322 CertReply ::= SEQUENCE { 3323 cert CertReference, 3324 replyStatus ReplyStatus DEFAULT success, 3325 replyValTime GeneralizedTime, 3326 replyChecks ReplyChecks, 3327 replyWantBacks ReplyWantBacks, 3328 validationErrors [0] SEQUENCE SIZE (1..MAX) OF 3329 OBJECT IDENTIFIER OPTIONAL, 3330 nextUpdate [1] GeneralizedTime OPTIONAL, 3331 certReplyExtensions [2] Extensions OPTIONAL } 3333 ReplyStatus ::= ENUMERATED { 3334 success (0), 3335 malformedPKC (1), 3336 malformedAC (2), 3337 unavailableValidityTime (3), 3338 referenceCertHashFail (4), 3339 certPathConstructFail (5), 3340 certPathNotValid (6), 3341 certPathNotValidNow (7), 3342 wantBackUnsatisfied (8) } 3344 ReplyChecks ::= SEQUENCE OF ReplyCheck 3346 ReplyCheck ::= SEQUENCE { 3347 check OBJECT IDENTIFIER, 3348 status INTEGER DEFAULT 0 } 3350 ReplyWantBacks ::= SEQUENCE OF ReplyWantBack 3352 ReplyWantBack::= SEQUENCE { 3353 wb OBJECT IDENTIFIER, 3354 value OCTET STRING } 3356 CertBundles ::= SEQUENCE SIZE (1..MAX) OF CertBundle 3358 RevInfoWantBack ::= SEQUENCE { 3359 revocationInfo RevocationInfos, 3360 extraCerts CertBundle OPTIONAL } 3362 SCVPResponses ::= SEQUENCE OF ContentInfo 3364 -- SCVP Validation Policies Request 3366 id-ct-scvp-valPolRequest OBJECT IDENTIFIER ::= { id-ct 12 } 3368 ValPolRequest ::= SEQUENCE { 3369 vpRequestVersion INTEGER DEFAULT 1, 3370 requestNonce OCTET STRING } 3372 -- SCVP Validation Policies Response 3374 id-ct-scvp-valPolResponse OBJECT IDENTIFIER ::= { id-ct 13 } 3376 ValPolResponse ::= SEQUENCE { 3377 vpResponseVersion INTEGER, 3378 maxCVResponseVersion INTEGER, 3379 maxVPResponseVersion INTEGER, 3380 serverConfigurationID INTEGER, 3381 thisUpdate GeneralizedTime, 3382 nextUpdate GeneralizedTime OPTIONAL, 3383 validationPolices SEQUENCE OF OBJECT IDENTIFIER, 3384 validationAlgs SEQUENCE OF OBJECT IDENTIFIER, 3385 authPolicies SEQUENCE OF AuthPolicy, 3386 responseTypes ResponseTypes, 3387 defaultPolicyValues RespValidationPolicy, 3388 revocationInfoTypes RevocationInfoTypes, 3389 signatureGeneration SEQUENCE OF AlgorithmIdentifier, 3390 signatureVerification SEQUENCE OF AlgorithmIdentifier, 3391 hashAlgorithms SEQUENCE SIZE (1..MAX) OF 3392 OBJECT IDENTIFIER, 3393 serverPublicKeys SEQUENCE OF KeyAgreePublicKey 3394 OPTIONAL, 3395 clockSkew INTEGER DEFAULT 10, 3396 requestNonce OCTET STRING OPTIONAL } 3398 ResponseTypes ::= ENUMERATED { 3399 cached-only (0), 3400 non-cached-only (1), 3401 cached-and-non-cached (2) } 3403 RevocationInfoTypes ::= BIT STRING { 3404 fullCRLs (0), 3405 deltaCRLs (1), 3406 indirectCRLs (2), 3407 oCSPResponses (3) } 3409 AuthPolicy ::= OBJECT IDENTIFIER 3411 -- SCVP Check Identifiers 3413 id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3414 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 } 3416 id-stc-build-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 } 3417 id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 2 } 3418 id-stc-build-status-checked-pkc-path 3419 OBJECT IDENTIFIER ::= { id-stc 3 } 3420 id-stc-build-aa-path OBJECT IDENTIFIER ::= { id-stc 4 } 3421 id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 5 } 3422 id-stc-build-status-checked-aa-path 3423 OBJECT IDENTIFIER ::= { id-stc 6 } 3424 id-stc-status-check-ac-and-build-status-checked-aa-path 3425 OBJECT IDENTIFIER ::= { id-stc 7 } 3427 -- SCVP WantBack Identifiers 3429 id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3430 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 } 3432 id-swb-pkc-best-cert-path OBJECT IDENTIFIER ::= { id-swb 1 } 3433 id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 } 3434 id-swb-pkc-public-key-info OBJECT IDENTIFIER ::= { id-swb 4 } 3435 id-swb-aa-cert-path OBJECT IDENTIFIER ::= { id-swb 5 } 3436 id-swb-aa-revocation-info OBJECT IDENTIFIER ::= { id-swb 6 } 3437 id-swb-ac-revocation-info OBJECT IDENTIFIER ::= { id-swb 7 } 3438 id-swb-relayed-responses OBJECT IDENTIFIER ::= { id-swb 9 } 3439 id-swb-pkc-cert OBJECT IDENTIFIER ::= { id-swb 10} 3440 id-swb-ac-cert OBJECT IDENTIFIER ::= { id-swb 11} 3441 id-swb-pkc-all-cert-paths OBJECT IDENTIFIER ::= { id-swb 12} 3442 id-swb-pkc-ee-revocation-info OBJECT IDENTIFIER ::= { id-swb 13} 3443 id-swb-pkc-CAs-revocation-info OBJECT IDENTIFIER ::= { id-swb 14} 3445 -- SCVP Validation Policy and Algorithm Identifiers 3447 id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3448 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 } 3450 id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 } 3452 -- SCVP Basic Validation Algorithm Identifier 3454 id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 } 3456 -- SCVP Basic Validation Algorithm Errors 3458 id-bvae OBJECT IDENTIFIER ::= id-svp-basicValAlg 3460 id-bvae-expired OBJECT IDENTIFIER ::= { id-bvae 1 } 3461 id-bvae-not-yet-valid OBJECT IDENTIFIER ::= { id-bvae 2 } 3462 id-bvae-wrongTrustAnchor OBJECT IDENTIFIER ::= { id-bvae 3 } 3463 id-bvae-noValidCertPath OBJECT IDENTIFIER ::= { id-bvae 4 } 3464 id-bvae-revoked OBJECT IDENTIFIER ::= { id-bvae 5 } 3465 id-bvae-invalidKeyPurpose OBJECT IDENTIFIER ::= { id-bvae 9 } 3466 id-bvae-invalidKeyUsage OBJECT IDENTIFIER ::= { id-bvae 10 } 3467 id-bvae-invalidCertPolicy OBJECT IDENTIFIER ::= { id-bvae 11 } 3469 -- SCVP Name Validation Algorithm Identifier 3471 id-svp-nameValAlg OBJECT IDENTIFIER ::= { id-svp 2 } 3473 -- SCVP Name Validation Algorithm DN comparison algorithm 3475 id-nva-dnCompAlg OBJECT IDENTIFIER ::= { id-svp 4 } 3477 -- SCVP Name Validation Algorithm Errors 3479 id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg 3480 id-nvae-name-mismatch OBJECT IDENTIFIER ::= { id-nvae 1 } 3481 id-nvae-no-name OBJECT IDENTIFIER ::= { id-nvae 2 } 3482 id-nvae-unknown-alg OBJECT IDENTIFIER ::= { id-nvae 3 } 3483 id-nvae-bad-name OBJECT IDENTIFIER ::= { id-nvae 4 } 3484 id-nvae-bad-name-type OBJECT IDENTIFIER ::= { id-nvae 5 } 3485 id-nvae-mixed-names OBJECT IDENTIFIER ::= { id-nvae 6 } 3487 -- SCVP Extended Key Usage Key Purpose Identifiers 3489 id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3490 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } 3492 id-kp-scvpServer OBJECT IDENTIFIER ::= { id-kp 15 } 3494 id-kp-scvpClient OBJECT IDENTIFIER ::= { id-kp 16 } 3496 END 3498 9 Security Considerations 3500 For security considerations specific to the Cryptographic Message 3501 Syntax message formats, see [CMS]. For security considerations 3502 specific to the process of PKI certificate path validation, see 3503 [PKIX-1]. 3505 A client that trusts a server's response for validation of a 3506 certificate inherently trusts that server as much as it would trust 3507 its own validation software. This means that if an attacker 3508 compromises a trusted SCVP server, the attacker can change the 3509 validation processing for every client that relies on that server. 3510 Thus, an SCVP server must be protected at least as well as the trust 3511 anchors that the SCVP server trusts. 3513 Clients MUST verify that the response matches their original 3514 request. Clients need to ensure that the server has performed the 3515 appropriate checks for the correct certificates under the requested 3516 validation policy for the specified validation time, and that the 3517 response includes the requested want backs and meets the client's 3518 freshness requirements. 3520 When the SCVP response is used to determine the validity of a 3521 certificate, the client MUST validate the digital signature or MAC 3522 on the response to ensure that the expected SCVP server generated 3523 it. If the client does not check the digital signature or MAC on 3524 the response, a man-in-the-middle attack could fool the client into 3525 believing modified responses from the server, or responses to 3526 questions the client did not ask. 3528 If the client does not include a requestNonce item, or if the client 3529 does not check that the requestNonce in the response matches the 3530 value in the request, an attacker can replay previous responses from 3531 the SCVP server. 3533 If the server does not require some sort of authorization (such as 3534 signed requests), an attacker can get the server to respond to 3535 arbitrary requests. Such responses may give the attacker 3536 information about weaknesses in the server or about the timeliness 3537 of the server's checking. This information may be valuable for a 3538 future attack. 3540 If the server uses the serverContextInfo item to indicate some 3541 server state associated with a requestor, implementers must take 3542 appropriate measures against denial of service attacks where an 3543 attacker sends in a lot of requests at one time to force the server 3544 to keep a lot of state information. 3546 SCVP does not include any confidentiality mechanisms. If 3547 confidentiality is needed, it can be achieved with a lower-layer 3548 security protocol. 3550 If an SCVP client is not operating on a network with good physical 3551 protection, it must ensure that there is integrity over the SCVP 3552 request-response pair. The client can ensure integrity by using a 3553 protected transport such as TLS. It can ensure integrity by using 3554 MACs or digital signatures to individually protect the request and 3555 response messages. 3557 If an SCVP client populates the userPolicySet in a request with a 3558 value other than anyPolicy, but does not set the 3559 requireExplicitPolicy flag, the server may return an affirmative 3560 answer for paths that do not satisfy any of the specified policies. 3561 In general, when a client populates the userPolicySet in a request 3562 with a value other than anyPolicy, the requireExplicitPolicy flag 3563 should also be set. This guarantees that all valid paths satisfy at 3564 least one of the requested policies. 3566 In SCVP, historical validation of a certificate returns the known 3567 status of the certificate at the time specified in validationTime. 3568 This may be used to demonstrate due diligence, but does not 3569 necessarily provide the most complete information. A certificate 3570 may have been revoked after the time specified in validationTime, 3571 but the revocation notice may specify an invalidity date that 3572 precedes the validationTime. The SCVP server would provide an 3573 affirmative response even though the most current information 3574 available indicates the certificate should not be trusted at that 3575 time. SCVP clients may wish to specify a validationTime later than 3576 the actual time of interest to mitigate this risk. 3578 10 References 3580 Normative and informative references are provided. 3582 10.1 Normative References 3584 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 3585 Requirement Levels", BCP 14, RFC 2119, March 1997. 3586 http://www.ietf.org/rfc/rfc2119.txt 3588 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 3369,August 3589 2002. 3590 http://www.ietf.org/rfc/rfc3369.txt 3592 [OCSP] Myers, M., R. Ankney, A. Malpani, S. Galperin and C. 3593 Adams, "X.509 Internet Public Key Infrastructure - Online 3594 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 3595 http://www.ietf.org/rfc/rfc2560.txt 3597 [PKIX-1] Housley, R., T. Polk, W. Ford and D. Solo, "Internet 3598 X.509 Public Key Infrastructure Certificate and 3599 Certificate Revocation List (CRL) Profile", RFC 3280, 3600 April 2002. 3601 http://www.ietf.org/rfc/rfc3280.txt 3603 [PKIX-AC] Farrell, S. and R. Housley, "An Internet Attribute 3604 Certificate Profile for Authorization", RFC 3281, April 3605 2002. 3606 http://www.ietf.org/rfc/rfc3281.txt 3608 [PKIX-ALG] Polk, W., R. Housley and L. Bassham, "Algorithms and 3609 Identifiers for the Internet X.509 Public Key 3610 Infrastructure Certificate and Certificate Revocation 3611 List (CRL) Profile", RFC 3279, April 2002. 3612 http://www.ietf.org/rfc/rfc3279.txt 3614 [PKIX-ALG2] Schaad, J., B. Kaliski and R. Housley, "Additional 3615 Algorithms and Identifiers for RSA Cryptography for use 3616 in the Internet X.509 Public Key Infrastructure 3617 Certificate and Certificate Revocation List (CRL) 3618 Profile", RFC 4055, June 2005. 3619 http://www.ietf.org/rfc/rfc4055.txt 3621 [SHA] National Institute of Standards and Technology, "Secure 3622 Hash Standard", NIST FIPS Pub 180-2, August 2002. 3624 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 3625 10646", RFC 2279, January 1998. 3626 http://www.ietf.org/rfc/rfc2279.txt 3628 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 3629 2634, June 1999. 3630 http://www.ietf.org/rfc/rfc2634.txt 3632 [HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC2818, May 2000. 3633 http://www.ietf.org/rfc/rfc2818.txt 3635 [SMIME-CERT] B. Ramsdell, Ed. "Secure/Multipurpose Internet Mail 3636 Extensions (S/MIME) Version 3.1 Certificate Handling" 3637 RFC3850, July 2004. 3638 http://www.ietf.org/rfc/rfc3850.txt 3640 [IKE] Harkins, D. and D. Carrel. "The Internet Key Exchange 3641 (IKE)", RFC2409, November 1998. 3642 http://www.ietf.org/rfc/rfc2409.txt 3644 10.2 Informative References 3646 [HTTP] Fielding, R., J. Gettys, J. Mogul, H. Frystyk, L. 3647 Masinter, P. Leach and T. Berners-Lee, "Hypertext 3648 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3649 http://www.ietf.org/rfc/rfc2616.txt 3651 [IKE-GROUPS] Kivinen, T. and M. Kojo "More Modular Exponential (MODP) 3652 Diffie-Hellman groups for Internet Key Exchange (IKE)", 3653 RFC3526, May 2003. 3654 http://www.ietf.org/rfc/rfc3526.txt 3656 [RQMTS] Pinkas, D. and R. Housley, "Delegated Path Validation and 3657 Delegated Path Discovery Protocol Requirements", RFC 3658 3379, September 2002. 3659 http://www.ietf.org/rfc/rfc3379.txt 3661 11 Intellectual Property Rights 3663 The IETF takes no position regarding the validity or scope of any 3664 Intellectual Property Rights or other rights that might be claimed 3665 to pertain to the implementation or use of the technology described 3666 in this document or the extent to which any license under such 3667 rights might or might not be available; nor does it represent that 3668 it has made any independent effort to identify any such rights. 3669 Information on the procedures with respect to rights in RFC 3670 documents can be found in BCP 78 and BCP 79. 3672 Copies of IPR disclosures made to the IETF Secretariat and any 3673 assurances of licenses to be made available, or the result of an 3674 attempt made to obtain a general license or permission for the use 3675 of such proprietary rights by implementers or users of this 3676 specification can be obtained from the IETF on-line IPR repository 3677 at http://www.ietf.org/ipr. 3679 The IETF invites any interested party to bring to its attention any 3680 copyrights, patents or patent applications, or other proprietary 3681 rights that may cover technology that may be required to implement 3682 this standard. Please address the information to the IETF at ietf- 3683 ipr@ietf.org. 3685 12 Acknowledgments 3687 The lively debate in the PKIX Working Group has made a significant 3688 impact on this protocol. Special thanks to the following for their 3689 contributions to this standard and diligence in greatly improving 3690 this document. 3692 Paul Hoffman 3693 Phillip Hallam-Baker 3694 Mike Myers 3695 Frank Balluffi 3696 Ameya Talwalkar 3697 John Thielens 3698 Peter Sylvester 3699 Yuriy Dzambasow 3700 Sean P. Turner 3701 Wen-Cheng Wang 3702 Francis Dupont 3703 Dave Engberg 3704 Faisal Maqsood 3706 Thanks also to working group chair Steve Kent for his support and 3707 help. 3709 Appendix A -- MIME Registrations 3711 Four MIME type registrations are provided in this appendix. 3713 A.1 application/cv-request 3715 To: ietf-types@iana.org 3716 Subject: Registration of MIME media type application/cv-request 3718 MIME media type name: application 3719 MIME subtype name: cv-request 3721 Required parameters: format 3723 Optional parameters: None 3725 Encoding considerations: binary 3727 Security considerations: Carries a request for information. This 3728 request may optionally be cryptographically protected. 3730 Interoperability considerations: None 3732 Published specification: IETF PKIX Working Group Draft on Standard 3733 Certificate Validation Protocol (SCVP) 3735 Applications that use this media type: SCVP clients 3737 Additional information: 3738 Magic number(s): None 3739 File extension(s): .SCQ 3740 Macintosh File Type Code(s): none 3742 Person & email address to contact for further information: 3743 Ambarish Malpani 3745 Intended usage: COMMON 3747 Author/Change controller: 3748 Ambarish Malpani 3750 A.2 application/cv-response 3752 To: ietf-types@iana.org 3753 Subject: Registration of MIME media type application/cv-response 3755 MIME media type name: application 3757 MIME subtype name: cv-response 3759 Required parameters: format 3761 Optional parameters: None 3763 Encoding considerations: binary 3765 Security considerations: The client may require that this response 3766 be cryptographically protected, or may choose to use secure 3767 transport mechanism. DPD responses may be unprotected, but the 3768 client validates the information provided in the request. 3770 Interoperability considerations: None 3772 Published specification: IETF PKIX Working Group Draft on Standard 3773 Certificate Validation Protocol (SCVP) 3775 Applications that use this media type: SCVP servers 3777 Additional information: 3779 Magic number(s): None 3780 File extension(s): .SCS 3781 Macintosh File Type Code(s): none 3783 Person & email address to contact for further information: 3784 Ambarish Malpani 3786 Intended usage: COMMON 3788 Author/Change controller: Ambarish Malpani 3790 A.3 application/vp-request 3792 To: ietf-types@iana.org 3793 Subject: Registration of MIME media type application/vp-request 3795 MIME media type name: application 3797 MIME subtype name: vp-request 3799 Required parameters: format 3801 Optional parameters: None 3803 Encoding considerations: binary 3805 Security considerations: Carries a request for information. 3807 Interoperability considerations: None 3809 Published specification: IETF PKIX Working Group Draft on Standard 3810 Certificate Validation Protocol (SCVP) 3812 Applications that use this media type: SCVP clients 3814 Additional information: 3816 Magic number(s): None 3817 File extension(s): .SPQ 3818 Macintosh File Type Code(s): none 3820 Person & email address to contact for further information: 3821 Ambarish Malpani 3823 Intended usage: COMMON 3825 Author/Change controller: Ambarish Malpani 3827 A.4 application/vp-response 3829 To: ietf-types@iana.org 3830 Subject: Registration of MIME media type application/vp-response 3832 MIME media type name: application 3834 MIME subtype name: vp-response 3836 Required parameters: format 3838 Optional parameters: None 3840 Encoding considerations: Binary 3842 Security considerations: None 3844 Interoperability considerations: None 3846 Published specification: IETF PKIX Working Group Draft on Standard 3847 Certificate Validation Protocol (SCVP) 3849 Applications that use this media type: SCVP servers 3851 Additional information: 3852 Magic number(s): None 3853 File extension(s): .SPP 3854 Macintosh File Type Code(s): none 3856 Person & email address to contact for further information: 3857 Ambarish Malpani 3859 Intended usage: COMMON 3861 Author/Change controller: 3862 Ambarish Malpani 3864 Appendix B -- SCVP over HTTP 3865 This appendix describes the formatting conventions for the SCVP 3866 request and response when carried by HTTP. 3868 B.1 SCVP Request 3870 HTTP based SCVP requests can use the POST method to submit their 3871 requests. Where privacy is a requirement, SCVP transactions 3872 exchanged using HTTP MAY be protected using either TLS/SSL or some 3873 other lower layer protocol. 3875 An SCVP request using the POST method is constructed as follows: 3877 The Content-Type header MUST have the value "application/cv- 3878 request". 3880 The Content-Length header MUST be present and have the exact 3881 length of the request. 3883 The body of the message is the binary value of the DER encoding 3884 of the CVRequest, wrapped in a CMS body as described in 3885 Section 3. Other HTTP headers MAY be present and MAY be 3886 ignored if not understood by the requestor. 3888 Sample Content-Type headers are: 3889 Content-Type: application/cv- request 3891 B.2 SCVP Response 3893 An HTTP-based SCVP response is composed of the appropriate HTTP 3894 headers, followed by the binary value of the BER encoding of the 3895 CVResponse, wrapped in a CMS body as described in Section 4. 3897 The Content-Type header MUST have the value "application/cv- 3898 response". 3900 The Content-Length header MUST be present and specify the length of 3901 the response. 3903 Other HTTP headers MAY be present and MAY be ignored if not 3904 understood by the requestor. 3906 B.3 SCVP Policy Request 3908 HTTP based SCVP policy requests can use the POST method to submit 3909 their requests. Where privacy is a requirement, SCVP transactions 3910 exchanged using HTTP MAY be protected using either TLS/SSL or some 3911 other lower layer protocol. 3913 An SCVP request using the POST method is constructed as follows: 3915 The Content-Type header MUST have the value "application/vp- 3916 request". 3918 The Content-Length header MUST be present and have the exact 3919 length of the request. 3921 The body of the message is the binary value of the BER encoding 3922 of the ValPolRequest, wrapped in a CMS body as described in 3923 Section 5. Other HTTP headers MAY be present and 3924 MAY be ignored if not understood by the requestor. 3926 Sample Content-Type headers are: 3927 Content-Type: application/vp-request 3929 B.4 SCVP Policy Response 3931 An HTTP-based SCVP policy response is composed of the appropriate 3932 HTTP headers, followed by the binary value of the DER encoding of 3933 the ValPolResponse, wrapped in a CMS body as described in Section 6. 3935 The Content-Type header MUST have the value "application/vp- 3936 response". 3938 The Content-Length header MUST be present and specify the length of 3939 the response. 3941 Other HTTP headers MAY be present and MAY be ignored if not 3942 understood by the requestor. 3944 Appendix C -- Authors' Addresses 3946 Trevor Freeman 3947 Microsoft Corporation, 3948 One Microsoft way. 3949 Redmond, WA 98052 3950 USA. 3951 trevorf@microsoft.com 3953 Russell Housley 3954 Vigil Security, LLC 3955 918 Spring Knoll Drive 3956 Herndon, VA 20170 3957 USA 3958 housley@Vigilsec.com 3960 Ambarish Malpani 3961 Malpani Consulting Services 3962 ambarish@malpani.biz 3964 David Cooper 3965 National Institute of Standards and Technology 3966 100 Bureau Drive, Mail Stop 8930 3967 Gaithersburg, MD 20899-8930 3968 david.cooper@nist.gov 3970 Tim Polk 3971 National Institute of Standards and Technology 3972 100 Bureau Drive, Mail Stop 8930 3973 Gaithersburg, MD 20899-8930 3974 tim.polk@nist.gov 3976 Full Copyright Statement 3978 Copyright (C) The Internet Society (2006). This document is subject 3979 to the rights, licenses and restrictions contained in BCP 78, and 3980 except as set forth therein, the authors retain all their rights. 3982 This document and the information contained herein are provided on 3983 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 3984 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 3985 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 3986 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3987 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3988 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3990 This document and translations of it may be copied and furnished to 3991 others, and derivative works that comment on or otherwise explain it 3992 or assist in its implementation may be prepared, copied, published 3993 and distributed, in whole or in part, without restriction of any 3994 kind, provided that the above copyright notice and this paragraph 3995 are included on all such copies and derivative works. In addition, 3996 the ASN.1 modules presented may be used in whole or in part without 3997 inclusion of the copyright notice. However, this document itself 3998 may not be modified in any way, such as by removing the copyright 3999 notice or references to the Internet Society or other Internet 4000 organizations, except as needed for the purpose of developing 4001 Internet standards in which case the procedures for copyrights 4002 defined in the Internet Standards process shall be followed, or as 4003 required to translate it into languages other than English.