idnits 2.17.1 draft-ietf-pkix-scvp-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: The signedAttrs within SignerInfo MUST include the content-type and message-digest attributes defined in [CMS] as well as the SigningCertificate attribute as defined in [ESS]. Within the SigningCertificate attribute, the first certificate identified in the sequence of certificate identifiers MUST be the certificate of the SCVP server. The inclusion of other certificate identifiers in the SigningCertificate attribute is OPTIONAL. The inclusion of policies in the SigningCertificate attribute is also OPTIONAL. The policies item in the SigningCertificate attribute SHALL not be present. -- 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 1966 -- Looks like a reference, but probably isn't: '1' on line 2017 -- Looks like a reference, but probably isn't: '2' on line 2018 -- Looks like a reference, but probably isn't: '3' on line 1958 -- Looks like a reference, but probably isn't: '4' on line 1959 -- Looks like a reference, but probably isn't: '5' on line 1960 == Missing Reference: 'PKIX' is mentioned on line 654, but not defined -- Looks like a reference, but probably isn't: '6' on line 1961 -- Looks like a reference, but probably isn't: '7' on line 1962 == Unused Reference: 'OpenPGP' is defined on line 2213, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2630 (ref. 'CMS') (Obsoleted by RFC 3369, RFC 3370) ** Obsolete normative reference: RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 3280 (ref. 'PKIX-1') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3281 (ref. 'PKIX-AC') (Obsoleted by RFC 5755) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA-1' ** Obsolete normative reference: RFC 2279 (ref. 'UTF8') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2818 (ref. 'HTTP-TLS') (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2068 (ref. 'HTTP') (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 2440 (ref. 'OpenPGP') (Obsoleted by RFC 4880) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft A. Malpani 2 draft-ietf-pkix-scvp-13.txt Malpani Consulting Services 3 October 2003 R. Housley 4 Expires in six months Vigil Security 5 T. Freeman 6 Microsoft Corp 8 Simple Certificate Validation Protocol (SCVP) 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 SCVP allows a client to offload certificate handling to a server. 39 The server can provide the client with a variety of valuable 40 information about the certificate, such as whether the certificate 41 is valid, a certification path to a trust anchor, and revocation 42 status. SCVP has many purposes, including simplifying client 43 implementations and allowing companies to centralize trust and 44 policy management. 46 Table of Contents 48 1 Introduction.......................................................4 49 1.1 SCVP overview and requirements..................................4 50 1.2 Terminology.....................................................5 51 1.3 Validation Policies.............................................5 52 2 Protocol Overview..................................................6 53 3 Validation Request.................................................7 54 3.1 scvpVersion.....................................................9 55 3.2 Query...........................................................9 56 3.2.1 queriedCerts...............................................10 57 3.2.2 checks.....................................................10 58 3.2.3 wantBack...................................................11 59 3.2.4 RequestRefHash.............................................13 60 3.2.5 IncludePolResponse.........................................13 61 3.2.6 inhibitPolMap..............................................13 62 3.2.7 requireExplicitPol.........................................14 63 3.2.8 ignoreAnyPol...............................................14 64 3.2.9 serverContextInfo..........................................14 65 3.2.10 valAlgorithm..............................................15 66 3.2.10.1 Default Validation Algorithm..........................15 67 3.2.10.2 Name Validation Algorithm.............................16 68 3.2.10.3 Name Validation Algorithm Errors......................16 69 3.2.11 validityTime..............................................17 70 3.2.12 trustAnchors..............................................18 71 3.2.13 intermediateCerts.........................................18 72 3.2.14 revInfos..................................................19 73 3.2.15 queryExtensions...........................................20 74 3.3 Requestor......................................................20 75 3.4 requestNonce...................................................20 76 3.5 reqExtensions..................................................21 77 4 Validation Response...............................................21 78 4.1 scvpVersion....................................................23 79 4.2 policyID.......................................................23 80 4.3 producedAt.....................................................24 81 4.4 responseStatus.................................................24 82 4.5 requestReference...............................................25 83 4.5.1 requestHash................................................26 84 4.5.2 fullRequest................................................26 85 4.6 Requestor......................................................27 86 4.7 responder......................................................27 87 4.8 replyObjects...................................................27 88 4.8.1 cert.......................................................28 89 4.8.2 replyStatus................................................28 90 4.8.3 replyValTime...............................................29 91 4.8.4 replyChecks................................................29 92 4.8.5 replyWantBack..............................................31 93 4.8.6 valAlgorithm...............................................32 94 4.8.7 nextUpdate.................................................32 95 4.8.8 certReplyExtensions........................................32 96 4.9 requestNonce...................................................32 97 4.10 serverContextInfo.............................................33 98 4.11 respExtensions................................................33 99 5 SCVP Server certificates..........................................33 100 5.1 SCVP Server Name...............................................34 101 5.1.1 SVCP Extended Key Usage....................................34 102 5.1.2 SCVP Server certificate validation.........................34 103 6 Server Policies Request...........................................34 104 7 Validation Policies Response......................................35 105 7.1 scvpVersion....................................................35 106 7.2 PolicyID.......................................................35 107 7.3 thisUpdate.....................................................36 108 7.4 nextUpdate.....................................................36 109 7.5 trustAnchors...................................................36 110 7.6 valAlgorithms..................................................36 111 7.7 clockSkew......................................................36 112 8 SCVP Server Relay.................................................36 113 9 SCVP ASN.1 Module.................................................37 114 10 Security Considerations..........................................42 115 11 References.......................................................43 116 11.1 Normative References..........................................43 117 11.2 Informative References........................................44 118 12 Acknowledgments..................................................44 119 Appendix A -- MIME Registrations....................................45 120 A.1 application/cv-request.........................................45 121 A.2 application/cv-response........................................45 122 A.3 application/cv-policies-request................................46 123 A.4 application/cv-policies-response...............................47 124 Appendix B -- SCVP over HTTP........................................48 125 B.1 SCVP Request...................................................48 126 Appendix C -- Author Contact Information............................48 127 1 Introduction 129 Certificate validation is complex. If certificate handling is to 130 be widely deployed in a variety of applications and environments, 131 the amount of processing an application needs to perform before it 132 can accept a certificate needs to be reduced. There are a variety 133 of applications that can make use of public key certificates, but 134 these applications are burdened with the overhead of constructing 135 and validating the certification paths. SCVP reduces this overhead 136 for two classes of certificate-using applications. 138 The first class of application wants just two things. First, they 139 want confirmation that the public key belongs to the identity named 140 in the certificate. Second, they want to know if the public key 141 can be used for the intended purpose. The client completely 142 delegates certification path construction and validation to the 143 SCVP server. 145 The second class of application can perform certification path 146 validation, but these applications have no reliable method of 147 constructing a certification path to a trust anchor. The client 148 only delegates certification path construction to the SCVP server. 150 1.1 SCVP overview and requirements 152 The SCVP meets the requirements documented in [RQMTS]. 154 The primary goals of SCVP are to make it easier to deploy PKI- 155 enabled applications and to allow central administration of PKI 156 policies within an organization. SCVP can be used by clients that 157 do much of the certificate processing themselves but simply want an 158 untrusted server to collect information for them. However, when 159 the client has complete trust in the SCVP server, SCVP can be used 160 to delegate the work of certification path construction and 161 validation, and SCVP can be used to ensure that policies are 162 consistently enforced throughout an organization. 164 Untrusted SCVP servers can provide clients the certification paths. 165 They can also provide clients revocation information, such as CRLs 166 and OCSP responses, and the client needs to validate the 167 certification path constructed by the SCVP server. These services 168 can be valuable to clients that do not include the protocols needed 169 to find and download intermediate certificates, CRLs, and OCSP 170 responses. 172 Trusted SCVP servers can perform certification path construction 173 and validation for the client. For a client that uses these 174 services, the client inherently trusts the SCVP server as much as 175 it would its own certification path validation software (if it 176 contained such software). There are two main reasons that a client 177 may want to trust such an SCVP server: 179 - The client does not want to incur the overhead of including 180 certification path validation software and running it for each 181 certificate it receives. 183 - The client is in an organization or community that wants to 184 centralize its PKI policies. These policies might dictate which 185 trust anchors are used and the types of policy checking that are 186 performed during certification path validation. 188 1.2 Terminology 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 192 this document are to be interpreted as described in [STDWORDS]. 194 1.3 Validation Policies 196 A validation policy (as defined in RFC 3379 [RQMTS]) specifies the 197 rules to be used by the SCVP server when validated a certificate. 198 In SCVP, the validation policy comprises an algorithm for 199 certificate path processing and the input parameters to the 200 algorithm. The default inputs to the certificate path processing 201 algorithm used by SCVP are defined by [PKIX-1] in section 6.1.1 and 202 comprise: 204 Certificate to be validated (by value or by reference) 206 Validation time 208 Set of Trust Anchors (by value or by reference) 210 The initial policy set 212 Initial policy mapping setting 214 Initial any-Policy setting 216 Initial explicit policy setting 218 The validation algorithm is determined by agreement between the 219 client and the server, but it MUST be represented as an OBJECT 220 IDENTIFIER. The SCVP server can assign validation algorithm object 221 identifiers which indicate that some predefined settings are used 222 in addition to values provided in the SCVP request. 224 Application-specific validation algorithms in addition to those 225 defined in this document can be defined to meet specific 226 requirements not covered by the default validation algorithm. The 227 validation algorithms documented here should serve as guides for 228 the development of further application-specific validation 229 algorithms. 231 For a certification path to be considered valid under a particular 232 validation policy, it MUST be a valid certification path as defined 233 in [PKIX-1] and all validation policy constraints that apply to the 234 certification path MUST be verified. Applications MAY place 235 additional requirements on the validation algorithm. 237 Revocation checking is one aspect of certification path validation 238 defined in [PKIX-1]. Therefore, the validation policy MUST specify 239 the source of revocation information. Five alternatives are 240 envisioned: 242 1. full CRLs (or full Authority Revocation Lists) have to 243 be collected; 245 2. OCSP responses, using [OCSP], have to be collected; 247 3. delta CRLs and the relevant associated full CRLs (or 248 full Authority Revocation Lists) are to be collected; 250 4. any available revocation information has to be collected; 251 and 253 5. no revocation information need be collected. 255 2 Protocol Overview 257 The SCVP uses a simple request-response model. That is, the SCVP 258 client creates a request and sends it to the SCVP server, and then 259 the SCVP server creates a single response and sends it to the 260 client. The typical use of SCVP is expected to be over HTTP [HTTP], 261 but it can also be used with email. Appendix A and Appendix B 262 provide the details necessary to use SCVP with HTTP. 264 SCVP includes two request-response pairs. The primary request- 265 response pair handles certificate validation. The secondary 266 request- response pair is used to determine the list of validation 267 policies and default parameters supported by a specific SCVP server. 269 Section 3 defines the certificate validation request, and section 4 270 defines the corresponding response. 272 Section 5 defines the validation policies request, and section 6 273 defines the corresponding response. 275 Appendix A registers MIME types for SCVP requests and responses, 276 and Appendix B describes the use of these MIME types with HTTP. 278 3 Validation Request 280 A SCVP client request to the server MUST be a single CVRequest item. 281 When a SCVPRequest is encapsulated in a MIME body part, 282 application/cv-request MUST be used. 284 There are two forms of SCVP request: unsigned and signed. A signed 285 request can be used to authenticate the client to the server. A 286 server MAY require all requests to be signed, and a server MAY 287 discard all unsigned requests. Alternatively, a server MAY choose 288 to process unsigned requests. 290 The unsigned request consists of a CVRequest encapsulated in a CMS 291 ContentInfo [CMS]. An overview of this structure is provided below. 292 Many details are not shown, but the way that SCVP makes use of CMS 293 is clearly illustrated. 295 ContentInfo { 296 contentType id-ct-scvp-certValRequest, 297 -- (1.2.840.113549.1.9.16.1.10) 298 content CVRequest } 300 The signed request consists of a certValRequest encapsulated in 301 either a SignedData or AuthenticatedData which is in turn 302 encapsulated in a ContentInfo. An overview of this structure is 303 provided below for each of these two cases. Again, many details 304 are not shown, but the way that SCVP makes use of CMS is clearly 305 illustrated. 307 SignedData example: 309 ContentInfo { 310 contentType id-signedData, -- (1.2.840.113549.1.7.2) 311 content SignedData } 313 SignedData { 314 version CMSVersion, 315 digestAlgorithms DigestAlgorithmIdentifiers, 316 encapContentInfo EncapsulatedContentInfo, 317 certificates CertificateSet, -- Optional 318 crls CertificateRevocationLists, -- Optional 319 signerInfos SET OF SignerInfo } -- only one in SCVP 321 SignerInfo { 322 version CMSVersion, 323 sid SignerIdentifier, 324 digestAlgorithm DigestAlgorithmIdentifier, 325 signedAttrs SignedAttributes, -- Required 326 signatureAlgorithm SignatureAlgorithmIdentifier, 327 signature SignatureValue, 328 unsignedAttrs UnsignedAttributes } -- not used in SCVP 329 EncapsulatedContentInfo { 330 eContentType id-ct-scvp-certValRequest, 331 -- (1.2.840.113549.1.9.16.1.10) 332 eContent OCTET STRING } -- Contains CVRequest 334 AuthenticatedData example: 336 ContentInfo { 337 contentType id-ct-authData, 338 -- (1.2.840.113549.1.9.16.1.2) 339 content AuthenticatedData } 341 AuthenticatedData { 342 version CMSVersion, 343 originatorInfo OriginatorInfo, -- Optional 344 recipientInfos RecipientInfos, -- Only SCVP server 345 macAlgorithm MessageAuthenticationCodeAlgorithm, 346 digestAlgorithm DigestAlgorithmIdentifier, -- Optional 347 encapContentInfo EncapsulatedContentInfo, 348 authAttrs AuthAttributes, -- Required 349 mac MessageAuthenticationCode, 350 unauthAttrs UnauthAttributes } -- not used in SCVP 352 EncapsulatedContentInfo { 353 eContentType id-ct-scvp-certValRequest, 354 -- (1.2.840.113549.1.9.16.1.10) 355 eContent OCTET STRING } -- Contains CVRequest 357 All SCVP clients and server MUST support SignedData for signed 358 requests and responses. SCVP clients and servers SHOULD support 359 authenticatedData for authenticated requests and responses. If a 360 server is responding to an unsigned request or a signed request, it 361 MUST use a signed response or an unsigned error response. If a 362 server is responding to an authenticated request, it MUST use an 363 authenticated response or an unsigned error response. 365 The syntax and semantics for signedData, authenticatedData and 366 ContentInfo are defined in [CMS]. The syntax for CVRequest is 367 defined below. The CVRequest item contains the client request. 368 The CVRequest contains the scvpVersion and query items; and the 369 CVRequest MAY also contain the requestor, requestNonce, and 370 reqExtensions items. 372 The CVRequest MUST have the following syntax: 374 CVRequest ::= SEQUENCE { 375 scvpVersion INTEGER, 376 query Query, 377 requestor [0] OCTET STRING OPTIONAL, 378 requestNonce [1] OCTET STRING OPTIONAL, 379 reqExtensions [2] Extensions OPTIONAL } 380 Each of the items within the CVRequest are described in the 381 following sections. 383 3.1 scvpVersion 384 The scvpVersion item tells the version of SCVP used in a request or 385 a response. The value of the scvpVersion item MUST be one (1). 386 Future updates to this specification ought to specify other integer 387 values. 389 3.2 Query 391 The query specifies one or more certificates that are the object of 392 the request; the certificates can be either public key certificates 393 [PKIX-1] or attribute certificates [PKIX-AC]. A query MUST contain 394 a sequence of one or more certificate references, checks, and 395 wantBack items; and a query MAY also contain valPolicy, 396 validityTime, trustAnchors, intermediateCerts, revInfos, and 397 queryExtensions items. 399 Query MUST have the following syntax: 401 Query ::= SEQUENCE { 402 queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, 403 checks CertChecks, 404 wantBack WantBack, 405 requestRefHash BOOLEAN DEFAULT TRUE, 406 includePolResponce BOOLEAN DEFAULT FALSE, 407 inhibitPolMap BOOLEAN DEFAULT FALSE, 408 requireExplicitPol BOOLEAN DEFAULT FALSE, 409 ignoreAnyPol BOOLEAN DEFAULT FALSE, 410 valAlgorithm ValidationAlgorithm, 411 serverContextInfo [0] OCTET STRING OPTIONAL, 412 validityTime [1] GeneralizedTime OPTIONAL, 413 trustAnchors [2] TrustAnchors OPTIONAL, 414 intermediateCerts [3] CertBundle OPTIONAL, 415 revInfos [4] RevocationInfos OPTIONAL, 416 queryExtensions [5] Extensions OPTIONAL } 418 The list of certificate references in the Query item tells the 419 server the certificate(s) for which the client wants information. 420 The OPTIONAL serverContextInfo item tells the server that 421 additional information from a previous request-response in desired. 422 The OPTIONAL validityTime item tells the date and time relative to 423 which the client wants the server to perform the checks. The 424 OPTIONAL valPolicy, trustAnchors, intermediateCerts, and revInfos 425 items provide context for the client request. The OPTIONAL 426 queryExtensions item provides for future expansion of the query 427 syntax. 429 3.2.1 queriedCerts 431 The queriedCerts item, using the CertReference type, identifies the 432 certificate that is the object of the request. The certificate is 433 either a public key certificate or an attribute certificate. The 434 certificate is either directly included or it is referenced. When 435 referenced, a SHA-1 hash value [SHA-1] of the referenced item is 436 included to ensure that the SCVP client and the SCVP server both 437 obtain the same certificate when the referenced certificate is 438 fetched. Certificate references use the ESSCertID type defined in 439 [ESS]. CertReference has the following syntax: 441 CertReference ::= CHOICE { 442 pkc PKCReference, 443 ac ACReference } 445 PKCReference ::= CHOICE { 446 cert [1] Certificate, 447 pkcRef [2] ESSCertID } 449 ACReference ::= CHOICE { 450 attrCert [3] AttributeCertificate, 451 acRef [4] ESSCertID } 453 The ASN.1 definition of Certificate is imported from [PKIX-1]; the 454 definition of AttributeCertificate is imported from [PKIX-AC]; and 455 the definition of ESSCertID is imported from [ESS]. 457 3.2.2 checks 459 The checks item describes the checking that the SCVP client wants 460 the SCVP server to perform on the certificate(s) in the 461 queriedCerts item. The checks item MUST contain a sequence of 462 object identifiers (OIDs). Each OID tells the SCVP server what 463 checking the client expects the server to perform. For each check 464 specified in the request, the SCVP server MUST perform all of the 465 requested checks, or return an error. 467 Revocation status checking inherently includes certification path 468 construction. Also, building a validated certification path does 469 not imply revocation status checks. A server may still choose to 470 perform revocation status checks when performing path construction, 471 although this information cannot be returned to the client. 473 The checks item uses the CertChecks type, which has the following 474 syntax: 476 CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 478 A list of OIDs indicates the checking that the client wants the 479 SCVP server to perform on the certificate(s) in the queriedCerts 480 item. 482 For public key certificates, OIDs are defined for the following 483 checks: 485 - Build a certification path to a trusted root; 487 - Build a validated certification path to a trusted root; and 489 - Do revocation status checks on the certification path. 491 For attribute certificates, OIDs are defined for the following 492 checks: 494 - Build a certification path to a trusted root for the AC 495 issuer; 497 - Build a validated certification path to a trusted root for the 498 AC issuer; 500 - Do revocation status checks on the certification path for the 501 AC issuer; and 503 - Do revocation status checks on the AC as well as the 504 certification path for the AC issuer. 506 For these purposes, the following OIDs are defined: 508 id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 509 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 } 511 id-stc-build-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 } 512 id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 2 } 513 id-stc-build-status-checked-pkc-path 514 OBJECT IDENTIFIER ::= { id-stc 3 } 515 id-stc-build-aa-path OBJECT IDENTIFIER ::= { id-stc 4 } 516 id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 5 } 517 id-stc-build-status-checked-aa-path 518 OBJECT IDENTIFIER ::= { id-stc 6 } 519 id-stc-status-check-ac-and-build-status-checked-aa-path 520 OBJECT IDENTIFIER ::= { id-stc 7 } 522 3.2.3 wantBack 524 The wantBack item describes the kind of information the SCVP client 525 wants from the SCVP server for the certificate(s) in the 526 queriedCerts item. The wantBack item MUST contain a sequence of 527 object identifiers (OIDs). Each OID tells the SCVP server what the 528 client wants to know about the queriedCerts item. For each type of 529 information specified in the request, the server MUST return 530 information regarding its finding (in a successful response). 532 For example, a request might include a checks item that only 533 specifies certification path building and include a wantBack item 534 that requests the return of the certification path built by the 535 server. In this case, the response would not include a status for 536 the validation of the certification path, but it would include a 537 certification path that the server considers to be valid. A client 538 that wants to perform its own certification path validation might 539 use a request of this form. 541 Alternatively, a request might include a checks item that requests 542 the server to build a certification path and validate it, including 543 revocation checking, and include a wantBack item that requests the 544 return of the status. In this case, the response would include 545 only a status for the validation of the certification path. A 546 client that completely delegates certification path validation 547 might use a request of this form. 549 The wantBack item uses the WantBack type, which has the following 550 syntax: 552 WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 554 For public key certificates, the types of information that can be 555 requested are: 557 - Certification path built for the certificate; 559 - Proof of revocation status for each certificate in the 560 certification path; 562 - Status indication; and 564 - Public key from the certificate. 566 For attribute certificates, the types of information that can be 567 requested are: 569 - Certification path built for the AC issuer certificate; 571 - Proof of revocation status for each certificate in the AC 572 issuer certification path; 574 - Proof of revocation status for the attribute certificate; and 576 - Status indication. 578 For these purposes, the following OIDs are defined: 580 id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 581 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 } 583 id-swb-pkc-cert-path OBJECT IDENTIFIER ::= { id-swb 1 } 584 id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 } 585 id-swb-pkc-cert-status OBJECT IDENTIFIER ::= { id-swb 3 } 586 id-swb-pkc-public-key-info OBJECT IDENTIFIER ::= { id-swb 4 } 587 id-swb-aa-cert-path OBJECT IDENTIFIER ::= { id-swb 5 } 588 id-swb-aa-revocation-info OBJECT IDENTIFIER ::= { id-swb 6 } 589 id-swb-ac-revocation-info OBJECT IDENTIFIER ::= { id-swb 7 } 590 id-swb-ac-cert-status OBJECT IDENTIFIER ::= { id-swb 8 } 592 3.2.4 RequestRefHash 594 The requestRefHash controls how the server identifies the 595 corresponding request in the response. By default, the server 596 includes a hash of the request in the response. If the client 597 wants the server to include the full request in the response, 598 RequestRefHash is set to FALSE in the request. The main reason a 599 client would request the server to include the full request in the 600 response is if it wanted to archive the request-response exchange 601 in a single object. That is, the client wants to archive a single 602 object which includes both request and response. 604 SCVP clients and servers MUST support the default behavior. SCVP 605 servers SHOULD support returning the full request. SCVP clients 606 MAY support requesting and processing the full request. 608 3.2.5 IncludePolResponse 610 The includePolResponse controls whether the responce includes the 611 full PolResponce. By default the server will just put the policyID 612 in the response. If the client wants the full PolResponse item to 613 be included by the server in the CVResponce, then the 614 includePolResponse is set to TRUE. The main reason a client would 615 request the server to include the full PolResponse in the 616 CVResponse is if it wanted to archive the request-response exchange 617 in a single object. That is, the client wants to archive a single 618 object that includes both CVResponse and polResponse. 620 SCVP clients and servers MUST support the default behavior. SVCP 621 server SHOULD support returning the full PolResponse. SCVP clients 622 MAY support requesting and processing the full PolResponse. 624 3.2.6 inhibitPolMap 626 The inihibitPolMap specifies an input to the certification path 627 validation algorithm, and it controls whether policy mapping is 628 allowed in the certification path validation (see [PKIX-1], section 629 6.1.1). By default the server allows policy mapping as part of 630 certification path validation. If the client wants the server to 631 inhibit policy mapping, inhibitPolMap is set to TRUE in the request. 633 SCVP clients and servers MUST support the default behavior. SCVP 634 servers SHOULD support inhibiting policy mapping. SCVP clients MAY 635 support inhibiting policy mapping. 637 3.2.7 requireExplicitPol 639 The requireExplicitPol specifies an input to the certification path 640 validation algorithm, and it controls whether there must be at 641 least one valid policy in the certificate policies extension (see 642 [PKIX], section 6.1.1). By default the server accepts no policies 643 in the certificate policies extension of valid certificates. If 644 the client wants the server to require at least one policy, 645 requireExplicitPol is set to TRUE in the request. 647 SCVP clients and servers MUST support the default behavior. SCVP 648 server SHOULD support requiring explicit policies. SCVP clients 649 MAY support requiring explicit policies. 651 3.2.8 ignoreAnyPol 653 The ignoreAnyPol specifies an input to the certification path 654 validation algorithm (see [PKIX], section 6.1.1), and it controls 655 whether the any-policy OID is processed or ignored when evaluating 656 certificate policy. By default the server processes the Any-Policy 657 OID. If the client wants the server to ignore the Any-policy OID, 658 ignoreAnyPol is set to TRUE in the request. 660 SCVP clients and servers MUST support the default behavior. SCVP 661 servers SHOULD support ignoring the Any-Policy OID. SCVP clients 662 MAY support ignoring the Any-Policy OID. 664 3.2.9 serverContextInfo 666 The serverContextInfo item, if present, contains context from a 667 previous request-response exchange with the same SCVP server. It 668 allows the server to return more than one certification path for 669 the same certificate to the client. For example, if a server 670 constructs a particular certification path for a certificate, but 671 the client finds it unacceptable, the client can then send the same 672 query back to the server with the serverContextInfo from the first 673 response, and the server will be able to provide a different 674 certification path (if another one can be found). 676 Contents of the serverContextInfo are opaque to the SCVP client. 677 That is, the client only knows that it needs to return the value 678 provided by the server with the subsequent request to get a 679 different certification path. Note that the subsequent query needs 680 be essentially identical to the previous query. The client MUST 681 NOT change any items other than: 683 - requestNonce; 685 - serverContextInfo; and 686 - the client's signature on the request. 688 .SCVP servers SHOULD support serverContextInfo. SCVP clients MAY 689 support serverContextInfo 691 3.2.10 valAlgorithm 693 The valAlgorithm item, defines the validation algorithm to be used 694 by the SCVP server during certificate validation. The value of 695 this item can be determined by agreement between the client and the 696 server, and is represented as an object identifier. The server 697 might want to assign additional object identifiers that indicate 698 that some settings are used in addition to others given in the 699 request. In this way, the validation algorithm object identifier 700 can be a shorthand for some SCVP options, but not others. 702 The valAlgorithm item uses the ValidationAlg type, which has the 703 following syntax: 705 ValidationAlg ::= SEQUENCE { 706 valAlgId OBJECT IDENTIFIER, 707 parameters ANY DEFINED BY valAlgId OPTIONAL } 709 3.2.10.1 Default Validation Algorithm 711 The client can request the SCVP server's default validation 712 algorithm is used or another algorithm. The object identifier to 713 identify the default validation algorithm is: 715 id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 716 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 } 718 id-svp-defaultValAlg OBJECT IDENTIFIER ::= { id-svp 1 } 720 When the id-svp-defaultValAlg appears as an valAlgId, the 721 parameters MUST be absent. 723 SCVP servers and clients MUST support the default validation 724 algorithm. SCVP servers and clients MAY support other validation 725 algorithms. 727 The meaning of the default validation algorithm is: 729 - Trust anchors will come from the trustAnchors item. If no 730 certificates are specified in the trustAnchors item, then 731 the SCVP server will use trust anchors of its own choosing. 733 - The acceptable policy set will come from the certPolicies 734 item associated with the selected trust anchor. If no 735 certificate policies are specified in the certPolicies item, 736 then the SCVP server will use any-policy. 738 - The SCVP server will check for certificate revocation using 739 CRLs, delta CRLs, OCSP responses, or any other source of 740 revocation information that is available. 742 3.2.10.2 Name Validation Algorithm 744 The name validation Algorithm allows the client to supply a name to 745 the server along with an application identifier. The application 746 identifier defines the name matching rules use to compare the name 747 supplied in the request with the names in the certificate being 748 validated. 750 id-svp-NameValAlg OBJECT IDENTIFIER ::= { id-svp 2 } 752 When the id-svp- NameValAlg appears as an valAlgId, the parameters 753 MUST use the NameValidationAlg syntax: 755 NameValidationAlg ::= SEQUENCE { 756 KeyPurposeId OBJECT IDENTIFIER, 757 ValidationNames GeneralNames } 759 KeyPurposeId and GeneralNames are defined in [PKIX-1]. 761 If more than one name is supplied in the request, all names MUST be 762 of the same type and be valid according to the name matching rules 763 requested. 765 If the KeyPurposeID supplied in the request is id-kp-serverAuth 766 [PKIX-1], then GeneralNames supplied in the request MUST be a DNS 767 name, and the matching rules to be used are defined in [HTTP-TLS]. 769 If the KeyPurposeID supplied in the request is id-kp-mailProtection 770 [PKIX-1], then GeneralNames supplied in the request MUST be a 771 rfc822 name, and the matching rule MUST be a case insensitive 772 comparison of the whole sting. For example user@example.com 773 matches USER@Example.COM, but not auser@example.com, 774 user@mail.example.com, or user@example1.com 776 3.2.10.3 Name Validation Algorithm Errors 778 The following errors are defined for the Name Validation Algorithm 780 id-nvae OBJECT IDENTIFIER ::= { id-svp-NameValPol 1 } 782 id-nvae-NameMismatch OBJECT IDENTIFIER ::= { id-nvae 1 } 783 id-nvae-NoCertName OBJECT IDENTIFIER ::= { id-nvae 2 } 784 id-nvae-UnknownPupose OBJECT IDENTIFIER ::= { id-nvae 3 } 785 id-nvae-BadName OBJECT IDENTIFIER ::= { id-nvae 4 } 786 id-nvae-BadNameType OBJECT IDENTIFIER ::= { id-nvae 5 } 787 id-nvae-MixedNames OBJECT IDENTIFIER ::= { id-nvae 6 } 788 Name mismatch means the client supplied a name with the validation 789 policy, which the server recognized and the server found 790 corresponding name type in the certificate, but was unable to find 791 a match to the name supplied. For example, the client supplied a 792 DNS name of example1.com, the certificate contained a DNS name of 793 example.com. 795 NoCertName means the client supplied a name with the validation 796 policy, which the server recognized, but the server could not find 797 the corresponding name type in the certificate. For example, the 798 client supplied a DNS name of example1.com, the certificate only 799 contained a rfc822 name of user@example.com. 801 UnknownPupose means the client supplied KeyPurposeID which the 802 server does not recognize. 804 BadName means the client supplied either and empty or malformed 805 name in the request. 807 BadNameType means the client supplied an inappropriate name type 808 for the key purpose. For example, the client specified a key 809 purpose ID of id-kp-serverAuth, and a rfc822 name of 810 user@example.com. 812 MixedNames means the client supplied multiple names in the request 813 of different types. 815 3.2.11 validityTime 817 The OPTIONAL validityTime item tells the date and time relative to 818 which the SCVP client wants the server to perform the checks. If 819 the validityTime is not present, the server MUST perform the 820 validation using the date and time at which the server processes 821 the request. If the validityTime is present, it MUST be encoded as 822 GeneralizedTime. The validityTime provided MUST be a retrospective 823 time since the server can only perform a validity check using the 824 current time (default) or previous time. A Server can ignore the 825 validityTime provided in the request if the time is within the 826 clock skew of the servers current time. 828 GeneralizedTime values MUST be expressed Greenwich Mean Time (Zulu) 829 and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even 830 when the number of seconds is zero. GeneralizedTime values MUST 831 NOT include fractional seconds. 833 The information in the corresponding CertReply item in the response 834 MUST be formatted as if the server created the response at the time 835 indicated in the validityTime. However, if the server does not 836 have appropriate historical information, the server MUST return an 837 error. 839 SCVP servers MUST apply a clock skew to the validity time to allow 840 for minor time synchronization errors. The default value is 10 841 minutes. If the server uses a value other than the default it MUST 842 include the clock skew value in the validation policy response. 844 SCVP servers MUST support using its current time, and SHOULD 845 support the client setting the validityTime in the request. SCVP 846 clients MAY support validityTime. 848 3.2.12 trustAnchors 850 The OPTIONAL trustAnchors item specifies the trust anchors to be 851 used by the SCVP server. One or more certificate policy MAY be 852 associated with each trust anchor. If a trustAnchors item is 853 present, the server MUST NOT use any certification path trust 854 anchors other than those provided. 856 The TrustAnchors type contains one or more trust anchor 857 specification. A certificate reference can be used to identify the 858 trust anchor by certificate hash and optionally a distinguished 859 name with serial number. Alternatively, trust anchors can be 860 provided directly. The order of trust anchor specifications within 861 the sequence is not important. Any CA certificate can be provided 862 as a trust anchor. 864 The OPTIONAL certPolicies item specifies a list of policy 865 identifiers that the SCVP server MUST use when forming and 866 validating a certification path that terminates at the associated 867 trust anchor. If certPolicies is not specified, then any-policy 868 MUST be used. 870 The trust anchor itself, regardless of its form, MUST NOT be 871 included in any certification path constructed by the SCVP server. 873 TrustAnchors has the following syntax: 875 TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF TrustAnchor 877 TrustAnchor ::= SEQUENCE { 878 anchor PKCReference, 879 certPolicies [1] SEQUENCE SIZE (1..MAX) OF 880 OBJECT IDENTIFIER OPTIONAL } 881 -- if absent, use any-policy 883 SCVP server MUST support TrustAnchor. SCVP clients SHOULD support 884 trust anchors. 886 3.2.13 intermediateCerts 888 The OPTIONAL intermediateCerts item helps the SCVP server create 889 valid certification paths. The intermediateCerts item, when 890 present, provides certificates that the server MAY use when forming 891 a certification path. The certificates in the intermediateCerts 892 item MAY be used by the server in addition to any other 893 certificates that the server can access when building certification 894 paths. The intermediateCerts item, when present, MUST contain at 895 least one certificate. The intermediateCerts item MUST be 896 structured as a CertBundle. The certificates in the 897 intermediateCerts MUST NOT be considered as valid by the server 898 just because they are present in this item. 900 The CertBundle type contains one or more certificate references. 901 The order of the entries in the bundle is not important. 902 CertBundle has the following syntax: 904 CertBundle ::= SEQUENCE SIZE (1..MAX) OF PKCReference 906 SCVP servers MUST support intermediateCerts. SCVP clients SHOULD 907 support intermediateCerts. 909 3.2.14 revInfos 911 The OPTIONAL revInfo item specifies revocation information such as 912 CRLs, delta CRLs [PKIX-1], and OCSP responses [OCSP] that the SCVP 913 server MAY use when validating certification paths. The purpose of 914 the revInfos item is to provide revocation information to which the 915 server might not otherwise have access, such as an OCSP response 916 that the client received along with the certificate. Note that the 917 information in the revInfos item might not be used by the server. 918 For example, the revocation information might be associated with 919 certificates that the server does not use in certification path 920 building. 922 It is courteous to the SCVP server to separate CRLs and delta CRLs. 923 However, since the two share a common syntax, SCVP servers SHOULD 924 accept delta CRLs even if they are identified as regular CRLs by 925 the SCVP client. 927 CRLs, delta CRLs, and OCSP responses can be provided as revocation 928 information. If needed, additional object identifiers can be 929 assigned for additional revocation information types in the future. 931 The revInfos item uses the RevocationInfos type, which has the 932 following syntax: 934 RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo 936 RevocationInfo ::= CHOICE { 937 crl [0] CertificateList, 938 delta-crl [1] CertificateList, 939 ocsp [2] OCSPResponse, 940 other [3] OtherRevInfo } 942 OtherRevInfo ::= SEQUENCE { 943 riType OBJECT IDENTIFIER, 944 riValue ANY DEFINED BY riType } 946 3.2.15 queryExtensions 948 The OPTIONAL queryExtensions item contains Extensions. If present, 949 each extension in the sequence extends the query. This 950 specification does not define any extensions, the facility is 951 provided to allow future specifications to extend SCVP. The syntax 952 for extensions is imported from [PKIX-1]. The queryExtensions item, 953 when present, MUST contain a sequence of extension items, and each 954 of extension MUST contain extnID, critical, and extnValue items. 956 The extnID item is an identifier for the extension. It contains 957 the object identifier that names the extension. 959 The critical item is a BOOLEAN. Each extension is designated as 960 either critical (with a value of TRUE) or non-critical (with a 961 value of FALSE). An SCVP server MUST reject the query if it 962 encounters a critical extension it does not recognize; however, a 963 non-critical extension MAY be ignored if it is not recognized. 965 The extnValue item contains an octet string. Within the octet 966 string is the extension value. An ASN.1 type is specified for each 967 extension, identified by the associated extnID object identifier. 969 3.3 Requestor 971 The OPTIONAL requestor item is a reference local to the requestor. 972 The value is only of local significance to the requestor. If the 973 SCVP client includes a requestor value in the request, then the 974 SCVP server MUST return the same value in the response. 976 The requestor item MUST be an octet string. No provisions are made 977 to ensure uniqueness of the requestor octet string; however, all of 978 the octets MUST have values other than zero. 980 3.4 requestNonce 982 The OPTIONAL requestNonce item contains an identifier generated by 983 the SCVP client for the request. If the client includes a 984 requestNonce value in the request, then the server MUST return the 985 same value in the response. The client SHOULD include a 986 requestNonce item in every request to prevent an attacker from 987 acting as a man-in-the-middle by replaying old responses from the 988 server. The requestNonce value SHOULD change with every request 989 sent by the client. 991 The requestNonce item, if present, MUST be an octet string that was 992 generated exclusively for this purpose. 994 3.5 reqExtensions 996 The OPTIONAL reqExtensions item contains Extensions. If present, 997 each Extension in the sequence extends the request. This 998 specification does not define any extensions, the facility is 999 provided to allow future specifications to extend the SCVP. The 1000 syntax for Extensions is imported from [PKIX-1]. The reqExtensions 1001 item, when present, MUST contain a sequence of extension items, and 1002 each of extension MUST contain extnID, critical, and extnValue 1003 items. 1005 The extnID item is an identifier for the extension. It contains 1006 the object identifier that names the extension. 1008 The critical item is a BOOLEAN. Each extension is designated as 1009 either critical (with a value of TRUE) or non-critical (with a 1010 value of FALSE). An SCVP server MUST reject the query if it 1011 encounters a critical extension it does not recognize; however, a 1012 non-critical extension MAY be ignored if it is not recognized. 1014 The extnValue item contains an octet string. Within the octet 1015 string is the extension value. An ASN.1 type is specified for each 1016 extension, identified by the associated extnID object identifier. 1018 4 Validation Response 1020 A SCVP server response to the client MUST be a single CVResponse 1021 item. A CVResponse item is carried in an application/cv-response 1022 MIME body part. 1024 There are two forms of an SCVP response: unsigned and signed. An 1025 unsigned response MUST only be generated for an error status. An 1026 overview of the structure used for an unsigned response is provided 1027 below. Many details are not shown, but the way that SCVP makes use 1028 of CMS is clearly illustrated. 1030 ContentInfo { 1031 contentType id-ct-scvp-certValResponse, 1032 -- (1.2.840.113549.1.9.16.1.11) 1033 content CVResponse } 1035 The signed response consists of a CVResponse encapsulated in either 1036 a SignedData or an AuthenticatedData which is in turn encapsulated 1037 in a ContentInfo. An overview of the structure used for a signed 1038 response is provided below. As above, many details are not shown, 1039 but the way that SCVP makes use of CMS is clearly illustrated. 1041 Signed Data Example: 1043 ContentInfo { 1044 contentType id-signedData, -- (1.2.840.113549.1.7.2) 1045 content SignedData } 1046 SignedData { 1047 version CMSVersion, 1048 digestAlgorithms DigestAlgorithmIdentifiers, 1049 encapContentInfo EncapsulatedContentInfo, 1050 certificates CertificateSet, -- MUST include server cert 1051 crls CertificateRevocationLists, -- Optional 1052 signerInfos SET OF SignerInfos } -- Only one in SCVP 1054 SignerInfo { 1055 version CMSVersion, 1056 sid SignerIdentifier, 1057 digestAlgorithm DigestAlgorithmIdentifier, 1058 signedAttrs SignedAttributes, -- (Required) 1059 signatureAlgorithm SignatureAlgorithmIdentifier, 1060 signature SignatureValue, 1061 unsignedAttrs UnsignedAttributes } -- Not used in SCVP 1063 EncapsulatedContentInfo { 1064 eContentType id-ct-scvp-psResponse, 1065 -- (1.2.840.113549.1.9.16.1.11) 1066 eContent OCTET STRING } -- Contains CVResponse 1068 AuthenticatedData Example: 1070 ContentInfo { 1071 contentType id-ct-authData, 1072 -- (1.2.840.113549.1.9.16.1.2) 1073 content AuthenticatedData } 1075 AuthenticatedData ::= SEQUENCE { 1076 version CMSVersion, 1077 originatorInfo OriginatorInfo, -- Optional 1078 recipientInfos RecipientInfos, -- Only for SCVP client 1079 macAlgorithm MessageAuthenticationCodeAlgorithm, 1080 digestAlgorithm DigestAlgorithmIdentifier, -- Optional 1081 encapContentInfo EncapsulatedContentInfo, 1082 authAttrs AuthAttributes, -- Required 1083 mac MessageAuthenticationCode, 1084 unauthAttrs UnauthAttributes } -- Not used in SCVP 1086 EncapsulatedContentInfo { 1087 eContentType id-ct-scvp-psResponse, 1088 -- (1.2.840.113549.1.9.16.1.11) 1089 eContent OCTET STRING } -- Contains CVResponse 1091 The SCVP server MUST include its own certificate in the 1092 certificates field within SignedData. The SCVP server MUST include 1093 its own certificate in the certificates field within 1094 AuthenticatedData if the HMAC key is derived using a public key 1095 from a certificate. Other certificates can also be included. The 1096 SCVP server MAY also provide one or more CRLs in the crls field 1097 within SignedData. 1099 The signedAttrs within SignerInfo MUST include the content-type and 1100 message-digest attributes defined in [CMS] as well as the 1101 SigningCertificate attribute as defined in [ESS]. Within the 1102 SigningCertificate attribute, the first certificate identified in 1103 the sequence of certificate identifiers MUST be the certificate of 1104 the SCVP server. The inclusion of other certificate identifiers in 1105 the SigningCertificate attribute is OPTIONAL. The inclusion of 1106 policies in the SigningCertificate attribute is also OPTIONAL. The 1107 policies item in the SigningCertificate attribute SHALL not be 1108 present. 1110 The value of the message-digest attribute in the signedAttrs within 1111 SignerInfo MAY be used as an identifier of the response generated 1112 by the SCVP server. 1114 The CVResponse item contains the server response. The CVResponse 1115 MUST contain the scvpVersion, producedAt, responseStatus, and 1116 requestRef items. The CVResponse MAY also contain the requestor, 1117 responder, replyObjects, requestNonce, serverContextInfo, and 1118 respExtensions optional items. The replyObjects item MUST contain 1119 exactly one CertReply item for each certificate requested. The 1120 requestor and the responder items MUST be included if the request 1121 included a requestor item. The requestNonce item MUST be included 1122 if the request included a requestNonce item. 1124 The CVResponse MUST have the following syntax: 1126 CVResponse ::= SEQUENCE { 1127 scvpVersion INTEGER, 1128 policyID INTEGER, 1129 producedAt GeneralizedTime, 1130 responseStatus ResponseStatus, 1131 requestRef RequestReference, 1132 requestor [1] OCTET STRING OPTIONAL, 1133 responder [2] OCTET STRING OPTIONAL, 1134 replyObjects [3] ReplyObjects OPTIONAL, 1135 requestNonce [4] OCTET STRING OPTIONAL, 1136 serverContextInfo [5] OCTET STRING OPTIONAL, 1137 polResponse [6] OCTET STRING OPTIONAL, 1138 respExtensions [7] Extensions OPTIONAL } 1140 4.1 scvpVersion 1142 The syntax and semantics of the scvpVersion item is described in 1143 section 3.1. 1145 4.2 policyID 1146 The policy ID in effet when the server processed the request. See 1147 section 7.2 for details. 1149 4.3 producedAt 1151 The producedAt item tells the date and time at which the SCVP 1152 server generated the response. The producedAt item represents the 1153 date and time in UTC, using the GeneralizedTime type and is 1154 independent of the validation time use. 1156 GeneralizedTime value MUST be expressed Greenwich Mean Time (Zulu) 1157 and MUST be interpreted as defined in section 3.2.11 1159 4.4 responseStatus 1161 The responseStatus item gives status information to the SCVP client 1162 about its request. The responseStatus item has a numeric status 1163 code and an optional string that is a sequence of characters from 1164 the ISO/IEC 10646-1 character set encoded with the UTF-8 1165 transformation format defined in [UTF8]. 1167 The string MAY optionally be used to transmit status information. 1168 The client MAY choose to display the string to the human user. 1169 However, because there is no way to know the languages understood 1170 by the human user, the string may be of little or no assistance. 1172 The responseStatus item uses the ResponseStatus type, which has the 1173 following syntax: 1175 ResponseStatus ::= SEQUENCE { 1176 statusCode SCVPStatusCode, 1177 errorMessage [0] UTF8String OPTIONAL } 1179 SCVPStatusCode ::= ENUMERATED { 1180 okay (0), 1181 skipUnrecognizedItems (1), 1182 tooBusy (10), 1183 internalError (12), 1184 badStructure (20), 1185 unsupportedVersion (21), 1186 abortUnrecognizedItems (22), 1187 unrecognizedSigKey (23), 1188 badSignature (24), 1189 unableToDecode (25), 1190 notAuthorized (26), 1191 unsupportedChecks (27), 1192 unsupportedWantBacks (28), 1193 unsupportedSignature (29), 1194 invalidSignature (30), 1195 relayingLoop (40), 1196 fullRequestRefUnsuported (51}, 1197 fullPolRequestUnsuported (52), 1198 inhibitPolMapUnsuported (53), 1199 requireExpPolUnsuported (54), 1200 ignoreAnyPolUnsuported (55), 1201 validityTimeUnsuported (56) } 1203 The SCVPStatusCode values have the following meaning: 1205 0 The request was fully processed 1206 1 The request included some unrecognized items; however, 1207 processing was able to continue ignoring them 1208 10 Too busy; try again later 1209 12 Internal server error occurred 1210 20 The structure of the request was wrong 1211 21 The version of request is not supported by this server 1212 22 The request included unrecognized items, and the server was 1213 not able to continue processing 1214 23 The key given in the RequestSignature is not recognized 1215 24 The signature or MAC did not match the body of the request 1216 25 The encoding was not understood 1217 26 The request was not authorized 1218 27 The request included unsupported checks items, and the 1219 server was not able to continue processing 1220 28 The request included unsupported want back items, and the 1221 server was not able to continue processing 1222 29 The server does not support the signature or MAC algorithm 1223 used by the client to sign the request 1224 30 The server could not validate the client's signature or MAC 1225 on the request 1226 40 The request was previously relayed by the same server 1227 50 The request contained an unrecognized validation algorithm 1228 51 The server does not returning the full request in the 1229 response 1230 52 The server does not returning the full policy responce 1231 53 The server does not support inhibiting policy mapping 1232 54 The server does not support requiring explicit policy 1233 55 The server does not support ignoring the any policy OID 1234 56 The server only validates requests using current time 1236 Status codes 0-9 are reserved for codes where the request was 1237 processed by the server and therefore MUST be sent in a signed 1238 response. Status codes 10 and above indicate an error and MUST 1239 therefore be sent in an unsigned response. 1241 4.5 requestReference 1243 The requestRef allows the SCVP server to identify the request that 1244 corresponds to this response. It associates the response to a 1245 particular request using either a hash of the request or a copy of 1246 CVRequest from the request. The hash is calculated as described in 1247 [CMS] for signedData and authenticatedData. That is, it covers the 1248 encapsulated content and authenticated attributes but not the 1249 unauthenticated attributes. 1251 The requestRef item does not provide authentication, but the 1252 requestRef does allow the client to determine that the request was 1253 not maliciously modified. 1255 The requestRef item allows the client to associate a response with 1256 a request. The requestNonce provides an alternative mechanism for 1257 matching requests and responses if the client has selected to 1258 include a full responce. When the fullRequest alternative is used, 1259 the response provides a single data structure that is suitable for 1260 archive of the transaction. 1262 The requestRef item uses the RequestReference type, which has the 1263 following syntax: 1265 RequestReference ::= CHOICE { 1266 requestHash [1] HashValue, -- hash of CVRequest 1267 fullRequest [2] CVRequest } 1269 4.5.1 requestHash 1271 The requestHash item is the hash of the CVRequest. By default, 1272 SHA-1 is used as the one-way hash function, but others can be used. 1273 The requestHash item serves two purposes. First, it allows a 1274 client to determine that the request was not maliciously modified. 1275 Second, it allows the client to associate a response with a request 1276 when using connectionless protocols. The requestNonce provides an 1277 alternative mechanism for matching requests and responses. 1279 The requestHash item uses the HashValue type, which has the 1280 following syntax: 1282 HashValue ::= SEQUENCE { 1283 algorithm AlgorithmIdentifier DEFAULT { sha-1 }, 1284 value OCTET STRING } 1286 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1287 oiw(14) secsig(3) algorithm(2) 26 } 1289 The algorithm identifier for SHA-1 is imported from [PKIX-ALG]. It 1290 is repeated here for convenience. 1292 4.5.2 fullRequest 1294 Like requestHash, the fullRequest alternative allows a client to 1295 determine that the request was not maliciously modified. It also 1296 provides a single data structure that is suitable for archive of 1297 the transaction. 1299 The fullRequest item uses the CVRequest type. The syntax and 1300 semantics of the PSRequest type are described in section 3. 1302 4.6 Requestor 1304 The OPTIONAL requestor item is used to identify the requestor. The 1305 value is only of local significance to the requestor. If the SCVP 1306 client includes a requestor value in the request, then the SCVP 1307 server MUST return the same value in the response. 1309 The requestor item MUST be an octet string. No provisions are made 1310 to ensure uniqueness of the requestor octet string; however, all of 1311 the octets MUST have values other than zero. 1313 4.7 responder 1315 The OPTIONAL responder item is used to identify the server. The 1316 value chosen is only of local significance to the SCVP server. The 1317 responder items MUST be included if the request included a 1318 requestor item. 1320 The responder item MUST be an octet string. No provisions are made 1321 to ensure uniqueness of the requestor octet string; however, all of 1322 the octets MUST have values other than zero. 1324 4.8 replyObjects 1326 The replyObjects item returns requested objects to the SCVP client, 1327 each of which tells the client about a single certificate from the 1328 request. The replyObjects item MUST be present in the response, 1329 unless the response is reporting an error. The CertReply item MUST 1330 contain cert, replyStatus, replyValTime, replyChecks, replyWantBack, 1331 and valPolicy items; and the CertReply item MAY contain the 1332 nextUpdate and certReplyExtensions optional items. 1334 A non-error response MUST contain one CertReply for each Query item 1335 in the request. The order is important. The first CertReply in 1336 the sequence MUST correspond to the first Query item in the 1337 request; the second CertReply in the sequence MUST correspond to 1338 the second Query item in the request; and so on. 1340 The checks item in the request determines the content of the 1341 replyChecks item in the response. The wantBack item in the request 1342 determines the content of the replyWantBacks item in the response. 1343 The queryExtensions items in the request controls the absence or 1344 the presence and content of the certReplyExtensions item in the 1345 response. 1347 The replyObjects item uses the ReplyObjects type, which has the 1348 following syntax: 1350 ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply 1352 CertReply ::= SEQUENCE { 1353 cert CertReference, 1354 replyStatus ReplyStatus, 1355 replyValTime GeneralizedTime, 1356 replyChecks ReplyChecks, 1357 replyWantBacks ReplyWantBacks, 1358 valAlg ValidationAlg, 1359 nextUpdate [1] GeneralizedTime OPTIONAL, 1360 certReplyExtensions [2] Extensions OPTIONAL } 1362 4.8.1 cert 1364 The cert item contains either the public key certificate or the 1365 attribute certificate or a reference to the certificate about which 1366 the client is requesting information. 1368 The ASN.1 definition of Certificate is imported from [PKIX-1]; and 1369 the definition of AttributeCertificate is imported from [PKIX-AC]. 1371 4.8.2 replyStatus 1373 The replyStatus item gives status information to the client about 1374 the request for the specific certificate. Note that the 1375 responseStatus item is different than the replyStatus item. The 1376 responseStatus item is the status of the whole request, while the 1377 replyStatus item is the status for the individual query item. 1379 The replyStatus item uses the ReplyStatus type, which has the 1380 following syntax: 1382 ReplyStatus ::= ENUMERATED { 1383 success (0), 1384 unrecognizedCheck (1), 1385 unrecognizedWantBack (2), 1386 malformedPKC (3), 1387 malformedAC (4), 1388 unrecognizedCertPolicy (5), 1389 unrecognizedValPolicy (6), 1390 unrecognizedExtension (7), 1391 unavailableValidityTime (8), 1392 referenceCertHashFail (9), 1393 certPathConstructFail (10), 1394 certPathNotValid (11), 1395 certPathNotValidNow (12) } 1397 The meaning of the various ReplyStatus values are: 1399 0 Success: a definitive answer follows 1400 1 Failure: an OID in the check item is not recognized 1401 2 Failure: an OID in the wantBack item is not recognized 1402 3 Failure: the public key certificate was malformed 1403 4 Failure: the attribute certificate was malformed 1404 5 Failure: the certificate policy OID is not recognized 1405 6 Failure: the validation policy OID is not recognized 1406 7 Failure: the extension OID is not recognized 1407 8 Failure: historical data for the requested validity time is 1408 not available 1409 9 Failure: the referenced certificate did not match the hash 1410 value provided 1411 10 Failure: no certification path could be constructed 1412 11 Failure: the constructed certification path is invalid 1413 12 Failure: the constructed certification path is invalid, but 1414 a query at a later time may be successful 1416 Codes 3 and 4 are used to tell the client that the request was 1417 properly formed, but the certificate in question was not. This is 1418 especially useful to clients that do not parse certificates. 1420 4.8.3 replyValTime 1422 The replyValTime item tells the time at which the information in 1423 the CertReply was correct. The replyValTime item represents the 1424 date and time in UTC, using GeneralizedTime type. The encoding 1425 rules for GeneralizedTime in section 3.2.11 MUST be used. 1427 Within the request, the optional validityTime item tells the date 1428 and time relative to which the SCVP client wants the server to 1429 perform the checks. If the validityTime is not present, the server 1430 MUST respond as if the client provided the date and time at which 1431 the server processes the request. 1433 The information in the CertReply item MUST be formatted as if the 1434 server created this portion of response at the time indicated in 1435 the validityTime item of the query. However, if the server does 1436 not have appropriate historical information, the server MAY either 1437 return an error or return information for a later time. 1439 4.8.4 replyChecks 1441 The replyChecks contains the responses to the checks item in the 1442 query. The replyChecks item repeats the object identifier (OID) 1443 from the query and an integer. The value of the integer indicates 1444 whether the requested check was successful. The OIDs in the checks 1445 item of the query are used to identify the corresponding 1446 replyChecks values. The OIDs in the replyChecks item MUST match 1447 the OIDs in the checks item in the request. 1449 The replyChecks item uses the ReplyChecks type, which has the 1450 following syntax: 1452 ReplyChecks ::= SEQUENCE OF ReplyCheck 1454 ReplyCheck ::= SEQUENCE { 1455 check OBJECT IDENTIFIER, 1456 status INTEGER } 1457 The status value for public key certification path building to a 1458 trusted root, { id-stc 1 }, can be one of the following: 1460 0: Built a path 1461 1: Could not build a path 1463 The status value for public key certification path building to a 1464 trusted root along with simple validation processing, { id-stc 2 }, 1465 can be one of the following: 1467 0: Valid 1468 1: Not valid 1470 The status value for public key certification path building to a 1471 trusted root along with complete status checking, { id-stc 3 }, can 1472 be one of the following: 1474 0: Good 1475 1: Revoked 1476 2: Unknown 1477 3: Unavailable 1479 The status value for AC issuer certification path building to a 1480 trusted root, { id-stc 4 }, can be one of the following: 1482 0: Built a path 1483 1: Could not build a path 1485 The status value for AC issuer certification path building to a 1486 trusted root along with simple validation processing, { id-stc 5 }, 1487 can be one of the following: 1489 0: Valid 1490 1: Not valid 1492 The status value for AC issuer certification path building to a 1493 trusted root along with complete status checking, { id-stc 6 }, can 1494 be one of the following: 1496 0: Good 1497 1: Revoked 1498 2: Unknown 1499 3: Unavailable 1501 The status value for revocation status checking of an AC as well as 1502 AC issuer certification path building to a trusted root along with 1503 complete status checking, { id-stc 7 }, can be one of the 1504 following: 1506 0: Good 1507 1: Revoked 1508 2: Unknown 1509 3: Unavailable 1511 4.8.5 replyWantBack 1513 The replyWantBack contains the responses to the wantBack item in 1514 the request. The replyWantBack item includes the object identifier 1515 (OID) from the wantBack item in the request and an octet string. 1516 Within the octet string is the requested value. The OIDs in the 1517 wantBack item in the request are used to identify the corresponding 1518 reply value. The OIDs in the replyWantBack item MUST match the 1519 OIDs in the wantBack item in the request. 1521 The replyWantBack item uses the ReplyWantBack type, which has the 1522 following syntax: 1524 ReplyWantBacks ::= SEQUENCE OF ReplyWantBack 1526 ReplyWantBack::= SEQUENCE { 1527 wb OBJECT IDENTIFIER, 1528 value OCTET STRING } 1530 The octet string value for the certification path used to verify 1531 the certificate in the request, { id-swb 1 }, contains the 1532 CertBundle type. The syntax and semantics of the CertBundle type 1533 are described in section 3.2.7. 1535 The octet string value for the proof of revocation status, { id-swb 1536 2 }, contains the RevocationInfo type. The syntax and semantics of 1537 the RevocationInfo type are described in section 3.2.9. 1539 The octet string value for the public key certificate status, { id- 1540 swb 3 }, contains an ASN.1 BOOLEAN type. The value will be TRUE if 1541 the certificate is valid, and the value will be FALSE if the 1542 certificate is not valid. 1544 The octet string value for the public key information, { id-swb 4 }, 1545 contains the SubjectPublicKeyInfo type. The syntax and semantics 1546 of the SubjectPublicKeyInfo type are described in [PKIX-1]. 1548 The octet string value for the AC issuer certification path used to 1549 verify the certificate in the request, { id-swb 5 }, contains the 1550 CertBundle type. The syntax and semantics of the CertBundle type 1551 are described in section 3.2.7. 1553 The octet string value for the proof of revocation status of the AC 1554 issuer certification path, { id-swb 6 }, contains the 1555 RevocationInfo type. The syntax and semantics of the 1556 RevocationInfo type are described in section 3.2.9. 1558 The octet string value for the proof of revocation status of the 1559 attribute certificate, { id-swb 7 }, contains the RevocationInfo 1560 type. The syntax and semantics of the RevocationInfo type are 1561 described in section 3.2.9. 1563 The octet string value for the attribute certificate status, { id- 1564 swb 8 }, contains an ASN.1 BOOLEAN type. The value will be TRUE if 1565 the certificate is valid, and the value will be FALSE if the 1566 certificate is not valid. 1568 4.8.6 valAlgorithm 1570 The valAlgorithm item indicates the validation algorithm used by 1571 the SCVP server. The server MUST include the validation algorithm 1572 that was used. 1574 The syntax and semantics of the valAlgorithm item are descried in 1575 section 3.2.10 1577 4.8.7 nextUpdate 1579 The nextUpdate item tells the time at which the server expects a 1580 refresh of information regarding the validity of the certificate to 1581 become available. The nextUpdate is especially interesting if the 1582 certificate revocation status information is not available or the 1583 certificate is suspended. The nextUpdate item represents the date 1584 and time in UTC, using the GeneralizedTime type. The encoding 1585 rules for GeneralizedTime in section 3.2.11 MUST be used. 1587 4.8.8 certReplyExtensions 1589 The certReplyExtensions contains the responses to the 1590 queryExtension item in the request. The singleReplyExtensions item 1591 uses the Extensions type defined in [PKIX-1]. The object 1592 identifiers (OIDs) in the queryExtension item in the request are 1593 used to identify the corresponding reply value. The 1594 certReplyExtensions item, when present, contains a sequence of 1595 Extension items, each of which contains an extnID item, a critical 1596 item, and an extnValue item. 1598 The extnID item is an identifier for the extension. It contains 1599 the OID that names the extension, and it MUST match one of the OIDs 1600 in the queryExtension item in the request. 1602 The critical item is a BOOLEAN, and it MUST be set to FALSE. 1603 The extnValue item contains an OCTET STRING. Within the OCTET 1604 STRING is the extension value. An ASN.1 type is specified for each 1605 extension, and identified by extnID. 1607 4.9 requestNonce 1609 The requestNonce optional item contains an identifier generated by 1610 the client for the request. If the client includes a requestNonce 1611 value in the request, then the server MUST return the same value in 1612 the response. 1614 The requestNonce item uses the octet string type. 1616 4.10 serverContextInfo 1618 The serverContextInfo item in a response is a mechanism for the 1619 server to pass some opaque context information to the client. If 1620 the client does not like the certification path retuned, it can 1621 make a new query and pass along this context information. 1623 Section 3.2.4 contains information about the client usage of this 1624 item. 1626 The context information is opaque to the client, but it provides 1627 information to the server that ensures that a different 1628 certification path will be returned (if another one can be found). 1629 The context information could indicate state on the server or it 1630 could contain a sequence of hashes of certification paths that have 1631 already returned to the client. The protocol does not dictate any 1632 structure or requirements for this item. However, implementers 1633 should review the Security Considerations section of this document 1634 before selecting a structure. 1636 Servers that are incapable of returning additional paths MUST NOT 1637 include the serverContextInfo item in the response. 1639 4.11 respExtensions 1641 The respExtensions item MAY contain Extensions. If present, each 1642 Extension in the sequence extends the request. This specification 1643 does not define any extensions, the facility is provided to allow 1644 future specifications to extend the SCVP. The syntax for 1645 Extensions is imported from [PKIX-1]. The respExtensions item, 1646 when present, contains a sequence of Extension items, each of which 1647 contains an extnID item, a critical item, and an extnValue item. 1649 The extnID item is an identifier for the extension. It contains 1650 the object identifier (OID) that names the extension. 1651 The critical item is a BOOLEAN. Each extension is designated as 1652 either critical (with a value of TRUE) or non-critical (with a 1653 value of FALSE). An SCVP client MUST reject the response if it 1654 encounters a critical extension it does not recognize; however, a 1655 non-critical extension MAY be ignored if it is not recognized. 1657 The extnValue item contains an OCTET STRING. Within the OCTET 1658 STRING is the extension value. An ASN.1 type is specified for each 1659 extension, and identified by extnID. 1661 5 SCVP Server certificates 1662 The SCVP server MUST have a single digital signature certificae in 1663 use at any one time and that certificaet is MUST be used to sign 1664 the validation policy responces. The digital signature certificate 1665 MUST have either the digital signatue or the non-repudiation bits 1666 set or both in the key usage extesnion of the certificate [PKIX-1 1667 section 4.2.1.3]. A SCVP server MUST have a single key agrement 1668 certificate in use at any one time if the server suports 1669 authenticatedData signed requests. 1671 5.1 SCVP Server Name 1673 5.1.1 SVCP Extended Key Usage 1675 It is necessary to ensure that the entity signing the validation 1676 response has been authorized to do so. SCVP response signing 1677 delegation SHALL be designated by the inclusion of a key pupose OID 1678 in an extendedKeyUsage certificate extension in the SCVP Server 1679 certificate. 1681 5.1.2 SCVP Server certificate validation 1683 SCVP clients MUST be capable of detecting and enforcing use of the 1684 key purpose value as described above. They MAY provide a means of 1685 locally configuring one or more SCVP servers, and specifying the 1686 set SCVP servers which are trusted. They MUST reject the response 1687 if the certificate required to validate the signature on the 1688 validation response fails to any one of the following criteria: 1690 - Matches a local configuration of SCVP server for the 1691 certificate in question; or 1693 - Includes a value of id-?? in an ExtendedKeyUsage extension. 1695 6 Server Policies Request 1697 A SCVP client uses the PolRequest item to request the list of 1698 validation policies supported by the SCVP server. When a 1699 PolRequest is encapsulated in a MIME body part, it MUST be carried 1700 in an application/cv-policies-request MIME body part. 1702 The request consists of a PolRequest encapsulated in a ContentInfo. 1703 The request is not signed by the client. 1705 ContentInfo { 1706 contentType id-ct-scvp-valPolRequest, 1707 -- (1.2.840.113549.1.9.16.1.12) 1708 content PolRequest } 1710 The PolRequest type has the following syntax: 1712 PolRequest ::= SEQUENCE { 1713 scvpVersion INTEGER } 1715 The scvpVersion item is described in section 3.1. 1717 7 Validation Policies Response 1719 In response to a PolRequest, the SCVP server provides a PolResponse. 1720 The polResponce is not unique to any PolRequest, so may be reused 1721 by the server in response to multiple PolRequests. The PolResponce 1722 also has an indecation of how frequently the PolResponce may be 1723 reissued. When a PolResponse is encapsulated in a MIME body part, 1724 it MUST be carried in an application/cv-policies-response MIME body 1725 part. 1727 The response consists of a PolResponse encapsulated in a 1728 ContentInfo. The response MUST be signed by the server using its 1729 digital signature certificate. 1731 ContentInfo { 1732 contentType id-ct-scvp-PolResponse, 1733 -- (1.2.840.113549.1.9.16.1.13) 1734 content PolResponse } 1736 The PolResponse type has the following syntax: 1738 PoliciesResponse ::= SEQUENCE { 1739 scvpVersion INTEGER, 1740 DefaultPolicyID INTEGER, 1741 thisUpdate GeneralizedTime, 1742 nextUpdate GeneralizedTime, 1743 trustAnchors TrustAnchors, 1744 valAlgorithms SEQUENCE OF OBJECT IDENTIFIER, 1745 authPolicies SEQUENCE OF OBJECT IDENTIFIER, 1746 clockSkew INTEGER OPTIONAL, 1747 authDataCert Certificate OPTIONAL } 1749 7.1 scvpVersion 1751 The scvpVersion item is described in section 3.1. 1753 7.2 PolicyID 1755 An integer which uniquely represents the version of the default 1756 validation policy as represented by the trustAnchors, valAlgorithms, 1757 authPolicies, clock skew and authDataCerts. If any of these values 1758 change, the server MUST create a new PolResponce with a new 1759 PolicyID. If the policy and therefore the policyID has not changed, 1760 then the server may reused PolicyID across multiple PolResponce 1761 messages. However if the server having changed the policy, then 1762 reverts to an earlier policy, the server MUST NOT revert the policy 1763 ID as well, but select another unique value. 1765 7.3 thisUpdate 1767 This field indicates the signing date & time of this policy 1768 response. Since the polResponse is not bound to a specific request. 1769 A SCVP server may periodically generate the response and use the 1770 same polResponce for multiple requests. 1772 GeneralizedTime values MUST be expressed Greenwich Mean Time (Zulu) 1773 and interpreted as defined in section 3.2.11. 1775 7.4 nextUpdate 1777 This field indicates the expected publication date & time of the 1778 next policy response. 1780 GeneralizedTime values MUST be expressed Greenwich Mean Time (Zulu) 1781 and interpreted as defined in section 3.2.11. 1783 7.5 trustAnchors 1785 The trustAnchors item specifies the trust anchors that the SCVP 1786 server will use if the client omits the trustAnchours from the 1787 request. 1789 7.6 valAlgorithms 1791 The valAlgorithms item contains a sequence of object identifiers 1792 (OIDs). Each OID identifies a single validation algorithm 1793 supported by the server. 1795 7.7 clockSkew 1797 The number of minures the server will allow for clock skew. If 1798 absent the server MUST use the default valie of 10 minutes. 1800 8 SCVP Server Relay 1802 In some network environments, especially ones that include 1803 firewalls, an SCVP server might not be able to obtain all of the 1804 information that it needs to process a request. However, the 1805 server might be configured to use the services of one or more other 1806 SCVP servers to fulfill all requests. In such cases, the SCVP 1807 client is unaware that the initial SCVP server is using the 1808 services of other SCVP servers. The initial SCVP server acts as a 1809 client to another SCVP server. Unlike the original client, the 1810 SCVP server is expected to have moderate computing and memory 1811 resources. This section describes SCVP server-to-SCVP server 1812 exchanges. This section does not impose any requirements on SCVP 1813 clients that are not also SCVP servers. Further, this section does 1814 not impose any requirements on SCVP servers that do not relay 1815 requests to other SCVP servers. 1817 When one SCVP server relays a request to another server, in an 1818 incorrectly configured system of servers, it is possible that the 1819 same request will be relayed back again. Any SCVP server that 1820 relays requests MUST implement the conventions described in this 1821 section to detect and break loops. 1823 When an SCVP server relays a request, the request MUST include the 1824 requestor item. If the request to be relayed already contains a 1825 requestor item, then server-generated request MUST contain a 1826 requestor item constructed from this value followed by a zero octet 1827 followed by the identifier of the SCVP server. If the request to 1828 be relayed does not contain a requestor item, then server-generated 1829 request MUST contain only identifier of the SCVP server. 1831 When an SVCP server receives a request that contains a requestor 1832 item, the server MUST check for its own identifier. The identifier 1833 could be located at the beginning of the octet string followed by a 1834 zero octet, or it could be located between two zero octets. If the 1835 server discovers its own identifier in the requestor item, it MUST 1836 respond with an error, setting the responseStatus to 40. 1838 9 SCVP ASN.1 Module 1840 This section defines the syntax for SCVP request-response pairs. 1841 The semantics for the messages are defined in sections 3, 4, 5, and 1842 6. The SCVP ASN.1 module follows. 1844 SCVP 1846 { iso(1) identified-organization(3) dod(6) internet(1) 1847 security(5) mechanisms(5) pkix(7) id-mod(0) 21 } 1849 DEFINITIONS IMPLICIT TAGS ::= BEGIN 1851 IMPORTS 1853 AlgorithmIdentifier, Certificate, Extensions, GeneralNames, 1854 SubjectPublicKeyInfo, UTF8String, CertificateList 1855 FROM PKIX1Explicit88 -- RFC 3280 1856 { iso(1) identified-organization(3) dod(6) internet(1) 1857 security(5) mechanisms(5) pkix(7) id-mod(0) 18 } 1859 AttributeCertificate 1860 FROM PKIXAttributeCertificate -- RFC 3281 1861 { iso(1) identified-organization(3) dod(6) internet(1) 1862 security(5) mechanisms(5) pkix(7) id-mod(0) 12 } 1864 ESSCertID FROM ExtendedSecurityServices -- RFC 2634 1865 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1866 pkcs-9(9) smime(16) modules(0) 2 } ; 1868 -- SCVP Certificate Validation Request 1870 id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1871 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1872 id-smime(16) 1 } 1874 id-ct-scvp-certValRequest OBJECT IDENTIFIER ::= { id-ct 10 } 1876 CVRequest ::= SEQUENCE { 1877 scvpVersion INTEGER, 1878 query Query, 1879 requestor [0] OCTET STRING OPTIONAL, 1880 requestNonce [1] OCTET STRING OPTIONAL, 1881 reqExtensions [2] Extensions OPTIONAL } 1883 Query ::= SEQUENCE { 1884 queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, 1885 checks CertChecks, 1886 wantBack WantBack, 1887 requestRefHash BOOLEAN DEFAULT TRUE, 1888 includePolResponce BOOLEAN DEFAULT FALSE, 1889 inhibitPolMap BOOLEAN DEFAULT FALSE, 1890 requireExplicitPol BOOLEAN DEFAULT FALSE, 1891 ignoreAnyPol BOOLEAN DEFAULT FALSE, 1892 valAlgorithm ValidationAlgorithm, 1893 serverContextInfo [0] OCTET STRING OPTIONAL, 1894 validityTime [1] GeneralizedTime OPTIONAL, 1895 trustAnchors [2] TrustAnchors OPTIONAL, 1896 intermediateCerts [3] CertBundle OPTIONAL, 1897 revInfos [4] RevocationInfos OPTIONAL, 1898 queryExtensions [5] Extensions OPTIONAL} 1900 CertReference::= CHOICE { 1901 pkc PKCReference, 1902 ac ACReference } 1904 PKCReference ::= CHOICE { 1905 cert [1] Certificate, 1906 pkcRef [2] ESSCertID } 1908 ACReference ::= CHOICE { 1909 attrCert [3] AttributeCertificate, 1910 acRef [4] ESSCertID } 1912 CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 1914 WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 1916 ValidationAlg ::= SEQUENCE { 1917 valAlgId OBJECT IDENTIFIER, 1918 parameters ANY DEFINED BY valAlgId OPTIONAL } 1920 NameValidationAlg ::= SEQUENCE { 1921 KeyPurposeId OBJECT IDENTIFIER, 1922 ValidationName GeneralNames } 1924 TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF TrustAnchor 1926 TrustAnchor ::= SEQUENCE { 1927 anchor PKCReference, 1928 certPolicies [1] SEQUENCE SIZE (1..MAX) OF 1929 OBJECT IDENTIFIER OPTIONAL } 1930 -- if absent, use any-policy 1932 CertBundle ::= SEQUENCE SIZE (1..MAX) OF PKCReference 1934 RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo 1936 RevocationInfo ::= CHOICE { 1937 crl [0] CertificateList, 1938 delta-crl [1] CertificateList, 1939 ocsp [2] OCSPResponse, 1940 other [3] OtherRevInfo } 1942 OtherRevInfo ::= SEQUENCE { 1943 retype OBJECT IDENTIFIER, 1944 revalue ANY DEFINED BY retype } 1946 -- SCVP Certificate Validation Request 1948 id-ct-scvp-certValResponse OBJECT IDENTIFIER ::= { id-ct 11 } 1950 CVResponse ::= SEQUENCE { 1951 scvpVersion INTEGER, 1952 policyID INTEGER, 1953 producedAt GeneralizedTime, 1954 responseStatus ResponseStatus, 1955 requestRef RequestReference, 1956 requestor [1] OCTET STRING OPTIONAL, 1957 responder [2] OCTET STRING OPTIONAL, 1958 replyObjects [3] ReplyObjects OPTIONAL, 1959 requestNonce [4] OCTET STRING OPTIONAL, 1960 serverContextInfo [5] OCTET STRING OPTIONAL, 1961 polResponse [6] OCTET STRING OPTIONAL, 1962 respExtensions [7] Extensions OPTIONAL } 1964 ResponseStatus ::= SEQUENCE { 1965 statusCode SCVPStatusCode, 1966 errorMessage [0] UTF8String OPTIONAL } 1968 SCVPStatusCode ::= ENUMERATED { 1969 okay (0), 1970 skipUnrecognizedItems (1), 1971 tooBusy (10), 1972 internalError (12), 1973 badStructure (20), 1974 unsupportedVersion (21), 1975 abortUnrecognizedItems (22), 1976 unrecognizedSigKey (23), 1977 badSignature (24), 1978 unableToDecode (25), 1979 notAuthorized (26), 1980 unsupportedChecks (27), 1981 unsupportedWantBacks (28), 1982 unsupportedSignature (29), 1983 invalidSignature (30), 1984 relayingLoop (40), 1985 unrecognisedValidationAlg (50), 1986 FullRequestRefUnsuported (51}, 1987 FullPolRequestUnsuported (52), 1988 InhibitPolMapUnsuported (53), 1989 RequireExpPolUnsuported (54), 1990 IgnoreAnyPolUnsuported (55), 1991 validityTimeUnsuported (56) } 1993 RequestReference ::= CHOICE { 1994 requestHash [1] HashValue, -- hash of CVRequest 1995 fullRequest [2] CVRequest } 1997 HashValue ::= SEQUENCE { 1998 algorithm AlgorithmIdentifier DEFAULT { sha-1 }, 1999 value OCTET STRING } 2001 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 2002 oiw(14) secsig(3) algorithm(2) 26 } 2004 ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply 2006 CertReply ::= SEQUENCE { 2007 cert ReplyCertificate, 2008 replyStatus ReplyStatus, 2009 replyValTime GeneralizedTime, 2010 replyChecks ReplyChecks, 2011 replyWantBacks ReplyWantBacks, 2012 valAlg ValidationAlg, 2013 nextUpdate [1] GeneralizedTime OPTIONAL, 2014 certReplyExtensions [2] Extensions OPTIONAL } 2016 ReplyCertificate ::= CHOICE { 2017 pkc [1] Certificate, 2018 ac [2] AttributeCertificate } 2019 ReplyStatus ::= ENUMERATED { 2020 success (0), 2021 unrecognizedCheck (1), 2022 unrecognizedWantBack (2), 2023 malformedPKC (3), 2024 malformedAC (4), 2025 unrecognizedCertPolicy (5), 2026 unrecognizedValPolicy (6), 2027 unrecognizedExtension (7), 2028 unavailableValidityTime (8), 2029 referenceCertHashFail (9), 2030 certPathConstructFail (10), 2031 certPathNotValid (11), 2032 certPathNotValidNow (12) } 2034 ReplyChecks ::= SEQUENCE OF ReplyCheck 2036 ReplyCheck ::= SEQUENCE { 2037 check OBJECT IDENTIFIER, 2038 status INTEGER } 2040 ReplyWantBacks ::= SEQUENCE OF ReplyWantBack 2042 ReplyWantBack::= SEQUENCE { 2043 wb OBJECT IDENTIFIER, 2044 value OCTET STRING } 2046 -- SCVP Validation Policies Request 2048 id-ct-scvp-valPolRequest OBJECT IDENTIFIER ::= { id-ct 12 } 2050 VPRequest ::= SEQUENCE { 2051 scvpVersion INTEGER } 2053 -- SCVP Validation Policies Response 2055 id-ct-scvp-valPolResponse OBJECT IDENTIFIER ::= { id-ct 13 } 2057 ValPoliciesResponse ::= SEQUENCE { 2058 scvpVersion INTEGER, 2059 DefaultPolicyID INTEGER, 2060 thisUpdate GeneralizedTime, 2061 nextUpdate GeneralizedTime, 2062 trustAnchors TrustAnchors, 2063 valAlgorithms SEQUENCE OF OBJECT IDENTIFIER, 2064 authPolicies SEQUENCE OF OBJECT IDENTIFIER, 2065 clockSkew INTEGER OPTIONAL, 2066 authDataCert Certificate OPTIONAL } 2068 -- SCVP Check Identifiers 2070 id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 2071 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 2072 17 } 2074 id-stc-build-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 } 2075 id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 2 } 2076 id-stc-build-status-checked-pkc-path 2077 OBJECT IDENTIFIER ::= { id-stc 3 } 2078 id-stc-build-aa-path OBJECT IDENTIFIER ::= { id-stc 4 } 2079 id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 5 } 2080 id-stc-build-status-checked-aa-path 2081 OBJECT IDENTIFIER ::= { id-stc 6 } 2082 id-stc-status-check-ac-and-build-status-checked-aa-path 2083 OBJECT IDENTIFIER ::= { id-stc 7 } 2085 -- SCVP WantBack Identifiers 2087 id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 2088 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 2089 18 } 2091 id-swb-pkc-cert-path OBJECT IDENTIFIER ::= { id-swb 1 } 2092 id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 } 2093 id-swb-pkc-cert-status OBJECT IDENTIFIER ::= { id-swb 3 } 2094 id-swb-pkc-public-key-info OBJECT IDENTIFIER ::= { id-swb 4 } 2095 id-swb-aa-cert-path OBJECT IDENTIFIER ::= { id-swb 5 } 2096 id-swb-aa-revocation-info OBJECT IDENTIFIER ::= { id-swb 6 } 2097 id-swb-ac-revocation-info OBJECT IDENTIFIER ::= { id-swb 7 } 2098 id-swb-ac-cert-status OBJECT IDENTIFIER ::= { id-swb 8 } 2100 -- SCVP Validation Policy Identifiers 2102 id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 2103 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 2104 19 } 2106 id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 } 2108 END 2110 10 Security Considerations 2112 A client that trusts a server's response for validation of a 2113 certificate inherently trusts that server as much as it would trust 2114 its own validation software. This means that if an attacker 2115 compromises a trusted SCVP server, the attacker can change the 2116 validation processing for every client that relies on that server. 2117 Thus, an SCVP server must be protected at least as well as the 2118 trust anchors that the SCVP server trusts. 2120 Clients MUST check the requestRef item in the response and ensure 2121 that it matches their original request. Requests contain a lot of 2122 information that affects the response and clients need to ensure 2123 that the server response corresponds to the expected request. 2125 When the SCVP response is used to determine the validity of a 2126 certificate, the client MUST validate the signature on the response 2127 to ensure that the expected SCVP server generated it. If the 2128 client does not check the signature on the response, a man-in-the- 2129 middle attack could fool the client into believing modified 2130 responses from the server, or responses to questions the client did 2131 not ask. 2133 If the client does not include a requestNonce item, or if the 2134 client does not check that the requestNonce in the response matches 2135 the value in the request, an attacker can replay previous responses 2136 from the SCVP server. 2138 If the server does not require some sort of authorization (such as 2139 signed requests), an attacker can get the server to respond to 2140 arbitrary requests. Such responses may give the attacker 2141 information about weaknesses in the server or about the timeliness 2142 of the server's checking. This information may be valuable for a 2143 future attack. 2145 If the server uses the serverContextInformation to indicate some 2146 server state associated with a requestor, implementers must take 2147 appropriate measures against denial of service attacks where an 2148 attacker sends in a lot of requests at one time to force the server 2149 to keep a lot of state information. 2151 The request and response for which policies are supported on the 2152 server are unsigned. These could lead to a denial of service 2153 attack where a man-in-the-middle indicates that a server supports a 2154 different set of validation policies than it actually does. This 2155 could result in the client requesting validation based on a policy 2156 the server does not support or lead the client using a less 2157 desirable policy. 2159 SCVP does not include any confidentiality mechanisms. If 2160 confidentiality is needed, it can be achieved with a lower-layer 2161 security protocol. 2163 11 References 2165 Normative and informative references are provided. 2167 11.1 Normative References 2169 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 2170 Requirement Levels", BCP 14, RFC 2119, March 1997. 2172 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2173 2630,June 1999. 2175 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S. and 2176 C. Adams, "X.509 Internet Public Key Infrastructure - 2177 Online Certificate Status Protocol - OCSP", RFC 2560, 2178 June 1999. 2180 [PKIX-1] Housley, R., Polk, T, Ford, W. and Solo, D., 2181 "Internet X.509 Public Key Infrastructure Certificate 2182 and Certificate Revocation List (CRL) Profile", RFC 2183 3280, April 2002. 2185 [PKIX-AC] Farrell, S., and R. Housley, "An Internet Attribute 2186 Certificate Profile for Authorization", RFC 3281, 2187 April 2002. 2189 [PKIX-ALG] Polk, W., Housley, R. and L. Bassham, "Algorithms 2190 and Identifiers for the Internet X.509 Public Key 2191 Infrastructure Certificate and Certificate Revocation 2192 List (CRL) Profile", RFC 3279, April 2002. 2194 [SHA-1] National Institute of Standards and Technology, 2195 "Secure Hash Standard", NIST FIPS Pub 180-1, April 2196 1995. 2198 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 2199 10646", RFC 2279, January 1998. 2201 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", 2202 RFC 2634, June 1999. 2204 [HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC2818, May 2000. 2206 11.2 Informative References 2208 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and 2209 T. 2210 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 2211 RFC 2068, January 1997. 2213 [OpenPGP] Callas, J., Donnerhacke, L., Finney, H., and R. 2214 Thayer, "OpenPGP Message Format", RFC 2440, November 2215 1998. 2217 [RQMTS] Pinkas, D., and R. Housley, "Delegated Path 2218 Validation and Delegated Path Discovery Protocol 2219 Requirements", RFC 3379, September 2002. 2221 12 Acknowledgments 2223 The lively debate in the PKIX Working Group has made a significant 2224 impact on this protocol. Denis Pinkas and Phillip Hallam-Baker 2225 suggested additional requirements for the protocol. Mike Myers 2226 identified areas that needed clarification. Frank Balluffi and 2227 Ameya Talwalkar did an implementation based on an early draft of 2228 this protocol, and they identified a few deficiencies. John 2229 Thielens, Peter Sylvester, and Yuriy Dzambasow provided good input, 2230 greatly improving this document. 2232 Appendix A -- MIME Registrations 2234 Four MIME type registrations are provided in this appendix. 2236 A.1 application/cv-request 2238 To: ietf-types@iana.org 2239 Subject: Registration of MIME media type application/cv-request 2241 MIME media type name: application 2243 MIME subtype name: cv-request 2245 Required parameters: format 2247 Optional parameters: None 2249 Encoding considerations: binary 2251 Security considerations: Carries a request for information. This 2252 request may optionally be cryptographically signed. 2254 Interoperability considerations: None 2256 Published specification: IETF PKIX Working Group Draft on Simple 2257 Certificate Validation Protocol (SCVP) 2259 Applications which use this media type: SCVP clients 2261 Additional information: 2262 Magic number(s): None 2263 File extension(s): .SCQ 2264 Macintosh File Type Code(s): none 2266 Person & email address to contact for further information: 2267 Ambarish Malpani 2269 Intended usage: COMMON 2271 Author/Change controller: 2272 Ambarish Malpani 2274 A.2 application/cv-response 2276 To: ietf-types@iana.org 2277 Subject: Registration of MIME media type application/cv-response 2278 MIME media type name: application 2280 MIME subtype name: cv-response 2282 Required parameters: format 2284 Optional parameters: None 2286 Encoding considerations: binary 2288 Security considerations: Unless reporting an error, the response is 2289 cryptographically signed 2291 Interoperability considerations: None 2293 Published specification: IETF PKIX Working Group Draft on Simple 2294 Certificate Validation Protocol (SCVP) 2296 Applications which use this media type: SCVP servers 2298 Additional information: 2300 Magic number(s): None 2301 File extension(s): .SCS 2302 Macintosh File Type Code(s): none 2304 Person & email address to contact for further information: 2305 Ambarish Malpani 2307 Intended usage: COMMON 2309 Author/Change controller: Ambarish Malpani 2311 A.3 application/cv-policies-request 2313 To: ietf-types@iana.org 2314 Subject: Registration of MIME media type application/cv-policies- 2315 request 2317 MIME media type name: application 2319 MIME subtype name: cv-policies-request 2321 Required parameters: format 2323 Optional parameters: None 2325 Encoding considerations: binary 2327 Security considerations: Carries a request for information. 2329 Interoperability considerations: None 2331 Published specification: IETF PKIX Working Group Draft on Simple 2332 Certificate Validation Protocol (SCVP) 2334 Applications which use this media type: SCVP clients 2336 Additional information: 2338 Magic number(s): None 2339 File extension(s): .SPQ 2340 Macintosh File Type Code(s): none 2342 Person & email address to contact for further information: 2343 Ambarish Malpani 2345 Intended usage: COMMON 2347 Author/Change controller: Ambarish Malpani 2349 A.4 application/cv-policies-response 2351 To: ietf-types@iana.org 2352 Subject: Registration of MIME media type application/cv-policies- 2353 response 2355 MIME media type name: application 2357 MIME subtype name: cv-policies-response 2359 Required parameters: format 2361 Optional parameters: None 2363 Encoding considerations: Binary 2365 Security considerations: None 2367 Interoperability considerations: None 2369 Published specification: IETF PKIX Working Group Draft on Simple 2370 Certificate Validation Protocol (SCVP) 2372 Applications which use this media type: SCVP servers 2374 Additional information: 2375 Magic number(s): None 2376 File extension(s): .SPP 2377 Macintosh File Type Code(s): none 2379 Person & email address to contact for further information: 2380 Ambarish Malpani 2381 Intended usage: COMMON 2383 Author/Change controller: 2384 Ambarish Malpani 2386 Appendix B -- SCVP over HTTP 2388 This appendix describes the formatting conventions for the SCVP 2389 request and response when carried by HTTP. 2391 B.1 SCVP Request 2393 HTTP based SCVP requests can use the POST method to submit their 2394 requests. Where privacy is a requirement, SCVP transactions 2395 exchanged using HTTP MAY be protected using either TLS/SSL or some 2396 other lower layer protocol. 2398 An SCVP request using the POST method is constructed as follows: 2400 The Content-Type header MUST have the value "application/scvp- 2401 request". 2403 The Content-Length header MUST be present and have the exact 2404 length of the request. 2406 The body of the message is the binary value of the DER encoding 2407 of the CVRequest. Other HTTP headers MAY be present and MAY be 2408 ignored if not understood by the requestor. 2410 Sample Content-Type headers are: 2411 Content-Type: application/scvp-request 2413 B.2 SCVP Response 2415 An HTTP-based SCVP response is composed of the appropriate HTTP 2416 headers, followed by the binary value of the DER encoding of the 2417 CVResponse. 2419 The Content-Type header MUST have the value "application/scvp- 2420 response". 2422 The Content-Length header MUST be present and specify the length of 2423 the response. 2425 Other HTTP headers MAY be present and MAY be ignored if not 2426 understood by the requestor. 2428 Appendix C -- Author Contact Information 2430 Ambarish Malpani 2431 Malpani Consulting Services 2432 ambarish@malpani.biz 2434 Russell Housley 2435 Vigil Security, LLC 2436 918 Spring Knoll Drive 2437 Herndon, VA 20170 2438 USA 2439 housley@Vigilsec.com 2441 Trevor Freeman 2442 Microsoft Corporation, 2443 One Microsoft way. 2444 Redmond, WA 98052 2445 USA. 2446 trevorf@microsoft.com 2448 Full Copyright Statement 2450 Copyright (C) The Internet Society (2002). All Rights Reserved. 2452 This document and translations of it may be copied and furnished to 2453 others, and derivative works that comment on or otherwise explain 2454 it or assist in its implementation may be prepared, copied, 2455 published and distributed, in whole or in part, without restriction 2456 of any kind, provided that the above copyright notice and this 2457 paragraph are included on all such copies and derivative works. 2458 In addition, the ASN.1 modules presented in Appendices A and B may 2459 be used in whole or in part without inclusion of the copyright 2460 notice. However, this document itself may not be modified in any 2461 way, such as by removing the copyright notice or references to the 2462 Internet Society or other Internet organizations, except as needed 2463 for the purpose of developing Internet standards in which case the 2464 procedures for copyrights defined in the Internet Standards process 2465 shall be followed, or as required to translate it into languages 2466 other than English. 2468 The limited permissions granted above are perpetual and will not be 2469 revoked by the Internet Society or its successors or assigns. This 2470 document and the information contained herein is provided on an "AS 2471 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2472 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2473 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2474 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2475 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.