idnits 2.17.1 draft-ietf-pkix-scvp-25.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 4001. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3683. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3690. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3696. ** 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 : ---------------------------------------------------------------------------- == 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 3332 -- Looks like a reference, but probably isn't: '1' on line 3334 -- Looks like a reference, but probably isn't: '2' on line 3335 -- Looks like a reference, but probably isn't: '3' on line 3269 -- Looks like a reference, but probably isn't: '4' on line 3270 -- Looks like a reference, but probably isn't: '5' on line 3271 -- Looks like a reference, but probably isn't: '6' on line 3272 -- Looks like a reference, but probably isn't: '7' on line 3273 -- Looks like a reference, but probably isn't: '8' on line 3274 == Unused Reference: 'SHA' is defined on line 3634, 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: 12 errors (**), 0 flaws (~~), 4 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-25.txt Microsoft Corp 4 May 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 Server-based Certificate Validation Protocol (SCVP) 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 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 Terminology . . . . . . . . . . . . . . . . . . . . . . 5 56 1.2 SCVP overview . . . . . . . . . . . . . . . . . . . . . 5 57 1.3 SCVP Requirements . . . . . . . . . . . . . . . . . . . 6 58 1.4 Validation Policies . . . . . . . . . . . . . . . . . . 7 59 1.5 Validation Algorithm . . . . . . . . . . . . . . . . . . 8 60 1.6 Validation Requirements . . . . . . . . . . . . . . . . 8 61 2 Protocol Overview . . . . . . . . . . . . . . . . . . . . . 9 62 3 Validation Request . . . . . . . . . . . . . . . . . . . . . 9 63 3.1 cvRequestVersion . . . . . . . . . . . . . . . . . . . . 12 64 3.2 query . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 3.2.1 queriedCerts . . . . . . . . . . . . . . . . . . . . . 13 66 3.2.2 checks . . . . . . . . . . . . . . . . . . . . . . . . 15 67 3.2.3 wantBack . . . . . . . . . . . . . . . . . . . . . . . 16 68 3.2.4 validationPolicy . . . . . . . . . . . . . . . . . . . 19 69 3.2.4.1 validationPolRef . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . . . . . 27 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 . . . . . . . . . . . . . . . . . . . 34 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 . . . . . . . . . . . . . . . . . . . . . 36 101 3.7 requestExtensions . . . . . . . . . . . . . . . . . . . 36 102 3.7.1 extnID . . . . . . . . . . . . . . . . . . . . . . . . 36 103 3.7.2 critical . . . . . . . . . . . . . . . . . . . . . . . 36 104 3.7.3 extnValue . . . . . . . . . . . . . . . . . . . . . . 37 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 . . . . . . . . . . . . . . . . . 42 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 . . . . . . . . . . . . . . . . . . . . . . . . . 48 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 . . . . . . . . . . . . . . . . . . . . . . . 55 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 . . . . . . . . . . . . . . . . . . . . . . . 64 157 7 SCVP Server Relay . . . . . . . . . . . . . . . . . . . . . 64 158 8 SCVP ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 65 159 9 Security Considerations . . . . . . . . . . . . . . . . . . 73 160 10 IANA Considerations . . . . . . . . . . . . . . . . . . . . 75 161 11 References . . . . . . . . . . . . . . . . . . . . . . . . . 75 162 11.1 Normative References . . . . . . . . . . . . . . . . . . 75 163 11.2 Informative References . . . . . . . . . . . . . . . . . 76 164 12 Intellectual Property Rights . . . . . . . . . . . . . . . . 77 165 13 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 77 166 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 78 167 Appendix A -- MIME Registrations . . . . . . . . . . . . . . . 78 168 A.1 application/cv-request . . . . . . . . . . . . . . . . . 78 169 A.2 application/cv-response . . . . . . . . . . . . . . . . . 79 170 A.3 application/vp-request . . . . . . . . . . . . . . . . . 80 171 A.4 application/vp-response . . . . . . . . . . . . . . . . . 81 172 Appendix B -- SCVP over HTTP . . . . . . . . . . . . . . . . . 81 173 B.1 SCVP Request . . . . . . . . . . . . . . . . . . . . . . 81 174 B.2 SCVP Response . . . . . . . . . . . . . . . . . . . . . . 82 175 B.3 SCVP Policy Request . . . . . . . . . . . . . . . . . . . 82 176 B.4 SCVP Policy Response . . . . . . . . . . . . . . . . . . 83 178 1 Introduction 180 Certificate validation is complex. If certificate handling is to be 181 widely deployed in a variety of applications and environments, the 182 amount of processing an application needs to perform before it can 183 accept a certificate needs to be reduced. There are a variety of 184 applications that can make use of public key certificates, but these 185 applications are burdened with the overhead of constructing and 186 validating the certification paths. SCVP reduces this overhead for 187 two classes of certificate-using applications. 189 The first class of applications wants just two things: confirmation 190 that the public key belongs to the identity named in the certificate 191 and confirmation that the public key can be used for the intended 192 purpose. Such clients can completely delegate certification path 193 construction and validation to the SCVP server. This is often 194 referred to as delegated path validation (DPV). 196 The second class of applications can perform certification path 197 validation, but they lack a reliable or efficient method of 198 constructing a valid certification path. Such clients delegate 199 certification path construction to the SCVP server, but not 200 validation of the returned certification path. This is often 201 referred to as delegated path discovery (DPD). 203 1.1 Terminology 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in [STDWORDS]. 209 1.2 SCVP overview 211 The primary goals of SCVP are to make it easier to deploy PKI- 212 enabled applications by delegating path discovery and/or validation 213 processing to a server, and to allow central administration of 214 validation policies within an organization. SCVP can be used by 215 clients that do much of the certificate processing themselves but 216 simply want an untrusted server to collect information for them. 217 However, when the client has complete trust in the SCVP server, SCVP 218 can be used to delegate the work of certification path construction 219 and validation, and SCVP can be used to ensure that policies are 220 consistently enforced throughout an organization. 222 Untrusted SCVP servers can provide clients the certification paths. 223 They can also provide clients the revocation information, such as 224 CRLs and OCSP responses, that the clients need to validate the 225 certification paths constructed by the SCVP server. These services 226 can be valuable to clients that do not include the protocols needed 227 to find and download intermediate certificates, CRLs, and OCSP 228 responses. 230 Trusted SCVP servers can perform certification path construction and 231 validation for the client. For a client that uses these services, 232 the client inherently trusts the SCVP server as much as it would its 233 own certification path validation software (if it contained such 234 software). There are two main reasons that a client may want to 235 trust such an SCVP server: 237 1. The client does not want to incur the overhead of including 238 certification path validation software and running it for each 239 certificate it receives. 241 2. The client is in an organization or community that wants to 242 centralize management of validation policies. These policies 243 might dictate that particular trust anchors are to be used and 244 the types of policy checking that are to be performed during 245 certification path validation. 247 1.3 SCVP Requirements 249 SCVP meets the mandatory requirements documented in [RQMTS] for DPV 250 and DPD. When SCVP is used to support DPD, the same response is 251 returned when a path is constructed, but some or all of the 252 revocation information is unavailable. 254 Note that RFC 3379 states the following requirement: 255 "The DPD response MUST indicate one of the following status 256 alternatives: 257 1) one or more certification paths was found according to the 258 path discovery policy, with all of the requested revocation 259 information present. 260 2) one or more certification paths was found according to the 261 path discovery policy, with a subset of the requested 262 revocation information present. 263 3) one or more certification paths was found according to the 264 path discovery policy, with none of the requested revocation 265 information present. 266 4) no certification path was found according to the path 267 discovery policy. 268 5) path construction could not be performed due to an error." 270 DPD responses constructed by SCVP servers do not differentiate 271 between states 2) and 3). This property was discussed on list and 272 determined to be conformant with the intent of [RQMTS]. 274 1.4 Validation Policies 276 A validation policy (as defined in RFC 3379 [RQMTS]) specifies the 277 rules and parameters to be used by the SCVP server when validating a 278 certificate. In SCVP, the validation policy to be used by the 279 server can either be fully referenced in the request by the client 280 (and thus no additional parameters are necessary) or it can be 281 referenced in the request by the client with additional parameters. 283 Policy definitions can be quite long and complex, and some policies 284 may allow for the setting of a few parameters. The request can 285 therefore be very simple if an OBJECT IDENTIFIER (OID) is used to 286 specify both the algorithm to be used and all the associated 287 parameters of the validation policy. The request can be more 288 complex if the validation policy fixes many of the parameters but 289 allows the client to specify some of them. When the validation 290 policy defines every parameter necessary, an SCVP request needs only 291 to contain the certificate to be validated, the referenced 292 validation policy, and any run-time parameters for the request. 294 A server publishes the references of the validation policies it 295 supports. When these policies have parameters that may be 296 overridden, the server communicates the default values for these 297 parameters as well. The client can simplify the request by omitting 298 a parameter from a request if the default value published by the 299 server for a given validation policy reference is acceptable. 300 However, if there is a desire to demonstrate to someone else that a 301 specific validation policy with all its parameters has been used, 302 the client will need to ask the server for the inclusion of the full 303 validation policy with all the parameters in the response. 305 The inputs to the basic certification path processing algorithm used 306 by SCVP are defined by [PKIX-1] in section 6.1.1 and comprise: 308 Certificate to be validated (by value or by reference); 310 Validation time; 312 The initial policy set; 314 Initial inhibit policy mapping setting; 316 Initial inhibit anyPolicy setting; and 318 Initial require explicit policy setting. 320 The basic certification path processing algorithm also supports 321 specification of one or more Trust Anchors (by value or reference) 322 as an input. Where the client demands a certification originating 323 with a specific CA, a single Trust Anchor is specified. Where the 324 client is willing to accept paths beginning with any of several CAs, 325 a set of Trust anchors is specified. 327 The basic certification path processing algorithm also supports the 328 following parameters, which are defined in [PKIX-1] section 4: 330 The usage of the key contained in the certificate (e.g., key 331 encipherment, key agreement, signature); and 333 Other application-specific purposes for which the certified public 334 key may be used. 336 1.5 Validation Algorithm 338 The validation algorithm is determined by agreement between the 339 client and the server and is represented as an OID. The algorithm 340 defines the checking that will be performed by the server to 341 determine whether the certificate is valid. A validation algorithm 342 is one of the parameters to a validation policy. SCVP defines a 343 basic validation algorithm that implements the basic path validation 344 algorithm as defined in [PKIX-1], and permits the client to request 345 additional information about the certificate to be validated. New 346 validation algorithms can be specified that define additional checks 347 if needed. These new validation algorithms may specify additional 348 parameters. The values for these parameters may be defined by any 349 validation policy that uses the algorithm or may be included by the 350 client in the request. 352 Application-specific validation algorithms in addition to those 353 defined in this document can be defined to meet specific 354 requirements not covered by the basic validation algorithm. The 355 validation algorithms documented here should serve as a guide for 356 the development of further application-specific validation 357 algorithms. For example, a new application-specific validation 358 algorithm might require the presence of a particular name form in 359 the subject alternative name extension of the certificate. 361 1.6 Validation Requirements 363 For a certification path to be considered valid under a particular 364 validation policy it MUST be a valid certification path as defined 365 in [PKIX-1] and all validation policy constraints that apply to the 366 certification path MUST be verified. 368 Revocation checking is one aspect of certification path validation 369 defined in [PKIX-1]. However, revocation checking is an optional 370 feature in [PKIX-1], and revocation information is distributed in 371 multiple formats. Clients specify in requests whether revocation 372 checking should be performed and whether revocation information 373 should be returned in the response. 375 Servers MUST be capable of indicating the sources of revocation 376 information that they are capable of processing: 378 1. full CRLs (or full Authority Revocation Lists); 380 2. OCSP responses, using [OCSP]; 382 3. delta CRLs; and 384 4. indirect CRLs. 386 2 Protocol Overview 388 SCVP uses a simple request-response model. That is, the SCVP client 389 creates a request and sends it to the SCVP server, and then the SCVP 390 server creates a single response and sends it to the client. The 391 typical use of SCVP is expected to be over HTTP [HTTP], but it can 392 also be used with email or any other protocol that can transport 393 digitally signed objects. Appendices A and B provide the details 394 necessary to use SCVP with HTTP. 396 SCVP includes two request-response pairs. The primary request- 397 response pair handles certificate validation. The secondary 398 request-response pair is used to determine the list of validation 399 policies and default parameters supported by a specific SCVP server. 401 Section 3 defines the certificate validation request. 403 Section 4 defines the corresponding certificate validation response. 405 Section 5 defines the validation policies request. 407 Section 6 defines the corresponding validation policies response. 409 Appendix A registers MIME types for SCVP requests and responses, and 410 Appendix B describes the use of these MIME types with HTTP. 412 3 Validation Request 414 An SCVP client request to the server MUST be a single CVRequest 415 item. When a CVRequest is encapsulated in a MIME body part, 416 application/cv-request MUST be used. 418 There are two forms of SCVP request: unprotected and protected. A 419 protected request is used to authenticate the client to the server 420 or to provide anonymous client integrity over the request-response 421 pair. The protection is provided by a digital signature or message 422 authentication code (MAC). In the later case, the MAC key is 423 derived using a key agreement algorithm, such as Diffie-Hellman. If 424 the client's public key is contained in a certificate, then it may 425 be used to authenticate the client. More commonly, the client's key 426 agreement public key will be ephemeral, supporting anonymous client 427 integrity. 429 A server MAY require all requests to be protected, and a server MAY 430 discard all unprotected requests. Alternatively, a server MAY 431 choose to process unprotected requests. 433 The unprotected request consists of a CVRequest encapsulated in a 434 CMS ContentInfo [CMS]. An overview of this structure is provided 435 below and is only intended as illustrative. The definitive ASN.1 is 436 found in [CMS]. Many details are not shown, but the way that SCVP 437 makes use of CMS is clearly illustrated. 439 ContentInfo { 440 contentType id-ct-scvp-certValRequest, 441 -- (1.2.840.113549.1.9.16.1.10) 442 content CVRequest } 444 The protected request consists of a CVRequest encapsulated in either 445 a SignedData or AuthenticatedData, which is in turn encapsulated in 446 a ContentInfo. That is, the EncapsulatedContentInfo field of either 447 SignedData or AuthenticatedData consists of an eContentType field 448 with a value of id-ct-scvp-certValRequest and an eContent field that 449 contains a DER encoded CVRequest. SignedData is used when the 450 request is digitally signed. AuthenticatedData is used with a 451 message authentication code (MAC). 453 All SCVP clients MUST support SignedData for signed requests and 454 responses. SCVP clients SHOULD support AuthenticatedData for MAC 455 protected requests and responses. 457 If the client uses SignedData it MUST have a public key that has 458 been bound to a subject identity by a certificate that conforms to 459 the PKIX profile [PKIX-1] and that certificate MUST be suitable for 460 signing the SCVP request. That is: 462 1. If the key usage extension is present, either the digital 463 signature or the non-repudiation bit MUST be asserted. 465 2. If the extended key usage extension is present, it MUST 466 contain either the SCVP client OID (see Section 3.10) or 467 another OID acceptable to the SCVP server. 469 The client MUST put an unambiguous reference to its certificate in 470 the SignedData that encapsulates the request. The client SHOULD 471 include its certificate in the request, but MAY omit the certificate 472 to reduce the size of the request. The client MAY include other 473 certificates in the request to aid the validation of its 474 certificates by the SCVP server. The signerInfos field of 475 SignedData MUST include exactly one SignerInfo. The SignedData MUST 476 NOT include the unsignedAttrs field. 478 The client MUST put its key agreement public key or an unambiguous 479 reference to a certificate that contains its key agreement public 480 key in the AuthenticatedData that encapsulates the request. If an 481 ephemeral key agreement key pair is used, then the ephemeral key 482 agreement public key is carried in the originatorKey field of 483 KeyAgreeRecipientInfo, which requires the client to obtain the 484 server's key agreement public key before computing the message 485 authentication code (MAC). The recipientInfos field of 486 AuthenticatedData MUST include exactly one RecipientInfo, which 487 contains information for the SCVP server. The AuthenticatedData 488 MUST NOT include the unauthAttrs field. 490 The syntax and semantics for SignedData, AuthenticatedData, and 491 ContentInfo are defined in [CMS]. The syntax and semantics for 492 CVRequest are defined below. The CVRequest item contains the client 493 request. The CVRequest contains the cvRequestVersion and query 494 items; the CVRequest MAY also contain the requestorRef, 495 requestNonce, requestorName, responderName, requestExtensions, 496 signatureAlg, and hashAlg items. 498 The CVRequest MUST have the following syntax: 500 CVRequest ::= SEQUENCE { 501 cvRequestVersion INTEGER DEFAULT 1, 502 query Query, 503 requestorRef [0] GeneralNames OPTIONAL, 504 requestNonce [1] OCTET STRING OPTIONAL, 505 requestorName [2] GeneralName OPTIONAL, 506 responderName [3] GeneralName OPTIONAL, 507 requestExtensions [4] Extensions OPTIONAL, 508 signatureAlg [5] AlgorithmIdentifier OPTIONAL, 509 hashAlg [6] OBJECT IDENTIFIER OPTIONAL, 510 requestorText [7] UTF8String (SIZE (1..256)) OPTIONAL } 512 Conforming clients MUST be able to construct requests with 513 cvRequestVersion and query. Conforming clients MUST DER-encode the 514 CVRequest in both protected and unprotected messages to facilitate 515 unambiguous hash-based referencing in the corresponding response 516 message. SCVP clients that insist on creation of a fresh response 517 (e.g., to protect against a replay attack or ensure information is 518 up to date) MUST support requestNonce. Support for the remaining 519 items is optional in client implementations. 521 Conforming servers MUST be able to parse CVRequests that contain any 522 or all of the optional items. 524 Each of the items within the CVRequest is described in the following 525 sections. 527 3.1 cvRequestVersion 529 The cvRequestVersion item defines the version of the SCVP CVRequest 530 used in a request. The subsequent response MUST use the same 531 version number. The value of the cvRequestVersion item MUST be one 532 (1) for a client implementing this specification. Future updates to 533 this specification must specify other values if there are any 534 changes to syntax or semantics. 536 SCVP clients MUST support asserting this value and SCVP servers must 537 be capable of processing this value. 539 3.2 query 541 The query item specifies one or more certificates that are the 542 subject of the request; the certificates can be either public key 543 certificates [PKIX-1] or attribute certificates [PKIX-AC]. A query 544 MUST contain a queriedCerts item as well as one checks, and one 545 validationPolicy item; a query MAY also contain wantback, 546 responseFlags, serverContextInfo, validationTime, intermediateCerts, 547 revInfos, producedAt, and queryExtensions items. 549 Query MUST have the following syntax: 551 Query ::= SEQUENCE { 552 queriedCerts CertReferences, 553 checks CertChecks, 554 wantBack [1] WantBack OPTIONAL, 555 validationPolicy ValidationPolicy, 556 responseFlags ResponseFlags OPTIONAL, 557 serverContextInfo [2] OCTET STRING OPTIONAL, 558 validationTime [3] GeneralizedTime OPTIONAL, 559 intermediateCerts [4] CertBundle OPTIONAL, 560 revInfos [5] RevocationInfos OPTIONAL, 561 producedAt [6] GeneralizedTime OPTIONAL, 562 queryExtensions [7] Extensions OPTIONAL } 564 The list of certificate references in the queriedCerts item tells 565 the server the certificate(s) for which the client wants 566 information. The checks item specifies the checking that the client 567 wants performed. The wantBack item specifies the objects that the 568 client wants the server to return in the response. The 569 validationPolicy item specifies the validation policy that the 570 client wants the server to employ. The responseFlags item allows 571 the client to request optional features for the response. The 572 serverContextInfo item tells the server that additional information 573 from a previous request-response is desired. The validationTime 574 item tells the date and time relative to which the client wants the 575 server to perform the checks. The intermediateCerts and revInfos 576 items provide context for the client request. The queryExtensions 577 item provides for future expansion of the query syntax. The syntax 578 and semantics of each of these items is discussed in the following 579 sections. 581 Conforming clients MUST be able to construct a Query with a 582 queriedCerts item that specifies at least one certificate, checks, 583 and validationPolicy. Conforming SCVP clients MAY support 584 specification of multiple certificates and MAY support the optional 585 items in the Query structure. 587 SCVP clients that support delegated path discovery (DPD) as defined 588 in [RQMTS] MUST support wantBack and responseFlags. SCVP clients 589 that insist on creation of a fresh response (e.g., to protect 590 against a replay attack or ensure information is up to date) MUST 591 support responseFlags. 593 Conforming servers MUST be able to process a Query that contains any 594 of the optional items, and MUST be able to process a Query that 595 specifies multiple certificates. 597 3.2.1 queriedCerts 599 The queriedCerts item is a SEQUENCE of one or more certificates, 600 each of which is a subject of the request. The specified 601 certificates are either public key certificates or attribute 602 certificates; if more than one certificate is specified, all must be 603 of the same type. Each certificate is either directly included or 604 it is referenced. When referenced, a hash value of the referenced 605 item is included to ensure that the SCVP client and the SCVP server 606 both obtain the same certificate when the referenced certificate is 607 fetched. Certificate references use the CertID type, which is 608 described below. A single request MAY contain both directly 609 included and referenced certificates. 611 CertReferences has the following syntax: 613 CertReferences ::= CHOICE { 614 pkcRefs [0] SEQUENCE SIZE (1..MAX) OF PKCReference, 615 acRefs [1] SEQUENCE SIZE (1..MAX) OF ACReference } 617 PKCReference ::= CHOICE { 618 cert [0] Certificate, 619 pkcRef [1] CertID } 621 ACReference ::= CHOICE { 622 attrCert [2] AttributeCertificate, 623 acRef [3] CertID } 625 CertID ::= SEQUENCE { 626 certHash OCTET STRING, 627 issuerSerial IssuerSerial, 628 hashAlgorithm AlgorithmIdentifier DEFAULT { sha-1 } } 630 The ASN.1 definition of Certificate is imported from [PKIX-1] and 631 the definition of AttributeCertificate is imported from [PKIX-AC]. 633 When creating a CertID, the certHash is computed over the entire DER 634 encoded certificate including the signature. The hash algorithm 635 used to compute certHash is specified in hashAlgorithm. The hash 636 algorithm used to compute certHash SHOULD be one of the hash 637 algorithms specified in the hashAlgorithms item of the server's 638 validation policy response message. 640 When encoding IssuerSerial, serialNumber is the serial number that 641 uniquely identifies the certificate. For public key certificates, 642 the issuer MUST contain only the issuer name from the certificate 643 encoded in the directoryName choice of GeneralNames. For attribute 644 certificates, the issuer MUST contain the issuer name field from the 645 attribute certificate. 647 Conforming clients MUST be able to reference a certificate by direct 648 inclusion. Clients SHOULD be able to specify a certificate using 649 the CertID. Conforming clients MAY be able to reference multiple 650 certificates and MAY be able to reference both public key and 651 attribute certificates. 653 Conforming SCVP Server implementations MUST be able to process 654 CertReferences with multiple certificates. Conforming SCVP Server 655 implementations MUST be able to parse CertReferences that contain 656 either public key or attribute certificates. Conforming SCVP Server 657 implementations MUST be able to parse both the cert and pkcRef 658 choices in PKCReference. Conforming SCVP Server implementations 659 that process attribute certificates MUST be able to parse both the 660 attrCert and acRef choices in ACReference. 662 3.2.2 checks 664 The checks item describes the checking that the SCVP client wants 665 the SCVP server to perform on the certificate(s) in the queriedCerts 666 item. The checks item contains a sequence of object identifiers 667 (OIDs). Each OID tells the SCVP server what checking the client 668 expects the server to perform. For each check specified in the 669 request, the SCVP server MUST perform the requested check, or return 670 an error. A server may choose to perform additional checks (e.g., a 671 server that is only asked to build a validated certification path 672 may choose to also perform revocation status checks), although the 673 server cannot indicate in the response that the additional checks 674 have been performed. 676 The checks item uses the CertChecks type, which has the following 677 syntax: 679 CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 681 For public key certificates, the following checks are defined: 683 - id-stc-build-pkc-path: Build a prospective certification path to 684 a trust anchor (as defined in section 6.1 of [PKIX-1]); 686 - id-stc-build-valid-pkc-path: Build a validated certification path 687 to a trust anchor (revocation checking not required); 689 - id-stc-build-status-checked-pkc-path: Build a validated 690 certification path to a trust anchor and perform revocation 691 status checks on the certification path. 693 Conforming SCVP server implementations that support delegated path 694 discovery (DPD) as defined in [RQMTS] MUST support the id-stc-build- 695 pkc-path check. Conforming SCVP server implementations that support 696 delegated path validation (DPV) as defined in [RQMTS] MUST support 697 the id-stc-build-valid-pkc-path and id-stc-build-status-checked-pkc- 698 path checks. 700 For attribute certificates, the following checks are defined: 702 - id-stc-build-aa-path: Build a prospective certification path to a 703 trust anchor for the AC issuer; 705 - id-stc-build-valid-aa-path: Build a validated certification path 706 to a trust anchor for the AC issuer; 708 - id-stc-build-status-checked-aa-path: Build a validated 709 certification path to a trust anchor for the AC issuer and 710 perform revocation status checks on the certification path for 711 the AC issuer; 713 - id-stc-status-check-ac-and-build-status-checked-aa-path: Build a 714 validated certification path to a trust anchor for the AC 715 issuer and perform revocation status checks on the AC as well 716 as the certification path for the AC issuer. 718 Conforming SCVP server implementations MAY support the attribute 719 certificates checks. 721 For these purposes, the following OIDs are defined: 723 id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 724 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 } 726 id-stc-build-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 } 727 id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 2 } 728 id-stc-build-status-checked-pkc-path 729 OBJECT IDENTIFIER ::= { id-stc 3 } 730 id-stc-build-aa-path OBJECT IDENTIFIER ::= { id-stc 4 } 731 id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 5 } 732 id-stc-build-status-checked-aa-path 733 OBJECT IDENTIFIER ::= { id-stc 6 } 734 id-stc-status-check-ac-and-build-status-checked-aa-path 735 OBJECT IDENTIFIER ::= { id-stc 7 } 737 Conforming client implementations MUST be able to assert at least 738 one of the standard checks. Conforming clients MAY be able to 739 assert multiple checks. Conforming clients need not support all of 740 the checks defined in this section. 742 3.2.3 wantBack 744 The optional wantBack item describes any information the SCVP client 745 wants from the SCVP server for the certificate(s) in the 746 queriedCerts item in addition to the results of the checks specified 747 in certChecks. If present, the wantBack item MUST contain a 748 sequence of object identifiers (OIDs). Each OID tells the SCVP 749 server what the client wants to know about the queriedCerts item. 750 For each type of information specified in the request, the server 751 MUST return information regarding its finding (in a successful 752 response). 754 For example, a request might include a checks item that only 755 specifies certification path building and include a wantBack item 756 that requests the return of the certification path built by the 757 server. In this case, the response would not include a status for 758 the validation of the certification path, but it would include a 759 certification path that the server considers to be valid. A client 760 that wants to perform its own certification path validation might 761 use a request of this form. 763 Alternatively, a request might include a checks item that requests 764 the server to build a certification path and validate it, including 765 revocation checking, and not include a wantBack item. In this case, 766 the response would include only a status for the validation of the 767 certification path. A client that completely delegates 768 certification path validation might use a request of this form. 770 The wantBack item uses the WantBack type, which has the following 771 syntax: 773 WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 775 For public key certificates, the types of information that can be 776 requested are: 778 - id-swb-pkc-cert: The certificate that was the subject of the 779 request; 781 - id-swb-pkc-best-cert-path: The certification path built for the 782 certificate including the certificate that was validated; 784 - id-swb-pkc-revocation-info: Proof of revocation status for each 785 certificate in the certification path; 787 - id-swb-pkc-public-key-info: The public key from the certificate; 789 - id-swb-pkc-all-cert-paths: A set of certification paths for the 790 certificate; 792 - id-swb-pkc-ee-revocation-info: Proof of revocation status for the 793 end entity certificate in the certification path; and 795 - id-swb-pkc-CAs-revocation-info: Proof of revocation status for 796 each CA certificate in the certification path. 798 All conforming SCVP server implementations MUST support the id-swb- 799 pkc-cert and id-swb-pkc-public-key-info wantBacks. Conforming SCVP 800 server implementations that support delegated path discovery (DPD) 801 as defined in [RQMTS] MUST support the id-swb-pkc-best-cert-path and 802 id-swb-pkc-revocation-info wantBacks. 804 The SCVP protocol provides two methods for a client to obtain 805 multiple certification paths for a certificate. The client could 806 use serverContextInfo to request one path at a time (see section 807 3.2.6). After obtaining each path, the client could submit the 808 serverContextInfo from the previous request to obtain another path 809 until the client either found a suitable path or the server 810 indicated (by not returning a serverContextInfo) that no more paths 811 were available. Alternatively, the client could send a single 812 request with an id-swb-pkc-all-cert-paths wantBack, in which case 813 the server would return all of the available paths in a single 814 response. 816 The server may, at its discretion, limit the number of paths that it 817 returns in response to the id-swb-pkc-all-cert-paths. When the 818 request includes an id-swb-pkc-all-cert-paths wantBack, the response 819 should not include a serverContextInfo. 821 For attribute certificates, the types of information that can be 822 requested are: 824 - id-swb-ac-cert: The attribute certificate that was the subject of 825 the request; 827 - id-swb-aa-cert-path: The certification path built for the AC 828 issuer certificate; 830 - id-swb-ac-revocation-info: Proof of revocation status for each 831 certificate in the AC issuer certification path; and 833 - id-swb-aa-revocation-info: Proof of revocation status for the 834 attribute certificate. 836 Conforming SCVP server implementations MAY support the attribute 837 certificate wantbacks. 839 The following wantBack can be used for either public key or 840 attribute certificates: 842 - id-swb-relayed-responses: Any SCVP responses received by the 843 server that were used to generate the response to this query. 845 Conforming SCVP servers MAY support the id-swb-relayed-responses 846 wantBack. 848 For these purposes, the following OIDs are defined: 850 id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 851 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 } 853 id-swb-pkc-best-cert-path OBJECT IDENTIFIER ::= { id-swb 1 } 854 id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 } 855 id-swb-pkc-public-key-info OBJECT IDENTIFIER ::= { id-swb 4 } 856 id-swb-aa-cert-path OBJECT IDENTIFIER ::= { id-swb 5 } 857 id-swb-aa-revocation-info OBJECT IDENTIFIER ::= { id-swb 6 } 858 id-swb-ac-revocation-info OBJECT IDENTIFIER ::= { id-swb 7 } 859 id-swb-relayed-responses OBJECT IDENTIFIER ::= { id-swb 9 } 860 id-swb-pkc-cert OBJECT IDENTIFIER ::= { id-swb 10} 861 id-swb-ac-cert OBJECT IDENTIFIER ::= { id-swb 11} 862 id-swb-pkc-all-cert-paths OBJECT IDENTIFIER ::= { id-swb 12} 863 id-swb-pkc-ee-revocation-info OBJECT IDENTIFIER ::= { id-swb 13} 864 id-swb-pkc-CAs-revocation-info OBJECT IDENTIFIER ::= { id-swb 14} 866 Conforming client implementations that support delegated path 867 validation (DPV) as defined in [RQMTS] SHOULD be able to assert at 868 least one wantback. Conforming client implementations that support 869 delegated path discovery (DPD) as defined in [RQMTS] MUST be able to 870 assert at least one wantBack. Conforming clients MAY be able to 871 assert multiple wantbacks. Conforming clients need not support all 872 of the wantbacks defined in this section. 874 3.2.4 validationPolicy 876 The validationPolicy item defines the validation policy that the 877 client wants the SCVP server to use during certificate validation. 878 If this policy cannot be used for any reason, then the server MUST 879 return an error response. 881 A validation policy MUST define default values for all parameters 882 necessary for processing an SCVP request. For each parameter, a 883 validation policy may either allow the client to specify a non- 884 default value or forbid the use of a non-default value. If the 885 client wishes to use the default values for all of the parameters, 886 then the client need only supply a reference to the policy in this 887 item. If the client wishes to use non-default values for one or 888 more parameters, then the client supplies a reference to the policy 889 plus whatever parameters are necessary to complete the request in 890 this item. If there are any conflicts between the policy referenced 891 in the request and any supplied parameter values in the request, 892 then the server MUST return an error response. 894 The syntax of the validationPolicy item is: 896 ValidationPolicy ::= SEQUENCE { 897 validationPolRef ValidationPolRef, 898 validationAlg [0] ValidationAlg OPTIONAL, 899 userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT 900 IDENTIFIER OPTIONAL, 901 inhibitPolicyMapping [2] BOOLEAN OPTIONAL, 902 requireExplicitPolicy [3] BOOLEAN OPTIONAL, 903 inhibitAnyPolicy [4] BOOLEAN OPTIONAL, 904 trustAnchors [5] TrustAnchors OPTIONAL, 905 keyUsages [6] SEQUENCE OF KeyUsage OPTIONAL, 906 extendedKeyUsages [7] SEQUENCE OF KeyPurposeId OPTIONAL } 908 The validationPolRef item is required, but the remaining items are 909 optional. The optional items are used to provide validation policy 910 parameters. When the client uses the validation policy's default 911 values for all parameters, all of the optional items are absent. 913 At a minimum, conforming SCVP client implementations MUST support 914 the ValidationPolRef item. Conforming client implementations MAY 915 support any or all of the optional items in ValidationPolicy. 917 Conforming SCVP servers MUST be able to process a ValidationPolicy 918 that contains any or all of the optional items. 920 The validationAlg item specifies the validation algorithm. The 921 userPolicySet item provides an acceptable set of certificate 922 policies. The inhibitPolicyMapping item inhibits certificate policy 923 mapping during certification path validation. The 924 requireExplicitPolicy item requires at least one valid certificate 925 policy in the certificate policies extension. The inhibitAnyPolicy 926 item indicates whether the anyPolicy certificate policy OID is 927 processed or ignored when evaluating certificate policy. The 928 trustAnchors item indicates the trust anchors that are acceptable to 929 the client. The keyUsages item indicates the technical usage of the 930 public key that is to be confirmed by the server as acceptable. The 931 extendedKeyUsages item indicates the application-specific usage of 932 the public key that is to be confirmed by the server as acceptable. 933 The syntax and semantics of each of these items is discussed in the 934 following sections. 936 3.2.4.1 validationPolRef 938 The reference to the validation policy is an OID that the client and 939 server have agreed represents a particular validation policy. 941 The syntax of the ValidationPolRef item is: 943 ValidationPolRef::= SEQUENCE { 944 valPolId OBJECT IDENTIFIER, 945 valPolParams ANY DEFINED BY valPolId OPTIONAL } 947 Where a validation policy supports additional policy-specific 948 parameter settings, these values are specified using the 949 valPolParams item. The syntax and semantics of the parameters 950 structure is defined by the object identifier encoded as the 951 valPolId. Where a validation policy has no parameters, such as the 952 default validation policy (see 3.2.4.1.1), this item MUST be 953 omitted. 955 Parameters specified in this item are independent of the validation 956 algorithm and the validation algorithm's parameters (see Section 957 3.2.4.2). For example, a server may support a validation policy 958 where it validates a certificate using the name validation algorithm 959 and also makes a determination regarding the creditworthiness of the 960 subject. In this case, the validation policy parameters could be 961 used to specify the value of the transaction. The validation 962 algorithm parameters are used to specify the application identifier 963 and name for the name validation algorithm. 965 Conforming SCVP client implementations MUST be able to specify a 966 validation policy. Conforming SCVP client implementations MAY be 967 able to specify parameters for a validation policy. Conforming SCVP 968 server implementations MUST be able to process valPolId and MAY be 969 able to process valPolParams. 971 3.2.4.1.1 Default Validation Policy 973 The client can request the SCVP server's default validation policy 974 or another validation policy. The default validation policy 975 corresponds to standard certification path processing as defined in 976 [PKIX-1] with server chosen default values (e.g., with a server 977 determined policy set and trust anchors). The default values can be 978 distributed out of band or using the policy request mechanism (see 979 Section 5). This mechanism permits the deployment of an SCVP server 980 without obtaining a new object identifier. 982 The object identifier that identifies the default validation policy 983 is: 985 id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 986 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 } 988 id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 } 990 The default validation policy MUST use the basic validation 991 algorithm as its default validation algorithm (see section 992 3.2.4.2.1), and has no validation policy parameters (see section 993 3.2.4.1). 995 When using the default validation policy, the client can override 996 any of the default parameter values by supplying a specific value in 997 the request. The SCVP server MUST make use of the provided 998 parameter values or return an error response. 1000 Conforming implementations of SCVP servers MUST support the default 1001 policy. However, an SCVP server may be configured to send an error 1002 response to all requests using the default policy to meet local 1003 security requirements. 1005 3.2.4.2 validationAlg 1007 The optional validationAlg item defines the validation algorithm to 1008 be used by the SCVP server during certificate validation. The value 1009 of this item can be determined by agreement between the client and 1010 the server. The validation algorithm is represented by an object 1011 identifier. 1013 The syntax of the validationAlg is: 1015 ValidationAlg ::= SEQUENCE { 1016 valAlgId OBJECT IDENTIFIER, 1017 parameters ANY DEFINED BY valAlgId OPTIONAL } 1019 The following section specifies the basic validation algorithm and 1020 the name validation algorithm. 1022 SCVP servers MUST recognize and support both validation algorithms 1023 defined in this section. SCVP clients that support explicit 1024 assertion of the validation algorithm MUST support the basic 1025 validation algorithm and SHOULD support the name validation 1026 algorithm. Other validation algorithms can be specified in other 1027 documents for use with specific applications. SCVP clients and 1028 servers MAY support any such validation algorithms. 1030 3.2.4.2.1 Basic Validation Algorithm 1032 The client can request use of the SCVP basic validation algorithm or 1033 another algorithm. For identity certificates, the basic validation 1034 algorithm MUST implement the certification path validation algorithm 1035 as defined in section 6 of [PKIX-1]. For attribute certificates, 1036 the basic validation algorithm MUST implement certificate path 1037 validation as defined in section 5 of [PKIX-AC]. Other validation 1038 algorithms MAY implement functions over and above those in the basic 1039 algorithm, but validation algorithms MUST generate results compliant 1040 with the basic validation algorithm. That is, none of the 1041 validation requirements in the basic algorithm may be omitted from 1042 any newly defined validation algorithms. However, other validation 1043 algorithms MAY reject paths that are valid using the basic 1044 validation algorithm. The object identifier to identify the basic 1045 validation algorithm is: 1047 id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 } 1049 When id-svp-basicValAlg appears in valAlgId, the parameters item 1050 MUST be absent. 1052 3.2.4.2.2 Basic Validation Algorithm Errors 1054 The following errors are defined for the basic validation algorithm 1055 for inclusion in the validationErrors item in the response (see 1056 section 4.9.6). These errors can be used by any other validation 1057 algorithm since all validation algorithms MUST implement the 1058 functionality of the basic validation algorithm. 1060 id-bvae OBJECT IDENTIFIER ::= id-svp-basicValAlg 1062 id-bvae-expired OBJECT IDENTIFIER ::= { id-bvae 1 } 1063 id-bvae-not-yet-valid OBJECT IDENTIFIER ::= { id-bvae 2 } 1064 id-bvae-wrongTrustAnchor OBJECT IDENTIFIER ::= { id-bvae 3 } 1065 id-bvae-noValidCertPath OBJECT IDENTIFIER ::= { id-bvae 4 } 1066 id-bvae-revoked OBJECT IDENTIFIER ::= { id-bvae 5 } 1067 id-bvae-invalidKeyPurpose OBJECT IDENTIFIER ::= { id-bvae 9 } 1068 id-bvae-invalidKeyUsage OBJECT IDENTIFIER ::= { id-bvae 10 } 1069 id-bvae-invalidCertPolicy OBJECT IDENTIFIER ::= { id-bvae 11 } 1071 The id-bvae-expired value means that the validation time used for 1072 the request was later than the notAfter time in the end certificate 1073 (the certificate specified in the queriedCerts item). 1075 The id-bvae-not-yet-valid value means that the validation time used 1076 for the request was before the notBefore time in the end 1077 certificate. 1079 The id-bvae-wrongTrustAnchor value means that a certification path 1080 could not be constructed for the client specified trust anchor(s), 1081 but a path exists for one of the trust anchors specified in the 1082 server's default validation policy. 1084 The id-bvae-invalidKeyUsage value means that the keyUsage extension 1085 (PKIX-1 section 4.2.1.3) in the end certificate does not satisfy the 1086 validation policy. For example, the keyUsage extension in the 1087 certificate may assert only the keyEncipherment bit, but the 1088 validation policy specifies in the keyUsages item that 1089 digitalSignature is required. 1091 The id-bvae-invalidCertPolicy value means that the path is not valid 1092 under any of the policies specified in the user policy set and 1093 explicit policies are required. That is, the valid_policy_tree is 1094 NULL and the explicit_policy variable is zero (PKIX-1 section 1095 6.1.5). 1097 The id-bvae-invalidKeyPurpose value means that the extended key 1098 usage extension (PKIX-1 section 4.2.1.13) in the end certificate 1099 does not satisfy the validation policy. 1101 The id-bvae-revoked value means that the end certificate was 1102 revoked. 1104 3.2.4.2.3 Name Validation Algorithm 1106 The name validation algorithm allows the client to specify one or 1107 more subject names that MUST appear in the end certificate in 1108 addition to the requirements specified for the basic validation 1109 algorithm. The name validation algorithm allows the client to 1110 supply an application identifier and a name to the server. The 1111 application identifier defines the name matching rules to use in 1112 comparing the name supplied in the request with the names in the 1113 certificate. 1115 id-svp-nameValAlg OBJECT IDENTIFIER ::= { id-svp 2 } 1117 When the id-svp-nameValAlg appears as a valAlgId, the parameters 1118 MUST use the NameValidationAlgParms syntax: 1120 NameValidationAlgParms ::= SEQUENCE { 1121 nameCompAlgId OBJECT IDENTIFIER, 1122 validationNames GeneralNames } 1124 GeneralNames is defined in [PKIX-1]. 1126 If more than one name is supplied in the validationNames value, all 1127 names MUST be of the same type. The certificate must contain a 1128 matching name for each of the names supplied in validationNames 1129 according to the name matching rules associated with the 1130 nameCompAlgId. This specification defines three sets of name 1131 matching rules. 1133 If the nameCompAlgId supplied in the request is id-nva-dnCompAlg, 1134 then GeneralNames supplied in the request MUST be a directoryName, 1135 and the matching rules to be used are defined in [PKIX-1]. The 1136 certificate must contain a matching name in either the subject field 1137 or a directoryName in the subjectAltName extension. This 1138 specification defines the OID for id-nva-dnCompAlg as follows: 1140 id-nva-dnCompAlg OBJECT IDENTIFIER ::= { id-svp 4 } 1142 If the nameCompAlgId supplied in the request is id-kp-serverAuth 1143 [PKIX-1], then GeneralNames supplied in the request MUST be a 1144 dNSName, and the matching rules to be used are defined in [HTTP- 1145 TLS]. 1147 If the nameCompAlgId supplied in the request is id-kp-mailProtection 1148 [PKIX-1], then GeneralNames supplied in the request MUST be an 1149 rfc822Name, and the matching rules are defined in [SMIME-CERT]. 1151 Conforming SCVP servers MUST support the name validation algorithm 1152 and the matching rules associated with id-nva-dnCompAlg, id-kp- 1153 serverAuth, id-kp-mailProtection. SCVP server MAY support other 1154 name matching rules. 1156 3.2.4.2.4 Name Validation Algorithm Errors 1158 The following errors are defined for the Name Validation Algorithm: 1160 id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg 1162 id-nvae-name-mismatch OBJECT IDENTIFIER ::= { id-nvae 1 } 1163 id-nvae-no-name OBJECT IDENTIFIER ::= { id-nvae 2 } 1164 id-nvae-unknown-alg OBJECT IDENTIFIER ::= { id-nvae 3 } 1165 id-nvae-bad-name OBJECT IDENTIFIER ::= { id-nvae 4 } 1166 id-nvae-bad-name-type OBJECT IDENTIFIER ::= { id-nvae 5 } 1167 id-nvae-mixed-names OBJECT IDENTIFIER ::= { id-nvae 6 } 1169 The id-nvae-name-mismatch value means the client supplied a name 1170 with the request, which the server recognized and the server found a 1171 corresponding name type in the certificate, but was unable to find a 1172 match to the name supplied. For example, the client supplied a DNS 1173 name of example1.com, the certificate contained a DNS name of 1174 example.com. 1176 The id-nvae-no-name value means the client supplied a name with the 1177 request, which the server recognized, but the server could not find 1178 the corresponding name type in the certificate. For example, the 1179 client supplied a DNS name of example1.com, the certificate only 1180 contained a rfc822Name of user@example.com. 1182 The id-nvae-unknown-alg value means the client supplied a 1183 nameCompAlgId which the server does not recognize. 1185 The id-nvae-bad-name value means the client supplied either an empty 1186 or malformed name in the request. 1188 The id-nvae-bad-name-type value means the client supplied an 1189 inappropriate name type for the application identifier. For 1190 example, the client specified a nameCompAlgId of id-kp-serverAuth, 1191 and an rfc822Name of user@example.com. 1193 The id-nvae-mixed-names value means the client supplied multiple 1194 names in the request of different types. 1196 3.2.4.3 userPolicySet 1198 The userPolicySet item specifies a list of certificate policy 1199 identifiers that the SCVP server MUST use when constructing and 1200 validating a certification path. The userPolicySet item specifies 1201 the user-initial-policy-set as defined in Section 6 of [PKIX-1]. A 1202 userPolicySet containing the anyPolicy OID indicates a user-initial- 1203 policy-set of any-policy. 1205 SCVP clients SHOULD support userPolicySet item in requests, and SCVP 1206 servers MUST support userPolicySet item in requests. 1208 3.2.4.4 inhibitPolicyMapping 1210 The inihibitPolicyMapping item specifies an input to the 1211 certification path validation algorithm, and it controls whether 1212 policy mapping is allowed during certification path validation (see 1213 [PKIX-1], section 6.1.1). If the client wants the server to inhibit 1214 policy mapping, inhibitPolicyMapping is set to TRUE in the request. 1216 SCVP clients MAY support inhibiting policy mapping. SCVP servers 1217 SHOULD support inhibiting policy mapping. 1219 3.2.4.5 requireExplicitPolicy 1221 The requireExplicitPolicy item specifies an input to the 1222 certification path validation algorithm, and it controls whether 1223 there must be at least one valid policy in the certificate policies 1224 extension (see [PKIX-1], section 6.1.1). If the client wants the 1225 server to require at least one policy, requireExplicitPolicy is set 1226 to TRUE in the request. 1228 SCVP clients MAY support requiring explicit policies. SCVP servers 1229 SHOULD support requiring explicit policies. 1231 3.2.4.6 inhibitAnyPolicy 1233 The inhibitAnyPolicy item specifies an input to the certification 1234 path validation algorithm (see [PKIX-1], section 6.1.1), and it 1235 controls whether the anyPolicy OID is processed or ignored when 1236 evaluating certificate policy. If the client wants the server to 1237 ignore the anyPolicy OID, inhibitAnyPolicy MUST be set to TRUE in 1238 the request. 1240 SCVP clients MAY support ignoring the anyPolicy OID. SCVP servers 1241 SHOULD support ignoring the anyPolicy OID. 1243 3.2.4.7 trustAnchors 1245 The trustAnchors item specifies the trust anchors at which the 1246 certification path must terminate if the path is to be considered 1247 valid by the SCVP server for the request. If a trustAnchors item is 1248 present, the server MUST NOT consider any certification paths ending 1249 in other trust anchors as valid. 1251 The TrustAnchors type contains one or more trust anchor 1252 specifications. A certificate reference can be used to identify the 1253 trust anchor by certificate hash and distinguished name with serial 1254 number. Alternatively, trust anchors can be provided directly. The 1255 order of trust anchor specifications within the sequence is not 1256 important. Any CA certificate that meets the requirements of [PKIX- 1257 1] for signing certificates can be provided as a trust anchor. If a 1258 trust anchor is supplied that does not meet these requirements, the 1259 server MUST return an error response. 1261 The trust anchor itself, regardless of its form, MUST NOT be 1262 included in any certification path returned by the SCVP server. 1264 TrustAnchors has the following syntax: 1266 TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF PKCReference 1268 SCVP server MUST support trustAnchors. SCVP clients SHOULD support 1269 trustAnchors. 1271 3.2.4.8 keyUsages 1273 The key usage extension [PKIX-1, section 4.2.1.3] in the certificate 1274 defines the technical purpose (such as encipherment, signature, and 1275 CRL signing) of the key contained in the certificate. If the client 1276 wishes to confirm the technical usage, then it can communicate the 1277 usage it wants to validate by the same structure using the same 1278 semantics as defined in [PKIX-1]. For example, if the client 1279 obtained the certificate in the context of a digital signature, it 1280 can confirm this use by including a keyUsage structure with the 1281 digital signature bit set. 1283 If the keyUsages item is present and contains an empty sequence, it 1284 indicates that the client does not require any particular key usage. 1286 If the keyUsages item contains one or more keyUsage definitions, 1287 then the certificate MUST satisfy at least one of the specified 1288 keyUsage definitions. If the client is willing to accept multiple 1289 possibilities then the client passes in a sequence of possible 1290 patterns. Each keyUsage can contain a set of one or more bits set 1291 in the request, all bits MUST be present in the certificate to match 1292 against an instance of the keyUsage in the SCVP request. If the 1293 certificate key usage extension contains more usages than requested, 1294 then the certificate MUST be considered a match. For example, if a 1295 client wishes to check for either digital signature or non- 1296 repudiation, then the client provides two keyUsage values, one with 1297 digital signature set and the other with non-repudiation set. If 1298 the key usage extension is absent from the certificate, the 1299 certificate MUST be considered good for all usages and therefore any 1300 pattern in the SCVP request will match. 1302 SCVP clients SHOULD support keyUsages, and SCVP servers MUST support 1303 keyUsages. 1305 3.2.4.9 extendedKeyUsages 1307 The extended key usage extension [PKIX-1, section 4.2.1.13] defines 1308 more specific technical purposes, in addition to or in place of the 1309 purposes indicated in the key usage extension, for which the 1310 certified public key may be used. If the client wishes to confirm 1311 the extended key usage, then it can communicate the usage it wants 1312 to validate by the same extension using the same semantics as 1313 defined in [PKIX-1]. For example, if the client obtained the 1314 certificate in the context of a TLS server, it can confirm this 1315 usage by including the extended key usage structure with the id-kp- 1316 serverAuth object identifier. If the extension is absent or is 1317 present and asserts the anyExtendedKeyUsage OID, then all usages 1318 specified in the request are a match. If the extension is present 1319 and more than one usage is set in the request, all usages MUST be 1320 present in the certificate. If the certificate extension contains 1321 more usages than requested, then the certificate MUST be considered 1322 a match. 1324 Where the client does not require any particular extended key usage, 1325 the client can specify an empty SEQUENCE. This may be used to 1326 override extended key usage requirements imposed in the validation 1327 policy specified by valPolId. 1329 SCVP clients SHOULD support extendedKeyUsages, and SCVP servers MUST 1330 support extendedKeyUsages. 1332 3.2.5 responseFlags 1334 The optional response flags item allows the client to indicate which 1335 optional features in the CVResponse it wants the server to include. 1336 If the default values for all of the flags are used, then the 1337 response flags item MUST NOT be included in the request. 1339 The syntax of the responseFlags is: 1341 ResponseFlags ::= SEQUENCE { 1342 fullRequestInResponse [0] BOOLEAN DEFAULT FALSE, 1343 responseValidationPolByRef [1] BOOLEAN DEFAULT TRUE, 1344 protectResponse [2] BOOLEAN DEFAULT TRUE, 1345 cachedResponse [3] BOOLEAN DEFAULT TRUE } 1347 Each of the response flags is described in the following sections. 1349 3.2.5.1 fullRequestInResponse 1351 By default, the server includes a hash of the request in non-cached 1352 responses to allow the client to identify the response. If the 1353 client wants the server to include the full request in the non- 1354 cached response, fullRequestInResponse is set to TRUE. The main 1355 reason a client would request the server to include the full request 1356 in the response is to archive the request-response exchange in a 1357 single object. That is, the client wants to archive a single object 1358 that includes both request and response. 1360 SCVP clients and servers MUST support the default behavior. SCVP 1361 clients MAY support requesting and processing the full request. 1362 SCVP servers SHOULD support returning the full request. 1364 3.2.5.2 responseValidationPolByRef 1366 The responseValidationPolByRef item controls whether the response 1367 includes just a reference to the policy or a reference to the policy 1368 plus all the parameters by value of the policy used to process the 1369 request. The response MUST contain a reference to the validation 1370 policy. If the client wants the validation policy parameters to be 1371 also included by value, then responseValidationPolByRef is set to 1372 FALSE. The main reason a client would request the server to include 1373 validation policy to be included by value is to archive the request- 1374 response exchange in a single object. That is, the client wants to 1375 archive the CVResponse and have it include every aspect of the 1376 validation policy. 1378 SCVP clients and servers MUST support the default behavior. SCVP 1379 clients MAY support requesting and processing the validation policy 1380 by values. SVCP server SHOULD support returning the validation 1381 policy by values. 1383 3.2.5.3 protectResponse 1385 The protectResponse item indicates whether the client requires the 1386 server to protect the response. If the client is performing full 1387 certification path validation on the response and it is not 1388 concerned about the source of the response, then the client does not 1389 benefit from a digital signature or MAC on the response. In this 1390 case, the client can indicate to the server that protecting the 1391 message is unnecessary. However, the server is always permitted to 1392 return a protected response. 1394 SCVP clients that support delegated path discovery (DPD) as defined 1395 in [RQMTS] MUST support setting this value to FALSE. 1397 SCVP clients that support delegated path validation (DPV) as defined 1398 in [RQMTS] require an authenticated response. Unless a protected 1399 transport mechanism (such a TLS) is used, such clients MUST always 1400 set this value to TRUE or omit the responseFlags item entirely, 1401 which requires the server to return a protected response. 1403 SCVP servers MUST support returning protected responses, and SCVP 1404 servers SHOULD support returning unprotected responses. Based on 1405 local policy, the server can be configured to return protected or 1406 unprotected responses if this value is set to FALSE. If based on 1407 local policy the server is unable to return protected responses, 1408 then the server MUST return an error if this value is set to TRUE. 1410 3.2.5.4 cachedResponse 1412 The cachedResponse item indicates whether the client will accept a 1413 cached response. To enhance performance and limit the exposure of 1414 signing keys, an SCVP service may be designed to cache responses 1415 until new revocation information is expected. Where cachedResponse 1416 is set to TRUE, the client will accept a previously cached response. 1418 Clients may insist on creation of a fresh response to protect 1419 against a replay attack and ensure information is up to date. Where 1420 cachedResponse is FALSE, the client will not accept a cached 1421 response. To ensure that a response is fresh, the client MUST also 1422 include the requestNonce as defined in Section 3.4. 1424 Servers MUST process the cachedResponse flag. Where cachedResponse 1425 is FALSE, servers that cannot produce fresh responses MUST reply 1426 with an error message. Servers MAY choose to provide fresh 1427 responses even where cachedResponse is set to TRUE. 1429 3.2.6 serverContextInfo 1431 The optional serverContextInfo item, if present, contains context 1432 from a previous request-response exchange with the same SCVP server. 1433 It allows the server to return more than one certification path for 1434 the same certificate to the client. For example, if a server 1435 constructs a particular certification path for a certificate, but 1436 the client finds it unacceptable, the client can then send the same 1437 query back to the server with the serverContextInfo from the first 1438 response, and the server will be able to provide a different 1439 certification path (if another one can be found). 1441 Contents of the serverContextInfo are opaque to the SCVP client. 1442 That is, the client only knows that it needs to return the value 1443 provided by the server with the subsequent request to get a 1444 different certification path. Note that the subsequent query needs 1445 to be identical to the previous query with the exception of the 1446 following: 1448 - requestNonce; 1450 - serverContextInfo; and 1452 - the client's digital signature or MAC on the request. 1454 SCVP clients MAY support serverContextInfo, and SCVP servers SHOULD 1455 support serverContextInfo. 1457 3.2.7 validationTime 1459 The optional validationTime item, if present, tells the date and 1460 time relative to which the SCVP client wants the server to perform 1461 the checks. If the validationTime is not present, the server MUST 1462 perform the validation using the date and time at which the server 1463 processes the request. If the validationTime is present, it MUST be 1464 encoded as GeneralizedTime. The validationTime provided MUST be a 1465 retrospective time since the server can only perform a validity 1466 check using the current time (default) or previous time. A server 1467 can ignore the validationTime provided in the request if the time is 1468 within the clock skew of the server's current time. 1470 The revocation status information is obtained with respect to the 1471 validation time. When specifying a validation time other than the 1472 current time, the validation time should not necessarily be 1473 identical to the time when the private key was used. The validation 1474 time specified by the client may be adjusted to compensate for: 1476 1) time for the end-entity to realize that its private key has 1477 been or could possibly be compromised, and/or 1479 2) time for the end-entity to report the key compromise, and/or 1481 3) time for the revocation authority to process the revocation 1482 request from the end-entity, and/or 1484 4) time for the revocation authority to update and distribute 1485 the revocation status information. 1487 GeneralizedTime values MUST be expressed in Universal Coordinated 1488 Time (UTC) (which is also known as Greenwich Mean Time and Zulu 1489 time) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), 1490 even when the number of seconds is zero. GeneralizedTime values 1491 MUST NOT include fractional seconds. 1493 The information in the corresponding CertReply item in the response 1494 MUST be formatted as if the server created the response at the time 1495 indicated in the validationTime. However, if the server does not 1496 have appropriate historical information, the server MUST return an 1497 error response. 1499 SCVP servers MUST apply a clock skew to the validity time to allow 1500 for minor time synchronization errors. The default value is 10 1501 minutes. If the server uses a value other than the default it MUST 1502 include the clock skew value in the validation policy response. 1504 SCVP clients MAY support validationTime other than the current time. 1505 SCVP servers MUST support using its current time, and SHOULD support 1506 the client setting the validationTime in the request. 1508 3.2.8 intermediateCerts 1510 The optional intermediateCerts item may help the SCVP server create 1511 valid certification paths. The intermediateCerts item, when 1512 present, provides certificates that the server MAY use when forming 1513 a certification path. When building certification paths, the server 1514 MAY use the certificates in the intermediateCerts item in addition 1515 to any other certificates that the server can access. When present, 1516 the intermediateCerts item MUST contain at least one certificate, 1517 and the intermediateCerts item MUST be structured as a CertBundle. 1518 The certificates in the intermediateCerts item MUST NOT be 1519 considered as valid by the server just because they are present in 1520 this item. 1522 The CertBundle type contains one or more certificates. The order of 1523 the entries in the bundle is not important. CertBundle has the 1524 following syntax: 1526 CertBundle ::= SEQUENCE SIZE (1..MAX) OF Certificate 1528 SCVP clients SHOULD support intermediateCerts, and SCVP servers MUST 1529 support intermediateCerts. 1531 3.2.9 revInfos 1533 The optional revInfos item specifies revocation information such as 1534 CRLs, delta CRLs [PKIX-1], and OCSP responses [OCSP] that the SCVP 1535 server MAY use when validating certification paths. The purpose of 1536 the revInfos item is to provide revocation information to which the 1537 server might not otherwise have access, such as an OCSP response 1538 that the client received along with the certificate. Note that the 1539 information in the revInfos item might not be used by the server. 1540 For example, the revocation information might be associated with 1541 certificates that the server does not use in the certification path 1542 that it constructs. 1544 Clients SHOULD be courteous to the SCVP server by separating CRLs 1545 and delta CRLs. However, since the two share a common syntax, SCVP 1546 servers SHOULD accept delta CRLs even if they are identified as 1547 regular CRLs by the SCVP client. 1549 CRLs, delta CRLs, and OCSP responses can be provided as revocation 1550 information. If needed, additional object identifiers can be 1551 assigned for additional revocation information types in the future. 1553 The revInfos item uses the RevocationInfos type, which has the 1554 following syntax: 1556 RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo 1558 RevocationInfo ::= CHOICE { 1559 crl [0] CertificateList, 1560 delta-crl [1] CertificateList, 1561 ocsp [2] OCSPResponse, 1562 other [3] OtherRevInfo } 1564 OtherRevInfo ::= SEQUENCE { 1565 riType OBJECT IDENTIFIER, 1566 riValue ANY DEFINED BY riType } 1568 3.2.10 producedAt 1570 The client MAY allow the server to use a cached SCVP response. When 1571 doing so, the client MAY use the producedAt item to express 1572 requirements on the freshness of the cached response. The 1573 producedAt item tells the earliest date and time at which an 1574 acceptable cached response could have been produced. The producedAt 1575 item represents the date and time in UTC, using the GeneralizedTime 1576 type. The value in the producedAt item is independent of the 1577 validation time. 1579 GeneralizedTime value MUST be expressed in UTC, as defined in 1580 section 3.2.7. 1582 SCVP clients MAY support using producedAt values in the request. 1583 SCVP servers MAY support the producedAt values in the request. SCVP 1584 servers that support cached responses SHOULD support the producedAt 1585 value in requests. 1587 3.2.11 queryExtensions 1589 The optional queryExtensions item contains Extensions. If present, 1590 each extension in the sequence extends the query. This 1591 specification does not define any extensions; the facility is 1592 provided to allow future specifications to extend SCVP. The syntax 1593 for extensions is imported from [PKIX-1]. The queryExtensions item, 1594 when present, MUST contain a sequence of extension items, and each 1595 of the extensions MUST contain extnID, critical, and extnValue 1596 items. Each of these is described in the following sections. 1598 3.2.11.1 extnID 1600 The extnID item is an identifier for the extension. It contains the 1601 object identifier that names the extension. 1603 3.2.11.2 critical 1605 The critical item is a BOOLEAN. Each extension is designated as 1606 either critical (with a value of TRUE) or non-critical (with a value 1607 of FALSE). By default, the extension is non-critical. An SCVP 1608 server MUST reject the query if it encounters a critical extension 1609 that it does not recognize; however, a non-critical extension MAY be 1610 ignored if it is not recognized, but MUST be processed if it is 1611 recognized. 1613 3.2.11.3 extnValue 1615 The extnValue item is an octet string, which contains the extension 1616 value. An ASN.1 type is specified for each extension, identified by 1617 the associated extnID object identifier. 1619 3.3 requestorRef 1621 The optional requestorRef item contains a list of names identifying 1622 SCVP servers, and it is intended for use in environments where SCVP 1623 relay is employed. Although requestorRef is encoded as a SEQUENCE, 1624 no order is implied. The requestorRef item is used to detect 1625 looping in some configurations. The value and use of requestorRef 1626 is defined in section 7. 1628 Conforming SCVP clients MAY support specification of the 1629 requestorRef value. Conforming SCVP server implementations MUST 1630 process the requestorRef value if present. If the SCVP client 1631 includes a requestorRef value in the request, then the SCVP server 1632 MUST return the same value in a non-cached response. The SCVP 1633 server MAY omit the requestorRef value from cached SCVP responses. 1635 The requestorRef item MUST be a sequence of GeneralName. No 1636 provisions are made to ensure uniqueness of the requestorRef 1637 GeneralName values. 1639 3.4 requestNonce 1641 The optional requestNonce item contains a request identifier 1642 generated by the SCVP client. If the client includes a requestNonce 1643 value in the request, it is expressing a preference that the SCVP 1644 server SHOULD return a non-cached response. If the server returns a 1645 non-cached response it MUST include the value of requestNonce from 1646 the request in the response as the respNonce item; however, the 1647 server MAY return a cached response which MUST NOT have a respNonce. 1649 SCVP clients that insist on creation of a fresh response (e.g., to 1650 protect against a replay attack or ensure information is up to date) 1651 MUST support requestNonce. Conforming SCVP server implementations 1652 MUST process the requestNonce value if present. 1654 If the client includes a requestNonce and also sets the 1655 cachedResponse flag to FALSE as defined in section 3.2.5.4, the 1656 client is indicating that the SCVP server MUST return either a non- 1657 cached response including the respNonce or an error response. The 1658 client SHOULD include a requestNonce item in every request to 1659 prevent an attacker from acting as a man-in-the-middle by replaying 1660 old responses from the server. The requestNonce value SHOULD change 1661 with every request sent by the client. 1663 The client MUST NOT set the cachedResponse flag to FALSE without 1664 also including a requestNonce. A server receiving such a request 1665 SHOULD return an invalidRequest error response. 1667 The requestNonce item, if present, MUST be an octet string that was 1668 generated exclusively for this request. 1670 3.5 requestorName 1672 The optional requestorName item is used by the client to include an 1673 identifier in the request. The client MAY include this information 1674 for the DPV server to copy into the response. 1676 Conforming SCVP clients MAY support specification of this item in 1677 requests. SCVP servers MUST be able to process requests that 1678 include this item. 1680 3.6 responderName 1682 The optional responderName item is used by the client to indicate 1683 the identity of the SCVP server that the client expects to sign the 1684 SCVP response if the response is digitally signed. The 1685 responderName item SHOULD only be included if: 1687 1. the request is either unprotected or digitally signed (i.e., is 1688 not protected using a MAC); and 1689 2. the responseFlags item is either absent or present with the 1690 protectResponse set to TRUE. 1692 Conforming SCVP clients MAY support specification of this item in 1693 requests. SCVP servers MUST be able to process requests that 1694 include this item. SCVP servers that maintain a single private key 1695 for signing SCVP responses or that are unable to return digitally 1696 signed responses MAY ignore the value in this item. SCVP servers 1697 that maintain more than one private key for signing SCVP responses 1698 SHOULD either (a) digitally sign the response using a private key 1699 that corresponds to a certificate that includes the name specified 1700 in responderName in either subject field or subjectAltName extension 1701 or (b) return a error indicating that the server does not possess a 1702 certificate that asserts the specified name. 1704 3.7 requestExtensions 1706 The OPTIONAL requestExtensions item contains Extensions. If 1707 present, each Extension in the sequence extends the request. This 1708 specification does not define any extensions; the facility is 1709 provided to allow future specifications to extend SCVP. The syntax 1710 for Extensions is imported from [PKIX-1]. The requestExtensions 1711 item, when present, MUST contain a sequence of extension items, and 1712 each of extension MUST contain extnID, critical, and extnValue 1713 items. Each of these is described in the following sections. 1715 3.7.1 extnID 1717 The extnID item is an identifier for the extension. It contains the 1718 object identifier that names the extension. 1720 3.7.2 critical 1722 The critical item is a BOOLEAN. Each extension is designated as 1723 either critical (with a value of TRUE) or non-critical (with a value 1724 of FALSE). By default, the extension is non-critical. An SCVP 1725 server MUST reject the query if it encounters a critical extension 1726 it does not recognize. A non-critical extension MAY be ignored if it 1727 is not recognized, but MUST be processed if it is recognized. 1729 3.7.3 extnValue 1731 The extnValue item contains an octet string. Within the octet 1732 string is the extension value. An ASN.1 type is specified for each 1733 extension, identified by the associated extnID object identifier. 1735 3.8 signatureAlg 1737 The signatureAlg item contains an AlgorithmIdentifier indicating 1738 which algorithm the server should use to sign the response message. 1739 The signatureAlg item SHOULD only be included if: 1741 1. the request is either unprotected or digitally signed (i.e., is 1742 not protected using a MAC); and 1743 2. the responseFlags item is either absent or present with the 1744 protectResponse set to TRUE. 1746 If included, the signatureAlg item SHOULD specify one of the 1747 signature algorithms specified in the signatureGeneration item of 1748 the server's validation policy response message. 1750 SCVP servers MUST be able to process requests that include this 1751 item. If the server is returning a digitally signed response to 1752 this message, then: 1754 1. If the signatureAlg item is present and specifies an algorithm 1755 that is included in the signatureGeneration item of the 1756 server's validation policy response message, the server MUST 1757 sign the response using the signature algorithm specified in 1758 signatureAlg. 1760 2. Otherwise, if the signatureAlg item is absent or is present but 1761 specifies an algorithm that is not supported by the server, the 1762 server MUST sign the response using the server's default 1763 signature algorithm as specified in the signatureGeneration 1764 item of the server's validation policy response message. 1766 3.9 hashAlg 1768 The hashAlg item contains an OBJECT IDENTIFIER indicating which hash 1769 algorithm the server should use to compute the hash value for the 1770 requestHash item in the response. SCVP clients SHOULD NOT include 1771 this item if fullRequestInResponse is set to TRUE. If included, the 1772 hashAlg item SHOULD specify one of the hash algorithms specified in 1773 the hashAlgorithms item of the server's validation policy response 1774 message. 1776 SCVP servers MUST be able to process requests that include this 1777 item. If the server is returning a response to this message that 1778 includes a requestHash then: 1780 1. If the hashAlg item is present and specifies an algorithm that 1781 is included in the hashAlgorithms item of the server's 1782 validation policy response message, the server MUST use the 1783 algorithm specified in hashAlg to compute the requestHash. 1785 2. Otherwise, if the hashAlg item is absent or is present but 1786 specifies an algorithm that is not supported by the server, the 1787 server MUST compute the requestHash using the server's default 1788 hash algorithm as specified in the hashAlgorithms item of the 1789 server's validation policy response message. 1791 3.10 RequestorText 1793 SCVP clients MAY use the requestor Text item to provide text for 1794 inclusion in the corresponding response. For example, this field 1795 may describe the nature or reason for the request. 1797 Conforming SCVP client implementations MAY support inclusion of this 1798 item in requests. Conforming SCVP Server implementations MUST 1799 accept requests that include this item. When generating non-cached 1800 responses, conforming SCVP Server implementations MUST copy the 1801 contents of this item into the requestorText item in the 1802 corresponding response (see Section 4.13). 1804 3.11 SCVP Request Authentication 1806 It is a matter of local policy what validation policy the server 1807 uses when authenticating requests. When authenticating protected 1808 SCVP requests, the SCVP servers SHOULD use the validation algorithm 1809 defined in section 6 of [PKIX-1]. 1811 If the certificate used to validate a SignedData validation request 1812 includes the key usage extension [PKIX-1, section 4.2.1.3], it MUST 1813 have either the digital signature bit set, the non-repudiation bit 1814 set, or both bits set. 1816 If the certificate used to validate an AuthenticatedData validation 1817 request includes the key usage extension, it MUST have the key 1818 agreement bit set. 1820 If the certificate used on a validation request contains the 1821 extended key usage extension [PKIX-1, section 4.2.1.13], the server 1822 SHALL verify that it contains the SCVP client OID or another OID 1823 acceptable to the server. The SCVP client OID is defined as 1824 follows: 1826 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 1828 id-kp-scvpClient OBJECT IDENTIFIER ::= { id-kp 16 } 1830 If a protected request fails to meet the validation policy of the 1831 server, it MUST be treated as an unauthenticated request. 1833 4 Validation Response 1835 An SCVP server response to the client MUST be a single CVResponse 1836 item. When a CVResponse is encapsulated in a MIME body part, 1837 application/cv-response MUST be used. 1839 There are a number of forms of an SCVP response: 1841 1. A success response to a request made over a protected transport 1842 such as TLS. These responses SHOULD NOT be protected by the 1843 server. 1845 2. A success response to a request that has protectResponse set to 1846 FALSE. These responses SHOULD NOT be protected by the server. 1848 3. The server MUST protect all other success responses. If the 1849 server is unable to return a protected success response due to 1850 local policy, then it MUST return an error response. 1852 4. An error response to a request made over a protected transport 1853 such as TLS. These responses SHOULD NOT be protected by the 1854 server 1856 5. An error response to a request that has protectResponse set to 1857 FALSE. These responses SHOULD NOT be protected by the server. 1859 6. An error response to an authenticated request. The server 1860 SHOULD protect these responses. 1862 7. An error response to an AuthenticatedData request where MAC is 1863 valid. The server MUST protect these responses. 1865 8. All other error responses MUST NOT be protected by the server. 1867 Successful responses are made when the server has fully complied 1868 with the request. That is, the server was able to build a 1869 certification path using the referenced or supplied validation 1870 policy, and it was able to comply with all the requested parameters. 1871 If the server is unable to perform validations using the required 1872 validation policy or the request contains an unsupported option, 1873 then the server MUST return an error response. 1875 For protected requests and responses, SCVP servers MUST support 1876 SignedData and SHOULD support AuthenticatedData. It is a matter of 1877 local policy which types are used. 1879 If the server is making a protected response to a protected request, 1880 then the server MUST use the same protection mechanism (SignedData 1881 or AuthenticatedData) as in the request. 1883 An overview of the structure used for an unprotected response is 1884 provided below. Many details are not shown, but the way that SCVP 1885 makes use of CMS is clearly illustrated. 1887 ContentInfo { 1888 contentType id-ct-scvp-certValResponse, 1889 -- (1.2.840.113549.1.9.16.1.11) 1890 content CVResponse } 1892 The protected response consists of a CVResponse encapsulated in 1893 either a SignedData or an AuthenticatedData, which is in turn 1894 encapsulated in a ContentInfo. That is, the EncapsulatedContentInfo 1895 field of either SignedData or AuthenticatedData consists of an 1896 eContentType field with a value of id-ct-scvp-certValResponse and an 1897 eContent field that contains a DER encoded CVResponse. 1899 The SCVP server MUST include its own certificate in the certificates 1900 field within SignedData. Other certificates MAY also be included. 1901 The SCVP server MAY also provide one or more CRLs in the crls field 1902 within SignedData. The signerInfos field of SignedData MUST include 1903 exactly one SignerInfo. The SignedData MUST NOT include the 1904 unsignedAttrs field. 1906 The signedAttrs field within SignerInfo MUST include the content- 1907 type and message-digest attributes defined in [CMS], and it SHOULD 1908 include the signing-certificate attribute as defined in [ESS]. 1909 Within the signing-certificate attribute, the first certificate 1910 identified in the sequence of certificate identifiers MUST be the 1911 certificate of the SCVP server. The inclusion of other certificate 1912 identifiers in the signing-certificate attribute is OPTIONAL. The 1913 inclusion of policies in the signing-certificate is OPTIONAL. 1915 The recipientInfos field of AuthenticatedData MUST include exactly 1916 one RecipientInfo, which contains information for the client that 1917 sent the request. The AuthenticatedData MUST NOT include the 1918 unauthAttrs field. 1920 The CVResponse item contains the server's response. The CVResponse 1921 MUST contain the cvResponseVersion, serverConfigurationID, 1922 producedAt, and responseStatus items. The CVResponse MAY also 1923 contain the respValidationPolicy, requestRef, requestorRef, 1924 requestorName, replyObjects, respNonce, serverContextInfo, and 1925 cvResponseExtensions items. The replyObjects item MUST contain 1926 exactly one CertReply item for each certificate requested. The 1927 requestorRef item MUST be included if the request included a 1928 requestorRef item and a non-cached response is provided. The 1929 respNonce item MUST be included if the request included a 1930 requestNonce item and a non-cached response is provided. 1932 The CVResponse MUST have the following syntax: 1934 CVResponse ::= SEQUENCE { 1935 cvResponseVersion INTEGER, 1936 serverConfigurationID INTEGER, 1937 producedAt GeneralizedTime, 1938 responseStatus ResponseStatus, 1939 respValidationPolicy [0] RespValidationPolicy OPTIONAL, 1940 requestRef [1] RequestReference OPTIONAL, 1941 requestorRef [2] GeneralNames OPTIONAL, 1942 requestorName [3] GeneralNames OPTIONAL, 1943 replyObjects [4] ReplyObjects OPTIONAL, 1944 respNonce [5] OCTET STRING OPTIONAL, 1945 serverContextInfo [6] OCTET STRING OPTIONAL, 1946 cvResponseExtensions [7] Extensions OPTIONAL, 1947 requestorText [8] UTF8String (SIZE (1..256)) OPTIONAL } 1949 Conforming SCVP servers MAY be capable of constructing a CVResponse 1950 that includes the serverContextInfo or cvResponseExtensions items. 1951 Conforming SCVP servers MUST be capable of constructing a CVResponse 1952 with any of the remaining optional items. Conforming SCVP clients 1953 MUST be capable of processing a CVResponse with the following 1954 optional items: respValidationPolicy; requestRef; requestorName; 1955 replyObjects; and respNonce. 1957 Conforming SCVP clients that are capable of including requestorRef 1958 in a request MUST be capable of processing a CVResponse that 1959 includes the requestorRef item. Conforming SCVP clients MUST be 1960 capable of processing a CVResponse that includes the 1961 serverContextInfo or cvResponseExtensions items. Conforming clients 1962 MUST be able to determine if critical extensions are present in the 1963 cvResponseExtensions item. 1965 4.1 cvResponseVersion 1967 The syntax and semantics of cvResponseVersion are the same as 1968 cvRequestVersion as described in section 3.1. The cvResponseVersion 1969 MUST match the cvRequestVersion in the request. If the server 1970 cannot generate a response with a matching version number, then the 1971 server MUST return an error response that indicates the highest 1972 version number that the server supports as the version number. 1974 4.2 serverConfigurationID 1976 The server configuration ID represents the version of the SCVP 1977 server configuration when it processed the request. See section 6.4 1978 for details. 1980 4.3 producedAt 1982 The producedAt item tells the date and time at which the SCVP server 1983 generated the response. The producedAt item MUST be expressed in 1984 UTC, and it MUST be interpreted as defined in section 3.2.7. This 1985 value is independent of the validation time. 1987 4.4 responseStatus 1989 The responseStatus item gives status information to the SCVP client 1990 about its request. The responseStatus item has a numeric status 1991 code and an optional string that is a sequence of characters from 1992 the ISO/IEC 10646-1 character set encoded with the UTF-8 1993 transformation format defined in [UTF8]. 1995 The string MAY be used to transmit status information. The client 1996 MAY choose to display the string to a human user. However, because 1997 there is often no way to know the languages understood by a human 1998 user, the string may be of little or no assistance. 2000 The responseStatus item uses the ResponseStatus type, which has the 2001 following syntax: 2003 ResponseStatus ::= SEQUENCE { 2004 statusCode CVStatusCode DEFAULT okay, 2005 errorMessage UTF8String OPTIONAL } 2007 CVStatusCode ::= ENUMERATED { 2008 okay (0), 2009 skipUnrecognizedItems (1), 2010 tooBusy (10), 2011 invalidRequest (11), 2012 internalError (12), 2013 badStructure (20), 2014 unsupportedVersion (21), 2015 abortUnrecognizedItems (22), 2016 unrecognizedSigKey (23), 2017 badSignatureOrMAC (24), 2018 unableToDecode (25), 2019 notAuthorized (26), 2020 unsupportedChecks (27), 2021 unsupportedWantBacks (28), 2022 unsupportedSignatureOrMAC (29), 2023 invalidSignatureOrMAC (30), 2024 protectedResponseUnsupported (31), 2025 unrecognizedResponderName (32), 2026 relayingLoop (40), 2027 unrecognizedValPol (50), 2028 unrecognizedValAlg (51), 2029 fullRequestInResponseUnsupported (52), 2030 fullPolResponseUnsupported (53), 2031 inhibitPolicyMappingUnsuported (54), 2032 requireExplicitPolicyUnsupported (55), 2033 inhibitAnyPolicyUnsupported (56), 2034 validityTimeUnsupported (57), 2035 unrecognizedCritQueryExt (63), 2036 unrecognizedCritRequestExt (64) } 2038 The CVStatusCode values have the following meaning: 2040 0 The request was fully processed. 2041 1 The request included some unrecognized non-critical extensions; 2042 however, processing was able to continue ignoring them. 2043 10 Too busy; try again later. 2044 11 The server was able to decode the request, but there was some 2045 other problem with the request. 2046 12 An internal server error occurred. 2047 20 The structure of the request was wrong. 2048 21 The version of request is not supported by this server. 2049 22 The request included unrecognized items, and the server was not 2050 able to continue processing. 2051 23 The server could not validate the key used to protect the 2052 request. 2053 24 The signature or message authentication code did not match the 2054 body of the request. 2055 25 The encoding was not understood. 2056 26 The request was not authorized. 2057 27 The request included unsupported checks items, and the server 2058 was not able to continue processing. 2059 28 The request included unsupported want back items, and the 2060 server was not able to continue processing. 2061 29 The server does not support the signature or message 2062 authentication code algorithm used by the client to protect the 2063 request. 2064 30 The server could not validate the client's signature or message 2065 authentication code on the request. 2066 31 The server could not generate a protected response as requested 2067 by the client. 2068 32 The server does not have a certificate matching the requested 2069 responder name. 2070 40 The request was previously relayed by the same server. 2072 50 The request contained an unrecognized validation policy 2073 reference. 2074 51 The request contained an unrecognized validation algorithm OID. 2075 52 The server does not support returning the full request in the 2076 response. 2077 53 The server does not support returning the full validation 2078 policy by value in the response. 2079 54 The server does not support inhibiting policy mapping. 2080 55 The server does not support requiring explicit policy. 2081 56 The server does not support ignoring the anyPolicy certificate 2082 policy OID. 2083 57 The server only validates requests using current time. 2084 63 The query item in the request contains a critical extension 2085 whose OID is not recognized. 2086 64 The request contains a critical request extension whose OID is 2087 not recognized. 2089 Status codes 0-9 are reserved for codes that indicate the request 2090 was processed by the server and therefore MUST be sent in a success 2091 response. Status codes 10 and above indicate an error and MUST 2092 therefore be sent in an error response. 2094 4.5 respValidationPolicy 2096 The respValidationPolicy item contains either a reference to the 2097 full validation policy or the full policy by value used by the 2098 server to validate the request. It MUST be present in success 2099 responses and MUST NOT be present in error responses. The choice 2100 between returning the policy by reference or by value is controlled 2101 by the responseValidationPolByRef item in the request. The 2102 resultant validation policy is the union of the following: 2104 1. Values from the request. 2106 2. For values that are not explicitly included in the request, 2107 values from the validation policy specified by reference in 2108 the request. 2110 The RespValidationPolicy syntax is: 2112 RespValidationPolicy ::= ValidationPolicy 2114 The validationPolicy item is defined in section 3.2.4. When 2115 responseValidationPolByRef is set to FALSE in the request, all items 2116 in the validationPolicy item MUST be populated. When 2117 responseValidationPolByRef is set to TRUE, OPTIONAL items in the 2118 validationPolicy item only need to be populated for items for which 2119 the value in the request differs from the value from the referenced 2120 validation policy. 2122 Conforming SCVP clients MUST be capable of processing the validation 2123 policy by reference. SCVP clients MAY be capable of processing the 2124 optional items in the validation policy. 2126 Conforming SCVP server implementations MUST be capable of asserting 2127 the policy by reference, and MUST be capable of including the 2128 optional items. 2130 4.6 requestRef 2132 The requestRef item allows the SCVP client to identify the request 2133 that corresponds to this response from the server. It associates 2134 the response to a particular request using either a hash of the 2135 request or a copy of CVRequest from the request. 2137 The requestRef item does not provide authentication, but does allow 2138 the client to determine that the request was not maliciously 2139 modified. 2141 The requestRef item allows the client to associate a response with a 2142 request. The requestNonce provides an alternative mechanism for 2143 matching requests and responses. When the fullRequest alternative 2144 is used, the response provides a single data structure that is 2145 suitable for archive of the transaction. 2147 The requestRef item uses the RequestReference type, which has the 2148 following syntax: 2150 RequestReference ::= CHOICE { 2151 requestHash [0] HashValue, -- hash of CVRequest 2152 fullRequest [1] CVRequest } 2154 SCVP clients MUST support requestHash, and they MAY support 2155 fullRequest. SCVP servers MUST support using requestHash, and they 2156 SHOULD support using fullRequest. 2158 4.6.1 requestHash 2160 The requestHash item is the hash of the CVRequest. The one-way hash 2161 function used to compute the hash of the CVRequest is as specified 2162 in section 3.9. The requestHash item serves two purposes. First, 2163 it allows a client to determine that the request was not maliciously 2164 modified. Second, it allows the client to associate a response with 2165 a request when using connectionless protocols. The requestNonce 2166 provides an alternative mechanism for matching requests and 2167 responses. 2169 The requestHash item uses the HashValue type, which has the 2170 following syntax: 2172 HashValue ::= SEQUENCE { 2173 algorithm AlgorithmIdentifier DEFAULT { sha-1 }, 2174 value OCTET STRING } 2176 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 2177 oiw(14) secsig(3) algorithm(2) 26 } 2179 The algorithm identifier for SHA-1 is imported from [PKIX-ALG]. It 2180 is repeated here for convenience. 2182 4.6.2 fullRequest 2184 Like requestHash, the fullRequest alternative allows a client to 2185 determine that the request was not maliciously modified. It also 2186 provides a single data structure that is suitable for archive of the 2187 transaction. 2189 The fullRequest item uses the CVRequest type. The syntax and 2190 semantics of the CVRequest type are described in section 3. 2192 4.7 requestorRef 2194 The optional requestorRef item is used by the client to identify the 2195 original requestor in cases where SCVP relay is used. The value is 2196 only of local significance to the client. If the SCVP client 2197 includes a requestorRef value in the request, then the SCVP server 2198 MUST return the same value if the server is generating a non-cached 2199 response. 2201 4.8 requestorName 2203 The optional requestorName item is used by the server to return one 2204 or more identities associated with the client in the response. 2206 The SCVP server MAY choose to include any or all of the following: 2208 (1) the identity asserted by the client in the requestorName item 2209 of the request, 2210 (2) an authenticated identity for the client from a certificate or 2211 other credential used to authenticate the request, or 2212 (3) a client identifier from an out-of-band mechanism. 2214 Alternatively, the SCVP server MAY omit this item. 2216 In the case of non-cached responses to authenticated requests, the 2217 SCVP server SHOULD return a requestor name. 2219 SCVP servers that support authenticated requests SHOULD support this 2220 item. 2222 SCVP clients MUST be able to process responses that include this 2223 item, although the item value might not impact the processing in any 2224 manner. 2226 4.9 replyObjects 2228 The replyObjects item returns requested objects to the SCVP client, 2229 each of which tells the client about a single certificate from the 2230 request. The replyObjects item MUST be present in the response, 2231 unless the response is reporting an error. The CertReply item MUST 2232 contain cert, replyStatus, replyValTime, replyChecks, and 2233 replyWantBacks items; and the CertReply item MAY contain the 2234 validationErrors, nextUpdate, and certReplyExtensions items. 2236 A success response MUST contain one CertReply for each certificate 2237 specified in the queriedCerts item in the request. The order is 2238 important. The first CertReply in the sequence MUST correspond to 2239 the first certificate in the request; the second CertReply in the 2240 sequence MUST correspond to the second certificate in the request; 2241 and so on. 2243 The checks item in the request determines the content of the 2244 replyChecks item in the response. The wantBack item in the request 2245 determines the content of the replyWantBacks item in the response. 2246 The queryExtensions items in the request controls the absence or the 2247 presence and content of the certReplyExtensions item in the 2248 response. 2250 The replyObjects item uses the ReplyObjects type, which has the 2251 following syntax: 2253 ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply 2255 CertReply ::= SEQUENCE { 2256 cert CertReference, 2257 replyStatus ReplyStatus DEFAULT success, 2258 replyValTime GeneralizedTime, 2259 replyChecks ReplyChecks, 2260 replyWantBacks ReplyWantBacks, 2261 validationErrors [0] SEQUENCE SIZE (1..MAX) OF 2262 OBJECT IDENTIFIER OPTIONAL, 2263 nextUpdate [1] GeneralizedTime OPTIONAL, 2264 certReplyExtensions [2] Extensions OPTIONAL } 2266 4.9.1 cert 2268 The cert item contains either the certificate or a reference to the 2269 certificate about which the client is requesting information. If 2270 the certificate was specified by reference in the request, the 2271 request included either the id-swb-pkc-cert or id-swb-aa-cert 2272 wantBack, and the server was able to obtain the referenced 2273 certificate then this item MUST include the certificate. Otherwise, 2274 this item MUST include the same value as was used in the 2275 queriedCerts item in the request. 2277 CertReference has the following syntax: 2279 CertReference ::= CHOICE { 2280 pkc PKCReference, 2281 ac ACReference } 2283 4.9.2 replyStatus 2285 The replyStatus item gives status information to the client about 2286 the request for the specific certificate. Note that the 2287 responseStatus item is different than the replyStatus item. The 2288 responseStatus item is the status of the whole request, while the 2289 replyStatus item is the status for the individual query item. 2291 The replyStatus item uses the ReplyStatus type, which has the 2292 following syntax: 2294 ReplyStatus ::= ENUMERATED { 2295 success (0), 2296 malformedPKC (1), 2297 malformedAC (2), 2298 unavailableValidityTime (3), 2299 referenceCertHashFail (4), 2300 certPathConstructFail (5), 2301 certPathNotValid (6), 2302 certPathNotValidNow (7), 2303 wantBackUnsatisfied (8) } 2305 The meaning of the various ReplyStatus values are: 2307 0 Success: all checks were performed successfully. 2308 1 Failure: the public key certificate was malformed. 2309 2 Failure: the attribute certificate was malformed. 2310 3 Failure: historical data for the requested validity time is not 2311 available. 2312 4 Failure: the server could not locate the reference certificate or 2313 the referenced certificate did not match the hash value 2314 provided. 2316 5 Failure: no certification path could be constructed. 2317 6 Failure: the constructed certification path is not valid with 2318 respect to the validation policy. 2319 7 Failure: the constructed certification path is not valid with 2320 respect to the validation policy, but a query at a later time 2321 may be successful. 2322 8 Failure: all checks were performed successfully, however one or 2323 more of the wantBacks could not be satisfied. 2325 Codes 1 and 2 are used to tell the client that the request was 2326 properly formed, but the certificate in question was not. This is 2327 especially useful to clients that do not parse certificates. 2329 Code 7 is used to tell the client that a valid certification path 2330 was found with the exception that a certificate in the path is on 2331 hold, current revocation information is unavailable, or the 2332 validation time precedes the notBefore time in one or more 2333 certificates in the path. 2335 For codes 1, 2, 3, and 4, the replyChecks and replyWantBacks items 2336 are not populated (i.e., they MUST be an empty sequence). For codes 2337 5, 6, 7, and 8 replyChecks MUST include an entry corresponding to 2338 each check in the request; the replyWantBacks item is not populated. 2340 4.9.3 replyValTime 2342 The replyValTime item tells the time at which the information in the 2343 CertReply was correct. The replyValTime item represents the date 2344 and time in UTC, using GeneralizedTime type. The encoding rules for 2345 GeneralizedTime in section 3.2.7 MUST be used. 2347 Within the request, the optional validityTime item tells the date 2348 and time relative to which the SCVP client wants the server to 2349 perform the checks. If the validityTime is not present, the server 2350 MUST respond as if the client provided the date and time at which 2351 the server processes the request. 2353 The information in the CertReply item MUST be formatted as if the 2354 server created this portion of the response at the time indicated in 2355 the validityTime item of the query. However, if the server does not 2356 have appropriate historical information, the server MAY either 2357 return an error or return information for a later time. 2359 4.9.4 replyChecks 2361 The replyChecks item contains the responses to the checks item in 2362 the query. The replyChecks item includes the object identifier 2363 (OID) from the query and an integer. The value of the integer 2364 indicates whether the requested check was successful. The OIDs in 2365 the checks item of the query are used to identify the corresponding 2366 replyChecks values. Each OID specified in the checks item in the 2367 request MUST be matched by an OID in the replyChecks item of the 2368 response. In the case of an error response, the server MAY include 2369 additional checks in the response to further explain the error. 2370 Clients MUST ignore any unrecognized ReplyCheck included in the 2371 response. 2373 The replyChecks item uses the ReplyChecks type, which has the 2374 following syntax: 2376 ReplyChecks ::= SEQUENCE OF ReplyCheck 2378 ReplyCheck ::= SEQUENCE { 2379 check OBJECT IDENTIFIER, 2380 status INTEGER DEFAULT 0 } 2382 The status value for public key certification path building to a 2383 trusted root, { id-stc 1 }, can be one of the following: 2385 0: Built a path 2386 1: Could not build a path 2388 The status value for public key certification path building to a 2389 trusted root along with simple validation processing, { id-stc 2 }, 2390 can be one of the following: 2392 0: Valid 2393 1: Not valid 2395 The status value for public key certification path building to a 2396 trusted root along with complete status checking, { id-stc 3 }, can 2397 be one of the following: 2399 0: Valid 2400 1: Not valid 2401 2: Revocation Offline 2402 3: Revocation Unavailable 2403 4: No known source for revocation information 2405 Revocation offline means that the server or distribution point for 2406 the revocation information was connected to successfully without a 2407 network error but either no data was returned or if data was 2408 returned it was stale. Revocation unavailable means that a network 2409 error was returned when an attempt was made to reach the server or 2410 distribution point. No known source for revocation information 2411 means that the server was able to build a valid certification path 2412 but was unable to locate a source for revocation information for one 2413 or more certificates in the path. 2415 The status value for AC issuer certification path building to a 2416 trusted root, { id-stc 4 }, can be one of the following: 2418 0: Built a path 2419 1: Could not build a path 2421 The status value for AC issuer certification path building to a 2422 trusted root along with simple validation processing, { id-stc 5 }, 2423 can be one of the following: 2425 0: Valid 2426 1: Not valid 2428 The status value for AC issuer certification path building to a 2429 trusted root along with complete status checking, { id-stc 6 }, can 2430 be one of the following: 2432 0: Valid 2433 1: Not Valid 2434 2: Revocation Offline 2435 3: Revocation Unavailable 2436 4: No known source for revocation information 2438 The status value for revocation status checking of an AC as well as 2439 AC issuer certification path building to a trusted root along with 2440 complete status checking, { id-stc 7 }, can be one of the following: 2442 0: Valid 2443 1: Not Valid 2444 2: Revocation Offline 2445 3: Revocation Unavailable 2446 4: No known source for revocation information 2448 4.9.5 replyWantBacks 2450 The replyWantBacks item contains the responses to the wantBack item 2451 in the request. The replyWantBacks item includes the object 2452 identifier (OID) from the wantBack item in the request and an octet 2453 string. Within the octet string is the requested value. The OIDs 2454 in the wantBack item in the request are used to identify the 2455 corresponding reply value. The OIDs in the replyWantBacks item MUST 2456 match the OIDs in the wantBack item in the request. For a non-error 2457 response, replyWantBacks MUST include exactly one replyWantBack for 2458 each wantBack specified in the request (excluding id-swb-pkc-cert 2459 and id-swb-ac-cert, where the requested information is included in 2460 the cert item). 2462 The replyWantBacks item uses the ReplyWantBacks type, which has the 2463 following syntax: 2465 ReplyWantBacks ::= SEQUENCE OF ReplyWantBack 2467 ReplyWantBack::= SEQUENCE { 2468 wb OBJECT IDENTIFIER, 2469 value OCTET STRING } 2471 The octet string value for the certification path used to verify the 2472 certificate in the request, { id-swb 1 }, contains the CertBundle 2473 type. The syntax and semantics of the CertBundle type are described 2474 in section 3.2.8. This CertBundle includes all the certificates in 2475 the path, starting with the end certificate and ending with the 2476 certificate issued by the trust anchor. 2478 The octet string value for the proof of revocation status, { id-swb 2479 2 }, contains the RevInfoWantBack type. The RevInfoWantBack type is 2480 a SEQUENCE of the RevocationInfos type and an optional CertBundle. 2481 The syntax and semantics of the RevocationInfos type are described 2482 in section 3.2.9. The CertBundle MUST be included if any 2483 certificates required to validate the revocation information were 2484 not returned in the id-swb-pkc-best-cert-path or id-swb-pkc-all- 2485 cert-paths want back. The CertBundle MUST include all such 2486 certificates but there are no ordering requirements. 2488 RevInfoWantBack ::= SEQUENCE { 2489 revocationInfo RevocationInfos, 2490 extraCerts CertBundle OPTIONAL } 2492 The octet string value for the public key information, { id-swb 4 }, 2493 contains the SubjectPublicKeyInfo type. The syntax and semantics of 2494 the SubjectPublicKeyInfo type are described in [PKIX-1]. 2496 The octet string value for the AC issuer certification path used to 2497 verify the certificate in the request, { id-swb 5 }, contains the 2498 CertBundle type. The syntax and semantics of the CertBundle type 2499 are described in section 3.2.8. This CertBundle includes all the 2500 certificates in the path, beginning with the AC issuer certificate 2501 and ending with the certificate issued by the trust anchor. 2503 The octet string value for the proof of revocation status of the AC 2504 issuer certification path, { id-swb 6 }, contains the 2505 RevInfoWantBack type. The RevInfoWantBack type is a SEQUENCE of the 2506 RevocationInfos type and an optional CertBundle. The syntax and 2507 semantics of the RevocationInfos type are described in section 2508 3.2.9. The CertBundle MUST be included if any certificates required 2509 to validate the revocation information were not returned in the id- 2510 aa-cert-path want back. The CertBundle MUST include all such 2511 certificates but there are no ordering requirements. 2513 The octet string value for the proof of revocation status of the 2514 attribute certificate, { id-swb 7 }, contains the RevInfoWantBack 2515 type. The RevInfoWantBack type is a SEQUENCE of the RevocationInfos 2516 type and an optional CertBundle. The syntax and semantics of the 2517 RevocationInfos type are described in section 3.2.9. The CertBundle 2518 MUST be included if any certificates required to validate the 2519 revocation information were not returned in the id-swb-aa-cert-path 2520 want back. The CertBundle MUST include all such certificates but 2521 there are no ordering requirements. 2523 The octet string value for returning all paths, { id-swb 12 }, 2524 contains an ASN.1 type CertBundles, as defined below. The syntax 2525 and semantics of the CertBundle type are described in section 3.2.8. 2526 Each CertBundle includes all the certificates in one path, starting 2527 the end certificate and ending with the certificate issued by the 2528 trust anchor. 2530 CertBundles ::= SEQUENCE SIZE (1..MAX) OF CertBundle 2532 The octet string value for relayed responses, { id-swb 9 }, contains 2533 an ASN.1 type SCVPResponses, as defined below. If the SCVP server 2534 used information obtained from other SCVP servers when generating 2535 this response, then SCVPResponses MUST include each of the SCVP 2536 responses received from those servers. If the SCVP server did not 2537 use information obtained from other SCVP servers when generating the 2538 response, then SCVPResponses MUST be an empty sequence. 2540 SCVPResponses ::= SEQUENCE OF ContentInfo 2542 The octet string value for the proof of revocation status of the 2543 path's target certificate, { id-swb-13 }, contains the 2544 RevInfoWantBack type. The RevInfoWantBack type is a SEQUENCE of the 2545 RevocationInfos type and an optional CertBundle. The syntax and 2546 semantics of the RevocationInfos type are described in section 2547 3.2.9. The CertBundle MUST be included if any certificates required 2548 to validate the revocation information were not returned in the id- 2549 swb-pkc-best-cert-path or id-swb-pkc-all-cert-paths want back. The 2550 CertBundle MUST include all such certificates but there are no 2551 ordering requirements. 2553 The octet string value for the proof of revocation status of the 2554 intermediate certificates in the path, { id-swb 14 }, contains the 2555 RevInfoWantBack type. The RevInfoWantBack type is a SEQUENCE of the 2556 RevocationInfos type and an optional CertBundle. The syntax and 2557 semantics of the RevocationInfos type are described in section 2558 3.2.9. The CertBundle MUST be included if any certificates required 2559 to validate the revocation information were not returned in the id- 2560 swb-pkc-best-cert-path or id-swb-pkc-all-cert-paths want back. The 2561 CertBundle MUST include all such certificates but there are no 2562 ordering requirements. 2564 4.9.6 validationErrors 2566 The validationErrors item MUST only be present in failure responses. 2567 If present, it MUST contain one or more OIDs representing the reason 2568 the validation failed (validation errors for the basic validation 2569 algorithm and name validation algorithm are defined in sections 2570 3.2.4.2.2 and 3.2.4.2.4). The validationErrors item SHOULD only be 2571 included when the replyStatus is 3, 5, 6, 7, or 8. SCVP servers are 2572 not required to specify all of the reasons that validation failed. 2573 SCVP clients MUST NOT assume that the OIDs included in 2574 validationErrors represent all of the validation errors for the 2575 certification path. 2577 4.9.7 nextUpdate 2579 The nextUpdate item tells the time at which the server expects a 2580 refresh of information regarding the validity of the certificate to 2581 become available. The nextUpdate item is especially interesting if 2582 the certificate revocation status information is not available or 2583 the certificate is suspended. The nextUpdate item represents the 2584 date and time in UTC, using the GeneralizedTime type. The encoding 2585 rules for GeneralizedTime in section 3.2.7 MUST be used. 2587 4.9.8 certReplyExtensions 2589 The certReplyExtensions contains the responses to the 2590 queryExtensions item in the request. The certReplyExtensions item 2591 uses the Extensions type defined in [PKIX-1]. The object 2592 identifiers (OIDs) in the queryExtensions item in the request are 2593 used to identify the corresponding reply values. The 2594 certReplyExtensions item, when present, contains a sequence of 2595 Extension items, each of which contains an extnID item, a critical 2596 item, and an extnValue item. 2598 The extnID item is an identifier for the extension. It contains the 2599 OID that names the extension, and it MUST match one of the OIDs in 2600 the queryExtensions item in the request. 2602 The critical item is a BOOLEAN, and it MUST be set to FALSE. 2604 The extnValue item contains an OCTET STRING. Within the OCTET 2605 STRING is the extension value. An ASN.1 type is specified for each 2606 extension, identified by the associated extnID object identifier. 2608 4.10 respNonce 2610 The respNonce item contains an identifier to bind the request to the 2611 response. 2613 If the client includes a requestNonce value in the request and the 2614 server is generating a specific non-cached response to the request 2615 then the server MUST return the same value in the response. 2617 If the server is using a cached response to the request then it MUST 2618 omit the respNonce item. 2620 If the server is returning a specific non-cached response to a 2621 request without a nonce, then the server MAY include a message 2622 specific nonce. For digitally signed messages, the server MAY use 2623 the value of the message-digest attribute in the signedAttrs within 2624 SignerInfo of the request as the value in the respNonce item. 2626 The requestNonce item uses the octet string type. 2628 Conforming client implementations MUST be able to process a response 2629 that includes this item. Conforming servers MUST support respNonce. 2631 4.11 serverContextInfo 2633 The serverContextInfo item in a response is a mechanism for the 2634 server to pass some opaque context information to the client. If 2635 the client does not like the certification path returned, it can 2636 make a new query and pass along this context information. 2638 Section 3.2.6 contains information about the client's usage of this 2639 item. 2641 The context information is opaque to the client, but it provides 2642 information to the server that ensures that a different 2643 certification path will be returned (if another one can be found). 2644 The context information could indicate state of the server or it 2645 could contain a sequence of hashes of certification paths that have 2646 already been returned to the client. The protocol does not dictate 2647 any structure or requirements for this item. However, implementers 2648 should review the Security Considerations section of this document 2649 before selecting a structure. 2651 Servers that are incapable of returning additional paths MUST NOT 2652 include the serverContextInfo item in the response. 2654 4.12 cvResponseExtensions 2655 If present, the cvResponseExtensions item contains a sequence of 2656 Extensions that extend the response. This specification does not 2657 define any extensions. The facility is provided to allow future 2658 specifications to extend SCVP. The syntax for Extensions is 2659 imported from [PKIX-1]. The cvResponseExtensions item, when 2660 present, contains a sequence of Extension items, each of which 2661 contains an extnID item, a critical item, and an extnValue item. 2663 The extnID item is an identifier for the extension. It contains the 2664 object identifier (OID) that names the extension. 2666 The critical item is a BOOLEAN. Each extension is designated as 2667 either critical (with a value of TRUE) or non-critical (with a value 2668 of FALSE). An SCVP client MUST reject the response if it encounters 2669 a critical extension it does not recognize; however, a non-critical 2670 extension MAY be ignored if it is not recognized. 2672 The extnValue item contains an OCTET STRING. Within the OCTET 2673 STRING is the extension value. An ASN.1 type is specified for each 2674 extension, identified by the associated extnID object identifier. 2676 4.13 RequestorText 2678 The requestorText item contains a text field supplied by the client. 2680 If the client includes a requestorText value in the request and the 2681 server is generating a specific non-cached response to the request 2682 then the server MUST return the same value in the response. 2684 If the server is using a cached response to the request then it MUST 2685 omit the requestorText item. 2687 The requestNonce item uses the UTF8 string type. 2689 Conforming client implementations that support the requestorText 2690 item in requests (see Section 3.10) MUST be able to process a 2691 response that includes this item. Conforming servers MUST support 2692 requestorText in responses. 2694 4.14 SCVP Response Validation 2696 There are two mechanisms for validation of SCVP responses, one based 2697 on the client's knowledge of a specific SCVP server key and the 2698 other based on validation of the certificate corresponding to the 2699 private key used to protect the SCVP response. 2701 4.14.1 Simple Key Validation 2702 The simple key validation method is where the SCVP client has a 2703 local policy of one or more SCVP server keys that directly identify 2704 the set of valid SCVP servers. Mechanisms for storage of server 2705 keys or identifiers are a local matter. For example, a client could 2706 store cryptographic hashes of public keys used to verify SignedData 2707 responses. Alternatively, a client could store shared symmetric 2708 keys used to verify MACs in AuthenticatedData responses. 2710 Simple key validation MUST be used by SCVP clients that cannot 2711 validate PKIX-1 certificates and are therefore making delegated path 2712 validation requests to the SCVP server [RQMTS]. It is a matter of 2713 local policy with these clients whether to use SignedData or 2714 AuthenticatedData. Simple key validation MAY be used by other SCVP 2715 clients for other reasons. 2717 4.14.2 SCVP Server Certificate Validation 2719 It is a matter of local policy what validation policy the client 2720 uses when validating responses. When validating protected SCVP 2721 responses, SCVP clients SHOULD use the validation algorithm defined 2722 in section 6 of [PKIX-1]. SCVP clients may impose additional 2723 limitations on the algorithm, such as limiting the number of 2724 certificates in the path or establishing initial name constraints, 2725 as specified in section 6.2 of [PKIX-1]. 2727 If the certificate used to sign the validation policy responses and 2728 SignedData validation responses contains the key usage extension 2729 [PKIX-1 section 4.2.1.3] it MUST have either the digital signature 2730 bit set, the non-repudiation bit set, or both bits set. 2732 If the certificate for AuthenticatedData validation responses 2733 contains the key usage extension it MUST have the key agreement bit 2734 set. 2736 If the certificate used on a validation policy response or a 2737 validation response contains the extended key usage extension [PKIX- 2738 1 section 4.2.1.13] it MUST contain the following OID: 2740 id-kp-scvpServer OBJECT IDENTIFIER ::= { id-kp 15 } 2742 5 Server Policy Request 2744 An SCVP client uses the ValPolRequest item to request information 2745 about an SCVP server's policies and configuration information, 2746 including the list of validation policies supported by the SCVP 2747 server. When a ValPolRequest is encapsulated in a MIME body part, 2748 it MUST be carried in an application/vp-request MIME body part. 2750 The request consists of a ValPolRequest encapsulated in a 2751 ContentInfo. The client does not sign the request. 2753 ContentInfo { 2754 contentType id-ct-scvp-valPolRequest, 2755 -- (1.2.840.113549.1.9.16.1.12) 2756 content ValPolRequest } 2758 The ValPolRequest type has the following syntax: 2760 ValPolRequest ::= SEQUENCE { 2761 vpRequestVersion INTEGER DEFAULT 1, 2762 requestNonce OCTET STRING } 2764 Conforming SCVP server implementations MUST recognize and process 2765 the server policy request. Conforming clients SHOULD support the 2766 server policy request. 2768 5.1 vpRequestVersion 2770 The syntax and semantics of vpRequestVersion are the same as 2771 cvRequestVersion as described in section 3.1. 2773 5.2 requestNonce 2775 The requestNonce item contains a request identifier generated by the 2776 SCVP client. If the server returns a specific response it MUST 2777 include the requestNonce from the request in the response, but the 2778 server MAY return a cached response which MUST NOT include a 2779 requestNonce. 2781 6 Validation Policy Response 2783 In response to a ValPolRequest, the SCVP server provides a 2784 ValPolResponse. The ValPolResponse MAY not be unique to any 2785 ValPolRequest, so may be reused by the server in response to 2786 multiple ValPolRequests. The ValPolResponse also has an indication 2787 of how frequently the ValPolResponse may be reissued. The server 2788 MUST sign the response using its digital signature certificate. 2789 When a ValPolResponse is encapsulated in a MIME body part, it MUST 2790 be carried in an application/vp-response MIME body part. 2792 The response consists of a ValPolResponse encapsulated in a 2793 SignedData, which is in turn encapsulated in a ContentInfo. That 2794 is, the EncapsulatedContentInfo field of SignedData consists of an 2795 eContentType field with a value of id-ct-scvp-valPolResponse 2796 (1.2.840.113549.1.9.16.1.13) and an eContent field that contains a 2797 DER encoded ValPolResponse. The SCVP server MUST include it's own 2798 certificate in the certificates field within SignedData and the 2799 signerInfos field of SignedData MUST include exactly one SignerInfo. 2800 The SignedData MUST NOT include the unsignedAttrs field. 2802 The ValPolResponse type has the following syntax: 2804 ValPolResponse ::= SEQUENCE { 2805 vpResponseVersion INTEGER, 2806 maxCVResponseVersion INTEGER, 2807 maxVPResponseVersion INTEGER, 2808 serverConfigurationID INTEGER, 2809 thisUpdate GeneralizedTime, 2810 nextUpdate GeneralizedTime OPTIONAL, 2811 validationPolicies SEQUENCE OF OBJECT IDENTIFIER, 2812 validationAlgs SEQUENCE OF OBJECT IDENTIFIER, 2813 authPolicies SEQUENCE OF AuthPolicy, 2814 responseTypes ResponseTypes, 2815 defaultPolicyValues RespValidationPolicy, 2816 revocationInfoTypes RevocationInfoTypes, 2817 signatureGeneration SEQUENCE OF AlgorithmIdentifier, 2818 signatureVerification SEQUENCE OF AlgorithmIdentifier, 2819 hashAlgorithms SEQUENCE SIZE (1..MAX) OF 2820 OBJECT IDENTIFIER, 2821 serverPublicKeys SEQUENCE OF KeyAgreePublicKey 2822 OPTIONAL, 2823 clockSkew INTEGER DEFAULT 10, 2824 requestNonce OCTET STRING OPTIONAL } 2826 ResponseTypes ::= ENUMERATED { 2827 cached-only (0), 2828 non-cached-only (1), 2829 cached-and-non-cached (2) } 2831 RevocationInfoTypes ::= BIT STRING { 2832 fullCRLs (0), 2833 deltaCRLs (1), 2834 indirectCRLs (2), 2835 oCSPResponses (3) } 2837 SCVP clients that support validation policy requests MUST support 2838 validation policy responses. SCVP servers MUST support validation 2839 policy responses. 2841 SCVP servers MUST support cached policy responses and MAY support 2842 specific responses to policy requests. 2844 6.1 vpResponseVersion 2846 The syntax and semantics of the vpResponseVersion item are the same 2847 as cvRequestVersion as described in section 3.1. The 2848 vpResponseVersion used MUST be the same as the vpRequestVersion 2849 unless the client has used a value greater than the values the 2850 server supports. If the client submits a vpRequestVersion greater 2851 than the version supported by the server, the server MUST return a 2852 vpResponseVersion using the highest version number the server 2853 supports as the version number. 2855 6.2 maxCVRequestVersion 2857 The maxCVRequestVersion defines the maximum version number for CV 2858 requests that the server supports. 2860 6.3 maxVPRequestVersion 2862 The maxVPRequestVersion defines the maximum version number for VP 2863 requests that the server supports. 2865 6.4 serverConfigurationID 2867 An integer that uniquely represents the version of the server 2868 configuration as represented by the validationPolicies, 2869 validationAlgs, authPolicies, defaultPolicyValues, and clockSkew. 2870 If any of these values change, the server MUST create a new 2871 ValPolResponse with a new serverConfigurationID. If the 2872 configuration has not changed, then the server may reuse 2873 serverConfigurationID across multiple ValPolResponse messages. 2874 However if the server reverts to an earlier configuration, the 2875 server MUST NOT revert the configuration ID as well, but MUST select 2876 another unique value. 2878 6.5 thisUpdate 2880 This item indicates the signing date and time of this policy 2881 response. 2883 GeneralizedTime values MUST be expressed Greenwich Mean Time (Zulu) 2884 and interpreted as defined in section 3.2.7. 2886 6.6 nextUpdate and requestNonce 2888 These items are used to indicate whether policy responses are 2889 specific to policy requests. Where policy responses are cached, 2890 these items indicate when the information will be updated. The 2891 optional nextUpdate item indicates the time by which the next policy 2892 response will be published. The optional requestNonce item links 2893 the response to a specific request by returning the nonce provided 2894 in the request. 2896 If the nextUpdate item is omitted it indicates a non-cached response 2897 generated in response to a specific request (i.e. the ValPolResponse 2898 is bound to a specific request). If this item is omitted the 2899 requestNonce item MUST be present and MUST include the requestNonce 2900 value from the request. 2902 If the nextUpdate item is present it indicates a cached response 2903 that is not bound to a specific request. An SCVP server MUST 2904 periodically generate a new response as defined by the next update 2905 time, but MAY use the same ValPolResponse to respond to multiple 2906 requests. The requestNonce is omitted if the nextUpdate item is 2907 present. 2909 It is a matter of local server policy to return a cached or non- 2910 cached specific response. 2912 GeneralizedTime values in nextUpdate MUST be expressed Greenwich 2913 Mean Time (Zulu) as specified in section 3.2.7. 2915 6.7 validationPolicies 2917 The validationPolicies item contains a sequence of object 2918 identifiers representing the validation policies supported by the 2919 server. It is a matter of local policy if the server wishes to 2920 process requests using the default validation policy, and if it does 2921 not, then it MUST NOT include the id-svp-defaultValPolicy in this 2922 list. 2924 6.8 validationAlgs 2926 The validationAlgs item contains a sequence of OIDs. Each OID 2927 identifies a validation algorithm supported by the server. 2929 6.9 authPolicies 2931 The authPolicies item contains a sequence of policy references for 2932 authenticating to the SCVP server. 2934 The reference to the authentication policy is an OID that the client 2935 and server have agreed represents an authentication policy. The 2936 list of policies is intended to document to the client if 2937 authentication is required for some requests and if so how. 2939 AuthPolicy ::= OBJECT IDENTIFIER 2941 6.10 responseTypes 2943 responseTypes allows the server to publish the range of response 2944 types it supports. Cached only means the server will only return 2945 cached responses to requests. Non-cached only means the server will 2946 return a specific response to the request i.e. containing the 2947 requestor's nonce. Both means the server will return either, 2948 depending on the request. 2950 6.11 revocationInfoTypes 2952 revocationInfoTypes allows the server to indicate the sources of 2953 revocation information that it is capable of processing. For each 2954 bit in the RevocationInfoTypes bit string, the server MUST set the 2955 bit to one if it is capable of processing the corresponding 2956 revocation information type and to zero if it can not. 2958 6.12 defaultPolicyValues 2960 This is the default validation policy used by the server. It 2961 contains a RespValidationPolicy, which is defined in section 4.5. 2962 All OPTIONAL items in the validationPolicy item MUST be populated. 2963 A server will use these default values when the request references 2964 the default validation policy and the client does not override the 2965 default values by supplying other values in the request. 2967 This allows the client to optimize the request by omitting 2968 parameters that match the server default values. 2970 6.13 signatureGeneration 2972 This sequence specifies the set of digital signature algorithms 2973 supported by an SCVP server for signing CVResponse messages. Each 2974 digital signature algorithm is specified as an AlgorithmIdentifier, 2975 using the encoding rules associated with the signatureAlgorithm 2976 field in a public key certificate [PKIX-1]. Supported algorithms 2977 are defined in [PKIX-ALG] and [PKIX-ALG2], but other signature 2978 algorithms may also be supported. 2980 By including an algorithm (e.g., RSA with SHA-1) in this list, the 2981 server states that it has a private key and corresponding certified 2982 public key for that asymmetric algorithm, and supports the specified 2983 hash algorithm. The list is ordered; the first digital signature 2984 algorithm is the server's default algorithm. The default algorithm 2985 will be used by the server to protect signed messages unless the 2986 client specifies another algorithm. 2988 For servers that do not have an online private key, and cannot sign 2989 CVResponse messages, the signatureGeneration item is encoded as an 2990 empty sequence. 2992 6.14 signatureVerification 2993 This sequence specifies the set of digital signature algorithms that 2994 can be verified by this SCVP server. Each digital signature 2995 algorithm is specified as an AlgorithmIdentifier, using the encoding 2996 rules associated with the signatureAlgorithm field in a public key 2997 certificate [PKIX-1]. Supported algorithms are defined in [PKIX- 2998 ALG] and [PKIX-ALG2], but other signature algorithms may also be 2999 supported. 3001 For servers that do not verify signatures on CVRequest messages, the 3002 signatureVerification item is encoded as an empty sequence. 3004 6.15 hashAlgorithms 3006 This sequence specifies the set of hash algorithms that the server 3007 can use to hash certificates and requests. The list is ordered; the 3008 first hash algorithm is the server's default algorithm. The default 3009 algorithm will be used by the server to compute hashes included in 3010 responses unless the client specifies another algorithm. Each hash 3011 algorithm is specified as an object identifier. [PKIX-ALG2] 3012 specifies object identifiers for SHA-1, SHA-224, SHA-256, SHA-384, 3013 and SHA-512. Other hash algorithms may also be supported. 3015 6.16 serverPublicKeys 3017 The serverPublicKeys item is a sequence of one or more key agreement 3018 public keys and associated parameters. It is used by clients making 3019 AuthenticatedData requests to the server. Each item in the 3020 serverPublicKeys sequence is of the KeyAgreePublicKey type: 3022 KeyAgreePublicKey ::= SEQUENCE { 3023 algorithm AlgorithmIdentifier, 3024 publicKey BIT STRING, 3025 macAlgorithm AlgorithmIdentifier, 3026 kDF AlgorithmIdentifier OPTIONAL } 3028 The KeyAgreePublicKey includes the algorithm identifier and the 3029 server's public key. SCVP servers that support the key agreement 3030 mode of AuthenticatedData for SCVP requests MUST support 3031 serverPublicKeys and the Diffie-Hellman key agreement algorithm as 3032 specified in [PKIX-ALG]. SCVP servers that support serverPublicKeys 3033 MUST support the 1024-bit MODP group key (group 2) as defined in 3034 [IKE]. SCVP servers that support serverPublicKeys MAY support other 3035 Diffie-Hellman groups [IKE-GROUPS], as well as other key agreement 3036 algorithms. 3038 The macAlgorithm item specifies the symmetric algorithm the server 3039 expects the client to use with the result of the key agreement 3040 algorithm. A key derivation function (KDF), which derives symmetric 3041 key material from the key agreement result, may be implied by the 3042 macAlgorithm. Alternatively, the KDF may be explicitly specified 3043 using the optional kDF item. 3045 6.17 clockSkew 3047 The clockSkew item is the number of minutes the server will allow 3048 for clock skew. The default value of 10 minutes. 3050 7 SCVP Server Relay 3052 In some network environments, especially ones that include 3053 firewalls, an SCVP server might not be able to obtain all of the 3054 information that it needs to process a request. However, the server 3055 might be configured to use the services of one or more other SCVP 3056 servers to fulfill all requests. In such cases, the SCVP client is 3057 unaware that the initial SCVP server is using the services of other 3058 SCVP servers. The initial SCVP server acts as a client to another 3059 SCVP server. Unlike the original client, the SCVP server is 3060 expected to have moderate computing and memory resources. This 3061 section describes SCVP server-to-SCVP server exchanges. This 3062 section does not impose any requirements on SCVP clients that are 3063 not also SCVP servers. Further, this section does not impose any 3064 requirements on SCVP servers that do not relay requests to other 3065 SCVP servers. 3067 When one SCVP server relays a request to another server, in an 3068 incorrectly configured system of servers, it is possible that the 3069 same request will be relayed back again. Any SCVP server that 3070 relays requests MUST implement the conventions described in this 3071 section to detect and break loops. 3073 When an SCVP server relays a request, the request MUST include the 3074 requestorRef item. If the request to be relayed already contains a 3075 requestorRef item, then the server-generated request MUST contain a 3076 requestorRef item constructed from this value and an additional 3077 GeneralName that contains an identifier of the SCVP server. If the 3078 request to be relayed does not contain a requestorRef item, then the 3079 server-generated request MUST contain a requestorRef item that 3080 includes a GeneralName that contains an identifier of the SCVP 3081 server. 3083 To prevent false loop detection, servers should use identifiers that 3084 are unique within their network of cooperating SCVP servers. SCVP 3085 servers that support relay SHOULD populate this item with the DNS 3086 name of the server or the distinguished name in the server's 3087 certificate. SCVP servers MAY choose other procedures for 3088 generating identifiers that are unique within their community. 3090 When an SVCP server receives a request that contains a requestorRef 3091 item, the server MUST check the sequence of names in the 3092 requestorRef item for its own identifier. If the server discovers 3093 its own identifier in the requestor item, it MUST respond with an 3094 error, setting the cvResponseStatus to 40. 3096 When an SCVP server generates a non-cached response to a relayed 3097 request, the server MUST include the requestorRef item from the 3098 request in the response. 3100 8 SCVP ASN.1 Module 3102 This section defines the syntax for SCVP request-response pairs. 3103 The semantics for the messages are defined in sections 3, 4, 5, and 3104 6. The SCVP ASN.1 module follows. 3106 SCVP 3108 { iso(1) identified-organization(3) dod(6) internet(1) 3109 security(5) mechanisms(5) pkix(7) id-mod(0) 21 } 3111 DEFINITIONS IMPLICIT TAGS ::= BEGIN 3113 IMPORTS 3115 AlgorithmIdentifier, Attribute, Certificate, Extensions, 3116 -- Import UTF8String if required by compiler 3117 -- UTF8String, -- CertificateList, CertificateSerialNumber 3118 FROM PKIX1Explicit88 -- RFC 3280 3119 { iso(1) identified-organization(3) dod(6) internet(1) 3120 security(5) mechanisms(5) pkix(7) id-mod(0) 18 } 3122 GeneralNames, GeneralName, KeyUsage, KeyPurposeId 3123 FROM PKIX1Implicit88 -- RFC 3280 3124 { iso(1) identified-organization(3) dod(6) internet(1) 3125 security(5) mechanisms(5) pkix(7) id-mod(0) 19 } 3127 AttributeCertificate 3128 FROM PKIXAttributeCertificate -- RFC 3281 3129 { iso(1) identified-organization(3) dod(6) internet(1) 3130 security(5) mechanisms(5) pkix(7) id-mod(0) 12 } 3132 OCSPResponse 3133 FROM OCSP -- RFC 2560 3134 { iso(1) identified-organization(3) dod(6) internet(1) 3135 security(5) mechanisms(5) pkix(7) id-mod(0) 14 } 3137 ContentInfo 3138 FROM CryptographicMessageSyntax -- RFC 3369 3139 { iso(1) member-body(2) us(840) rsadsi(113549) 3140 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) } ; 3142 -- SCVP Certificate Validation Request 3144 id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3145 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3146 id-smime(16) 1 } 3148 id-ct-scvp-certValRequest OBJECT IDENTIFIER ::= { id-ct 10 } 3150 CVRequest ::= SEQUENCE { 3151 cvRequestVersion INTEGER DEFAULT 1, 3152 query Query, 3153 requestorRef [0] GeneralNames OPTIONAL, 3154 requestNonce [1] OCTET STRING OPTIONAL, 3155 requestorName [2] GeneralName OPTIONAL, 3156 responderName [3] GeneralName OPTIONAL, 3157 reqestExtensions [4] Extensions OPTIONAL, 3158 signatureAlg [5] AlgorithmIdentifier OPTIONAL, 3159 hashAlg [6] OBJECT IDENTIFIER OPTIONAL, 3160 requestorText [7] UTF8String (SIZE (1..256)) OPTIONAL } 3162 Query ::= SEQUENCE { 3163 queriedCerts CertReferences, 3164 checks CertChecks, 3165 wantBack [1] WantBack OPTIONAL, 3166 validationPolicy ValidationPolicy, 3167 responseFlags ResponseFlags OPTIONAL, 3168 serverContextInfo [2] OCTET STRING OPTIONAL, 3169 validationTime [3] GeneralizedTime OPTIONAL, 3170 intermediateCerts [4] CertBundle OPTIONAL, 3171 revInfos [5] RevocationInfos OPTIONAL, 3172 producedAt [6] GeneralizedTime OPTIONAL, 3173 queryExtensions [7] Extensions OPTIONAL } 3175 CertReferences ::= CHOICE { 3176 pkcRefs [0] SEQUENCE SIZE (1..MAX) OF PKCReference, 3177 acRefs [1] SEQUENCE SIZE (1..MAX) OF ACReference } 3179 CertReference::= CHOICE { 3180 pkc PKCReference, 3181 ac ACReference } 3183 PKCReference ::= CHOICE { 3184 cert [0] Certificate, 3185 pkcRef [1] CertID } 3187 ACReference ::= CHOICE { 3188 attrCert [2] AttributeCertificate, 3189 acRef [3] CertID } 3191 CertID ::= SEQUENCE { 3192 certHash OCTET STRING, 3193 issuerSerial IssuerSerial, 3194 hashAlgorithm AlgorithmIdentifier DEFAULT { sha-1 } } 3196 IssuerSerial ::= SEQUENCE { 3197 issuer GeneralNames, 3198 serialNumber CertificateSerialNumber 3199 } 3201 ValidationPolicy ::= SEQUENCE { 3202 validationPolRef ValidationPolRef, 3203 validationAlg [0] ValidationAlg OPTIONAL, 3204 userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT 3205 IDENTIFIER OPTIONAL, 3206 inhibitPolicyMapping [2] BOOLEAN OPTIONAL, 3207 requireExplicitPolicy [3] BOOLEAN OPTIONAL, 3208 inhibitAnyPolicy [4] BOOLEAN OPTIONAL, 3209 trustAnchors [5] TrustAnchors OPTIONAL, 3210 keyUsages [6] SEQUENCE OF KeyUsage OPTIONAL, 3211 extendedKeyUsages [7] SEQUENCE OF KeyPurposeId OPTIONAL } 3213 CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 3215 WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 3217 ValidationPolRef ::= SEQUENCE { 3218 valPolId OBJECT IDENTIFIER, 3219 valPolParams ANY DEFINED BY valPolId OPTIONAL } 3221 ValidationAlg ::= SEQUENCE { 3222 valAlgId OBJECT IDENTIFIER, 3223 parameters ANY DEFINED BY valAlgId OPTIONAL } 3225 NameValidationAlgParms ::= SEQUENCE { 3226 nameCompAlgId OBJECT IDENTIFIER, 3227 validationNames GeneralNames } 3229 TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF PKCReference 3231 KeyAgreePublicKey ::= SEQUENCE { 3232 algorithm AlgorithmIdentifier, 3233 publicKey BIT STRING, 3234 macAlgorithm AlgorithmIdentifier, 3235 kDF AlgorithmIdentifier OPTIONAL } 3237 ResponseFlags ::= SEQUENCE { 3238 fullRequestInResponse [0] BOOLEAN DEFAULT FALSE, 3239 responseValidationPolByRef [1] BOOLEAN DEFAULT TRUE, 3240 protectResponse [2] BOOLEAN DEFAULT TRUE, 3241 cachedResponse [3] BOOLEAN DEFAULT TRUE } 3243 CertBundle ::= SEQUENCE SIZE (1..MAX) OF Certificate 3245 RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo 3247 RevocationInfo ::= CHOICE { 3248 crl [0] CertificateList, 3249 delta-crl [1] CertificateList, 3250 ocsp [2] OCSPResponse, 3251 other [3] OtherRevInfo } 3253 OtherRevInfo ::= SEQUENCE { 3254 riType OBJECT IDENTIFIER, 3255 riValue ANY DEFINED BY riType } 3257 -- SCVP Certificate Validation Response 3259 id-ct-scvp-certValResponse OBJECT IDENTIFIER ::= { id-ct 11 } 3261 CVResponse ::= SEQUENCE { 3262 cvResponseVersion INTEGER, 3263 serverConfigurationID INTEGER, 3264 producedAt GeneralizedTime, 3265 responseStatus ResponseStatus, 3266 respValidationPolicy [0] RespValidationPolicy OPTIONAL, 3267 requestRef [1] RequestReference OPTIONAL, 3268 requestorRef [2] GeneralNames OPTIONAL, 3269 requestorName [3] GeneralNames OPTIONAL, 3270 replyObjects [4] ReplyObjects OPTIONAL, 3271 respNonce [5] OCTET STRING OPTIONAL, 3272 serverContextInfo [6] OCTET STRING OPTIONAL, 3273 cvResponseExtensions [7] Extensions OPTIONAL, 3274 requestorText [8] UTF8String (SIZE (1..256)) OPTIONAL } 3276 ResponseStatus ::= SEQUENCE { 3277 statusCode CVStatusCode DEFAULT okay, 3278 errorMessage UTF8String OPTIONAL } 3280 CVStatusCode ::= ENUMERATED { 3281 okay (0), 3282 skipUnrecognizedItems (1), 3283 tooBusy (10), 3284 invalidRequest (11), 3285 internalError (12), 3286 badStructure (20), 3287 unsupportedVersion (21), 3288 abortUnrecognizedItems (22), 3289 unrecognizedSigKey (23), 3290 badSignatureOrMAC (24), 3291 unableToDecode (25), 3292 notAuthorized (26), 3293 unsupportedChecks (27), 3294 unsupportedWantBacks (28), 3295 unsupportedSignatureOrMAC (29), 3296 invalidSignatureOrMAC (30), 3297 protectedResponseUnsupported (31), 3298 unrecognizedResponderName (32), 3299 relayingLoop (40), 3300 unrecognizedValPol (50), 3301 unrecognizedValAlg (51), 3302 fullRequestInResponseUnsupported (52), 3303 fullPolResponseUnsupported (53), 3304 inhibitPolicyMappingUnsuported (54), 3305 requireExplicitPolicyUnsupported (55), 3306 inhibitAnyPolicyUnsupported (56), 3307 validityTimeUnsupported (57), 3308 unrecognizedCritQueryExt (63), 3309 unrecognizedCritRequestExt (64) } 3311 RespValidationPolicy ::= ValidationPolicy 3313 RequestReference ::= CHOICE { 3314 requestHash [0] HashValue, -- hash of CVRequest 3315 fullRequest [1] CVRequest } 3317 HashValue ::= SEQUENCE { 3318 algorithm AlgorithmIdentifier DEFAULT { sha-1 }, 3319 value OCTET STRING } 3321 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3322 oiw(14) secsig(3) algorithm(2) 26 } 3324 ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply 3326 CertReply ::= SEQUENCE { 3327 cert CertReference, 3328 replyStatus ReplyStatus DEFAULT success, 3329 replyValTime GeneralizedTime, 3330 replyChecks ReplyChecks, 3331 replyWantBacks ReplyWantBacks, 3332 validationErrors [0] SEQUENCE SIZE (1..MAX) OF 3333 OBJECT IDENTIFIER OPTIONAL, 3334 nextUpdate [1] GeneralizedTime OPTIONAL, 3335 certReplyExtensions [2] Extensions OPTIONAL } 3337 ReplyStatus ::= ENUMERATED { 3338 success (0), 3339 malformedPKC (1), 3340 malformedAC (2), 3341 unavailableValidityTime (3), 3342 referenceCertHashFail (4), 3343 certPathConstructFail (5), 3344 certPathNotValid (6), 3345 certPathNotValidNow (7), 3346 wantBackUnsatisfied (8) } 3348 ReplyChecks ::= SEQUENCE OF ReplyCheck 3350 ReplyCheck ::= SEQUENCE { 3351 check OBJECT IDENTIFIER, 3352 status INTEGER DEFAULT 0 } 3354 ReplyWantBacks ::= SEQUENCE OF ReplyWantBack 3356 ReplyWantBack::= SEQUENCE { 3357 wb OBJECT IDENTIFIER, 3358 value OCTET STRING } 3360 CertBundles ::= SEQUENCE SIZE (1..MAX) OF CertBundle 3362 RevInfoWantBack ::= SEQUENCE { 3363 revocationInfo RevocationInfos, 3364 extraCerts CertBundle OPTIONAL } 3366 SCVPResponses ::= SEQUENCE OF ContentInfo 3368 -- SCVP Validation Policies Request 3370 id-ct-scvp-valPolRequest OBJECT IDENTIFIER ::= { id-ct 12 } 3372 ValPolRequest ::= SEQUENCE { 3373 vpRequestVersion INTEGER DEFAULT 1, 3374 requestNonce OCTET STRING } 3376 -- SCVP Validation Policies Response 3378 id-ct-scvp-valPolResponse OBJECT IDENTIFIER ::= { id-ct 13 } 3380 ValPolResponse ::= SEQUENCE { 3381 vpResponseVersion INTEGER, 3382 maxCVResponseVersion INTEGER, 3383 maxVPResponseVersion INTEGER, 3384 serverConfigurationID INTEGER, 3385 thisUpdate GeneralizedTime, 3386 nextUpdate GeneralizedTime OPTIONAL, 3387 validationPolices SEQUENCE OF OBJECT IDENTIFIER, 3388 validationAlgs SEQUENCE OF OBJECT IDENTIFIER, 3389 authPolicies SEQUENCE OF AuthPolicy, 3390 responseTypes ResponseTypes, 3391 defaultPolicyValues RespValidationPolicy, 3392 revocationInfoTypes RevocationInfoTypes, 3393 signatureGeneration SEQUENCE OF AlgorithmIdentifier, 3394 signatureVerification SEQUENCE OF AlgorithmIdentifier, 3395 hashAlgorithms SEQUENCE SIZE (1..MAX) OF 3396 OBJECT IDENTIFIER, 3397 serverPublicKeys SEQUENCE OF KeyAgreePublicKey 3398 OPTIONAL, 3399 clockSkew INTEGER DEFAULT 10, 3400 requestNonce OCTET STRING OPTIONAL } 3402 ResponseTypes ::= ENUMERATED { 3403 cached-only (0), 3404 non-cached-only (1), 3405 cached-and-non-cached (2) } 3407 RevocationInfoTypes ::= BIT STRING { 3408 fullCRLs (0), 3409 deltaCRLs (1), 3410 indirectCRLs (2), 3411 oCSPResponses (3) } 3413 AuthPolicy ::= OBJECT IDENTIFIER 3415 -- SCVP Check Identifiers 3417 id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3418 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 } 3420 id-stc-build-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 } 3421 id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 2 } 3422 id-stc-build-status-checked-pkc-path 3423 OBJECT IDENTIFIER ::= { id-stc 3 } 3424 id-stc-build-aa-path OBJECT IDENTIFIER ::= { id-stc 4 } 3425 id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 5 } 3426 id-stc-build-status-checked-aa-path 3427 OBJECT IDENTIFIER ::= { id-stc 6 } 3428 id-stc-status-check-ac-and-build-status-checked-aa-path 3429 OBJECT IDENTIFIER ::= { id-stc 7 } 3431 -- SCVP WantBack Identifiers 3433 id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3434 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 } 3436 id-swb-pkc-best-cert-path OBJECT IDENTIFIER ::= { id-swb 1 } 3437 id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 } 3438 id-swb-pkc-public-key-info OBJECT IDENTIFIER ::= { id-swb 4 } 3439 id-swb-aa-cert-path OBJECT IDENTIFIER ::= { id-swb 5 } 3440 id-swb-aa-revocation-info OBJECT IDENTIFIER ::= { id-swb 6 } 3441 id-swb-ac-revocation-info OBJECT IDENTIFIER ::= { id-swb 7 } 3442 id-swb-relayed-responses OBJECT IDENTIFIER ::= { id-swb 9 } 3443 id-swb-pkc-cert OBJECT IDENTIFIER ::= { id-swb 10} 3444 id-swb-ac-cert OBJECT IDENTIFIER ::= { id-swb 11} 3445 id-swb-pkc-all-cert-paths OBJECT IDENTIFIER ::= { id-swb 12} 3446 id-swb-pkc-ee-revocation-info OBJECT IDENTIFIER ::= { id-swb 13} 3447 id-swb-pkc-CAs-revocation-info OBJECT IDENTIFIER ::= { id-swb 14} 3449 -- SCVP Validation Policy and Algorithm Identifiers 3451 id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3452 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 } 3454 id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 } 3456 -- SCVP Basic Validation Algorithm Identifier 3458 id-svp-basicValAlg OBJECT IDENTIFIER ::= { id-svp 3 } 3460 -- SCVP Basic Validation Algorithm Errors 3462 id-bvae OBJECT IDENTIFIER ::= id-svp-basicValAlg 3464 id-bvae-expired OBJECT IDENTIFIER ::= { id-bvae 1 } 3465 id-bvae-not-yet-valid OBJECT IDENTIFIER ::= { id-bvae 2 } 3466 id-bvae-wrongTrustAnchor OBJECT IDENTIFIER ::= { id-bvae 3 } 3467 id-bvae-noValidCertPath OBJECT IDENTIFIER ::= { id-bvae 4 } 3468 id-bvae-revoked OBJECT IDENTIFIER ::= { id-bvae 5 } 3469 id-bvae-invalidKeyPurpose OBJECT IDENTIFIER ::= { id-bvae 9 } 3470 id-bvae-invalidKeyUsage OBJECT IDENTIFIER ::= { id-bvae 10 } 3471 id-bvae-invalidCertPolicy OBJECT IDENTIFIER ::= { id-bvae 11 } 3473 -- SCVP Name Validation Algorithm Identifier 3475 id-svp-nameValAlg OBJECT IDENTIFIER ::= { id-svp 2 } 3477 -- SCVP Name Validation Algorithm DN comparison algorithm 3478 id-nva-dnCompAlg OBJECT IDENTIFIER ::= { id-svp 4 } 3480 -- SCVP Name Validation Algorithm Errors 3482 id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg 3484 id-nvae-name-mismatch OBJECT IDENTIFIER ::= { id-nvae 1 } 3485 id-nvae-no-name OBJECT IDENTIFIER ::= { id-nvae 2 } 3486 id-nvae-unknown-alg OBJECT IDENTIFIER ::= { id-nvae 3 } 3487 id-nvae-bad-name OBJECT IDENTIFIER ::= { id-nvae 4 } 3488 id-nvae-bad-name-type OBJECT IDENTIFIER ::= { id-nvae 5 } 3489 id-nvae-mixed-names OBJECT IDENTIFIER ::= { id-nvae 6 } 3491 -- SCVP Extended Key Usage Key Purpose Identifiers 3493 id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 3494 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } 3496 id-kp-scvpServer OBJECT IDENTIFIER ::= { id-kp 15 } 3498 id-kp-scvpClient OBJECT IDENTIFIER ::= { id-kp 16 } 3500 END 3502 9 Security Considerations 3504 For security considerations specific to the Cryptographic Message 3505 Syntax message formats, see [CMS]. For security considerations 3506 specific to the process of PKI certificate path validation, see 3507 [PKIX-1]. 3509 A client that trusts a server's response for validation of a 3510 certificate inherently trusts that server as much as it would trust 3511 its own validation software. This means that if an attacker 3512 compromises a trusted SCVP server, the attacker can change the 3513 validation processing for every client that relies on that server. 3514 Thus, an SCVP server must be protected at least as well as the trust 3515 anchors that the SCVP server trusts. 3517 Clients MUST verify that the response matches their original 3518 request. Clients need to ensure that the server has performed the 3519 appropriate checks for the correct certificates under the requested 3520 validation policy for the specified validation time, and that the 3521 response includes the requested want backs and meets the client's 3522 freshness requirements. 3524 When the SCVP response is used to determine the validity of a 3525 certificate, the client MUST validate the digital signature or MAC 3526 on the response to ensure that the expected SCVP server generated 3527 it. If the client does not check the digital signature or MAC on 3528 the response, a man-in-the-middle attack could fool the client into 3529 believing modified responses from the server, or responses to 3530 questions the client did not ask. 3532 If the client does not include a requestNonce item, or if the client 3533 does not check that the requestNonce in the response matches the 3534 value in the request, an attacker can replay previous responses from 3535 the SCVP server. 3537 If the server does not require some sort of authorization (such as 3538 signed requests), an attacker can get the server to respond to 3539 arbitrary requests. Such responses may give the attacker 3540 information about weaknesses in the server or about the timeliness 3541 of the server's checking. This information may be valuable for a 3542 future attack. 3544 If the server uses the serverContextInfo item to indicate some 3545 server state associated with a requestor, implementers must take 3546 appropriate measures against denial of service attacks where an 3547 attacker sends in a lot of requests at one time to force the server 3548 to keep a lot of state information. 3550 SCVP does not include any confidentiality mechanisms. If 3551 confidentiality is needed, it can be achieved with a lower-layer 3552 security protocol. 3554 If an SCVP client is not operating on a network with good physical 3555 protection, it must ensure that there is integrity over the SCVP 3556 request-response pair. The client can ensure integrity by using a 3557 protected transport such as TLS. It can ensure integrity by using 3558 MACs or digital signatures to individually protect the request and 3559 response messages. 3561 If an SCVP client populates the userPolicySet in a request with a 3562 value other than anyPolicy, but does not set the 3563 requireExplicitPolicy flag, the server may return an affirmative 3564 answer for paths that do not satisfy any of the specified policies. 3565 In general, when a client populates the userPolicySet in a request 3566 with a value other than anyPolicy, the requireExplicitPolicy flag 3567 should also be set. This guarantees that all valid paths satisfy at 3568 least one of the requested policies. 3570 In SCVP, historical validation of a certificate returns the known 3571 status of the certificate at the time specified in validationTime. 3572 This may be used to demonstrate due diligence, but does not 3573 necessarily provide the most complete information. A certificate 3574 may have been revoked after the time specified in validationTime, 3575 but the revocation notice may specify an invalidity date that 3576 precedes the validationTime. The SCVP server would provide an 3577 affirmative response even though the most current information 3578 available indicates the certificate should not be trusted at that 3579 time. SCVP clients may wish to specify a validationTime later than 3580 the actual time of interest to mitigate this risk. 3582 10 IANA Considerations 3584 The details of SCVP requests and responses are communicated using 3585 Object Identifiers (OIDs). The objects are defined in an arc 3586 delegated by IANA to the PKIX Working Group. This document also 3587 includes four MIME type registrations in Appendix A. No further 3588 action by IANA is necessary for this document or any anticipated 3589 updates. 3591 11 References 3593 Normative and informative references are provided. 3595 11.1 Normative References 3597 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 3598 Requirement Levels", BCP 14, RFC 2119, March 1997. 3599 http://www.ietf.org/rfc/rfc2119.txt 3601 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 3369,August 3602 2002. 3603 http://www.ietf.org/rfc/rfc3369.txt 3605 [OCSP] Myers, M., R. Ankney, A. Malpani, S. Galperin and C. 3606 Adams, "X.509 Internet Public Key Infrastructure - Online 3607 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 3608 http://www.ietf.org/rfc/rfc2560.txt 3610 [PKIX-1] Housley, R., T. Polk, W. Ford and D. Solo, "Internet 3611 X.509 Public Key Infrastructure Certificate and 3612 Certificate Revocation List (CRL) Profile", RFC 3280, 3613 April 2002. 3614 http://www.ietf.org/rfc/rfc3280.txt 3616 [PKIX-AC] Farrell, S. and R. Housley, "An Internet Attribute 3617 Certificate Profile for Authorization", RFC 3281, April 3618 2002. 3619 http://www.ietf.org/rfc/rfc3281.txt 3621 [PKIX-ALG] Polk, W., R. Housley and L. Bassham, "Algorithms and 3622 Identifiers for the Internet X.509 Public Key 3623 Infrastructure Certificate and Certificate Revocation 3624 List (CRL) Profile", RFC 3279, April 2002. 3625 http://www.ietf.org/rfc/rfc3279.txt 3627 [PKIX-ALG2] Schaad, J., B. Kaliski and R. Housley, "Additional 3628 Algorithms and Identifiers for RSA Cryptography for use 3629 in the Internet X.509 Public Key Infrastructure 3630 Certificate and Certificate Revocation List (CRL) 3631 Profile", RFC 4055, June 2005. 3632 http://www.ietf.org/rfc/rfc4055.txt 3634 [SHA] National Institute of Standards and Technology, "Secure 3635 Hash Standard", NIST FIPS Pub 180-2, August 2002. 3637 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 3638 10646", RFC 2279, January 1998. 3639 http://www.ietf.org/rfc/rfc2279.txt 3641 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 3642 2634, June 1999. 3643 http://www.ietf.org/rfc/rfc2634.txt 3645 [HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC2818, May 2000. 3646 http://www.ietf.org/rfc/rfc2818.txt 3648 [SMIME-CERT] B. Ramsdell, Ed. "Secure/Multipurpose Internet Mail 3649 Extensions (S/MIME) Version 3.1 Certificate Handling" 3650 RFC3850, July 2004. 3651 http://www.ietf.org/rfc/rfc3850.txt 3653 [IKE] Harkins, D. and D. Carrel. "The Internet Key Exchange 3654 (IKE)", RFC2409, November 1998. 3655 http://www.ietf.org/rfc/rfc2409.txt 3657 11.2 Informative References 3659 [HTTP] Fielding, R., J. Gettys, J. Mogul, H. Frystyk, L. 3660 Masinter, P. Leach and T. Berners-Lee, "Hypertext 3661 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3662 http://www.ietf.org/rfc/rfc2616.txt 3664 [IKE-GROUPS] Kivinen, T. and M. Kojo "More Modular Exponential (MODP) 3665 Diffie-Hellman groups for Internet Key Exchange (IKE)", 3666 RFC3526, May 2003. 3667 http://www.ietf.org/rfc/rfc3526.txt 3669 [RQMTS] Pinkas, D. and R. Housley, "Delegated Path Validation and 3670 Delegated Path Discovery Protocol Requirements", RFC 3671 3379, September 2002. 3672 http://www.ietf.org/rfc/rfc3379.txt 3674 12 Intellectual Property Rights 3676 The IETF takes no position regarding the validity or scope of any 3677 Intellectual Property Rights or other rights that might be claimed 3678 to pertain to the implementation or use of the technology described 3679 in this document or the extent to which any license under such 3680 rights might or might not be available; nor does it represent that 3681 it has made any independent effort to identify any such rights. 3682 Information on the procedures with respect to rights in RFC 3683 documents can be found in BCP 78 and BCP 79. 3685 Copies of IPR disclosures made to the IETF Secretariat and any 3686 assurances of licenses to be made available, or the result of an 3687 attempt made to obtain a general license or permission for the use 3688 of such proprietary rights by implementers or users of this 3689 specification can be obtained from the IETF on-line IPR repository 3690 at http://www.ietf.org/ipr. 3692 The IETF invites any interested party to bring to its attention any 3693 copyrights, patents or patent applications, or other proprietary 3694 rights that may cover technology that may be required to implement 3695 this standard. Please address the information to the IETF at ietf- 3696 ipr@ietf.org. 3698 13 Acknowledgments 3700 The lively debate in the PKIX Working Group has made a significant 3701 impact on this protocol. Special thanks to the following for their 3702 contributions to this standard and diligence in greatly improving 3703 this document. 3705 Paul Hoffman 3706 Phillip Hallam-Baker 3707 Mike Myers 3708 Frank Balluffi 3709 Ameya Talwalkar 3710 John Thielens 3711 Peter Sylvester 3712 Yuriy Dzambasow 3713 Sean P. Turner 3714 Wen-Cheng Wang 3715 Francis Dupont 3716 Dave Engberg 3717 Faisal Maqsood 3719 Thanks also to working group chair Steve Kent for his support and 3720 help. 3722 14 Authors' Addresses 3724 Trevor Freeman 3725 Microsoft Corporation, 3726 One Microsoft way. 3727 Redmond, WA 98052 3728 USA. 3729 trevorf@microsoft.com 3731 Russell Housley 3732 Vigil Security, LLC 3733 918 Spring Knoll Drive 3734 Herndon, VA 20170 3735 USA 3736 housley@Vigilsec.com 3738 Ambarish Malpani 3739 Malpani Consulting Services 3740 ambarish@malpani.biz 3742 David Cooper 3743 National Institute of Standards and Technology 3744 100 Bureau Drive, Mail Stop 8930 3745 Gaithersburg, MD 20899-8930 3746 david.cooper@nist.gov 3748 Tim Polk 3749 National Institute of Standards and Technology 3750 100 Bureau Drive, Mail Stop 8930 3751 Gaithersburg, MD 20899-8930 3752 tim.polk@nist.gov 3754 Appendix A -- MIME Registrations 3756 Four MIME type registrations are provided in this appendix. 3758 A.1 application/cv-request 3760 To: ietf-types@iana.org 3761 Subject: Registration of MIME media type application/cv-request 3763 MIME media type name: application 3765 MIME subtype name: cv-request 3767 Required parameters: format 3768 Optional parameters: None 3770 Encoding considerations: binary 3772 Security considerations: Carries a request for information. This 3773 request may optionally be cryptographically protected. 3775 Interoperability considerations: None 3777 Published specification: IETF PKIX Working Group Draft on Server- 3778 based Certificate Validation Protocol (SCVP) 3780 Applications that use this media type: SCVP clients 3782 Additional information: 3783 Magic number(s): None 3784 File extension(s): .SCQ 3785 Macintosh File Type Code(s): none 3787 Person & email address to contact for further information: 3788 Ambarish Malpani 3790 Intended usage: COMMON 3792 Author/Change controller: 3793 Ambarish Malpani 3795 A.2 application/cv-response 3797 To: ietf-types@iana.org 3798 Subject: Registration of MIME media type application/cv-response 3800 MIME media type name: application 3802 MIME subtype name: cv-response 3804 Required parameters: format 3806 Optional parameters: None 3808 Encoding considerations: binary 3810 Security considerations: The client may require that this response 3811 be cryptographically protected, or may choose to use secure 3812 transport mechanism. DPD responses may be unprotected, but the 3813 client validates the information provided in the request. 3815 Interoperability considerations: None 3816 Published specification: IETF PKIX Working Group Draft on Server- 3817 based Certificate Validation Protocol (SCVP) 3819 Applications that use this media type: SCVP servers 3821 Additional information: 3823 Magic number(s): None 3824 File extension(s): .SCS 3825 Macintosh File Type Code(s): none 3827 Person & email address to contact for further information: 3828 Ambarish Malpani 3830 Intended usage: COMMON 3832 Author/Change controller: Ambarish Malpani 3834 A.3 application/vp-request 3836 To: ietf-types@iana.org 3837 Subject: Registration of MIME media type application/vp-request 3839 MIME media type name: application 3841 MIME subtype name: vp-request 3843 Required parameters: format 3845 Optional parameters: None 3847 Encoding considerations: binary 3849 Security considerations: Carries a request for information. 3851 Interoperability considerations: None 3853 Published specification: IETF PKIX Working Group Draft on Server- 3854 based Certificate Validation Protocol (SCVP) 3856 Applications that use this media type: SCVP clients 3858 Additional information: 3860 Magic number(s): None 3861 File extension(s): .SPQ 3862 Macintosh File Type Code(s): none 3864 Person & email address to contact for further information: 3866 Ambarish Malpani 3868 Intended usage: COMMON 3870 Author/Change controller: Ambarish Malpani 3872 A.4 application/vp-response 3874 To: ietf-types@iana.org 3875 Subject: Registration of MIME media type application/vp-response 3877 MIME media type name: application 3879 MIME subtype name: vp-response 3881 Required parameters: format 3883 Optional parameters: None 3885 Encoding considerations: Binary 3887 Security considerations: None 3889 Interoperability considerations: None 3891 Published specification: IETF PKIX Working Group Draft on Server- 3892 based Certificate Validation Protocol (SCVP) 3894 Applications that use this media type: SCVP servers 3896 Additional information: 3897 Magic number(s): None 3898 File extension(s): .SPP 3899 Macintosh File Type Code(s): none 3901 Person & email address to contact for further information: 3902 Ambarish Malpani 3904 Intended usage: COMMON 3906 Author/Change controller: 3907 Ambarish Malpani 3909 Appendix B -- SCVP over HTTP 3911 This appendix describes the formatting conventions for the SCVP 3912 request and response when carried by HTTP. 3914 B.1 SCVP Request 3915 HTTP based SCVP requests can use the POST method to submit their 3916 requests. Where privacy is a requirement, SCVP transactions 3917 exchanged using HTTP MAY be protected using either TLS/SSL or some 3918 other lower layer protocol. 3920 An SCVP request using the POST method is constructed as follows: 3922 The Content-Type header MUST have the value "application/cv- 3923 request". 3925 The Content-Length header MUST be present and have the exact 3926 length of the request. 3928 The body of the message is the binary value of the DER encoding 3929 of the CVRequest, wrapped in a CMS body as described in 3930 Section 3. Other HTTP headers MAY be present and MAY be 3931 ignored if not understood by the requestor. 3933 Sample Content-Type headers are: 3934 Content-Type: application/cv-request 3936 B.2 SCVP Response 3938 An HTTP-based SCVP response is composed of the appropriate HTTP 3939 headers, followed by the binary value of the BER encoding of the 3940 CVResponse, wrapped in a CMS body as described in Section 4. 3942 The Content-Type header MUST have the value "application/cv- 3943 response". 3945 The Content-Length header MUST be present and specify the length of 3946 the response. 3948 Other HTTP headers MAY be present and MAY be ignored if not 3949 understood by the requestor. 3951 B.3 SCVP Policy Request 3953 HTTP based SCVP policy requests can use the POST method to submit 3954 their requests. Where privacy is a requirement, SCVP transactions 3955 exchanged using HTTP MAY be protected using either TLS/SSL or some 3956 other lower layer protocol. 3958 An SCVP request using the POST method is constructed as follows: 3960 The Content-Type header MUST have the value "application/vp- 3961 request". 3963 The Content-Length header MUST be present and have the exact 3964 length of the request. 3966 The body of the message is the binary value of the BER encoding 3967 of the ValPolRequest, wrapped in a CMS body as described in 3968 Section 5. Other HTTP headers MAY be present and 3969 MAY be ignored if not understood by the requestor. 3971 Sample Content-Type headers are: 3972 Content-Type: application/vp-request 3974 B.4 SCVP Policy Response 3976 An HTTP-based SCVP policy response is composed of the appropriate 3977 HTTP headers, followed by the binary value of the DER encoding of 3978 the ValPolResponse, wrapped in a CMS body as described in Section 6. 3980 The Content-Type header MUST have the value "application/vp- 3981 response". 3983 The Content-Length header MUST be present and specify the length of 3984 the response. 3986 Other HTTP headers MAY be present and MAY be ignored if not 3987 understood by the requestor. 3989 Full Copyright Statement 3991 Copyright (C) The Internet Society (2006). This document is subject 3992 to the rights, licenses and restrictions contained in BCP 78, and 3993 except as set forth therein, the authors retain all their rights. 3995 This document and the information contained herein are provided on 3996 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 3997 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 3998 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 3999 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4000 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4001 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4003 This document and translations of it may be copied and furnished to 4004 others, and derivative works that comment on or otherwise explain it 4005 or assist in its implementation may be prepared, copied, published 4006 and distributed, in whole or in part, without restriction of any 4007 kind, provided that the above copyright notice and this paragraph 4008 are included on all such copies and derivative works. In addition, 4009 the ASN.1 modules presented may be used in whole or in part without 4010 inclusion of the copyright notice. However, this document itself 4011 may not be modified in any way, such as by removing the copyright 4012 notice or references to the Internet Society or other Internet 4013 organizations, except as needed for the purpose of developing 4014 Internet standards in which case the procedures for copyrights 4015 defined in the Internet Standards process shall be followed, or as 4016 required to translate it into languages other than English.