idnits 2.17.1 draft-ietf-pkix-scvp-12.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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 2502 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 1682 -- Looks like a reference, but probably isn't: '1' on line 1727 -- Looks like a reference, but probably isn't: '2' on line 1728 -- Looks like a reference, but probably isn't: '3' on line 1675 -- Looks like a reference, but probably isn't: '4' on line 1676 -- Looks like a reference, but probably isn't: '5' on line 1677 -- Looks like a reference, but probably isn't: '6' on line 1678 == Unused Reference: 'SHA-1' is defined on line 1901, but no explicit reference was found in the text == Unused Reference: 'OpenPGP' is defined on line 1914, 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. 'PKIX-ALG' -- 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 2440 (ref. 'OpenPGP') (Obsoleted by RFC 4880) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft A. Malpani 3 draft-ietf-pkix-scvp-12.txt Malpani Consulting Services 4 June 2003 R. Housley 5 Expires in six months Vigil Security 6 T. Freeman 7 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 documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2002). All Rights Reserved. 35 Abstract 37 SCVP allows a client to offload certificate handling to a server. 38 The server can provide the client with a variety of valuable 39 information about the certificate, such as whether the certificate 40 is valid, a certification path to a trust anchor, and revocation 41 status. SCVP has many purposes, including simplifying client 42 implementations and allowing companies to centralize trust and 43 policy management. 45 Table of Contents 46 1 Introduction......................................................4 47 1.1 SCVP overview and requirements................................4 48 1.2 Terminology...................................................5 49 1.3 Validation Policies...........................................5 50 2 Protocol Overview.................................................6 51 3 Validation Request................................................6 52 3.1 scvpVersion...................................................8 53 3.2 Query.........................................................8 54 3.2.1 queriedCerts..............................................9 55 3.2.2 checks....................................................9 56 3.2.3 wantBack.................................................11 57 3.2.4 serverContextInfo........................................12 58 3.2.5 valPolicy................................................12 59 3.2.6 validityTime.............................................14 60 3.2.7 trustAnchors.............................................15 61 3.2.8 intermediateCerts........................................16 62 3.2.9 revInfos.................................................16 63 3.2.10 queryExtensions.........................................17 64 3.3 Requestor....................................................17 65 3.4 requestNonce.................................................17 66 3.5 reqExtensions................................................18 67 4 Validation Response..............................................18 68 4.1 scvpVersion..................................................20 69 4.2 producedAt...................................................21 70 4.3 responseStatus...............................................21 71 4.4 requestReference.............................................22 72 4.4.1 requestHash..............................................22 73 4.4.2 fullRequest..............................................23 74 4.5 Requestor....................................................23 75 4.6 responder....................................................23 76 4.7 replyObjects.................................................24 77 4.7.1 cert.....................................................24 78 4.7.2 replyStatus..............................................25 79 4.7.3 replyValTime.............................................26 80 4.7.4 replyChecks..............................................26 81 4.7.5 replyWantBack............................................27 82 4.7.6 valPolicy................................................28 83 4.7.7 nextUpdate...............................................29 84 4.7.8 certReplyExtensions......................................29 85 4.8 requestNonce.................................................29 86 4.9 serverContextInfo............................................29 87 4.10 respExtensions..............................................30 88 5 Validation Policies Request......................................30 89 6 Validation Policies Response.....................................31 90 7 SCVP Server Relay................................................31 91 8 SCVP ASN.1 Module................................................32 92 9 Security Considerations..........................................37 93 10 References......................................................38 94 10.1 Normative References........................................38 96 Malpani, Housley, & Freeman [Page2] 97 10.2 Informative References......................................39 98 11 Acknowledgments.................................................39 99 Appendix A -- MIME Registrations...................................39 100 A.1 application/scvp-request.....................................39 101 A.2 application/scvp-response....................................40 102 A.3 application/scvp-policies-request............................41 103 A.4 application/scvp-policies-response...........................42 104 Appendix B -- SCVP over HTTP.......................................42 105 B.1 SCVP Request.................................................42 106 Appendix C -- Author Contact Information...........................43 108 Malpani, Housley, & Freeman [Page3] 109 1 Introduction 111 Certificate validation is complex. If certificate handling is to be 112 widely deployed in a variety of applications and environments, the 113 amount of processing an application needs to perform before it can 114 accept a certificate needs to be reduced. There are a variety of 115 applications that can make use of public key certificates, but these 116 applications are burdened with the overhead of constructing and 117 validating the certification paths. SCVP reduces this overhead for 118 two classes of certificate-using applications. 120 The first class of application wants just two things. First, they 121 want confirmation that the public key belongs to the identity named 122 in the certificate. Second, they want to know if the public key can 123 be used for the intended purpose. The client delegates certificate 124 validation to the SCVP server. 126 The second class of application can perform certification path 127 validation, but these applications have no reliable method of 128 constructing a certification path to a trust anchor. The client 129 delegates certification path construction to the SCVP server. 131 1.1 SCVP overview and requirements 133 The SCVP meets the requirements documented in [RQMTS]. 135 The primary goals of SCVP are to make it easier to deploy PKI- 136 enabled applications and to allow central administration of PKI 137 policies within an organization. SCVP can be used by clients that 138 do much of the certificate processing themselves but simply want an 139 untrusted server to collect information for them. However, when the 140 client has complete trust in the SCVP server, SCVP can be used to 141 delegate the work of certification path construction and validation, 142 and SCVP can be used to ensure that policies are consistently 143 enforced throughout an organization. 145 Untrusted SCVP servers can provide clients the certification paths. 146 They can also provide clients revocation information, such as CRLs 147 and OCSP responses, and the client needs to validate the 148 certification path constructed by the SCVP server. These services 149 can be valuable to clients that do not include the protocols needed 150 to find and download intermediate certificates, CRLs, and OCSP 151 responses. 153 Trusted SCVP servers can perform certification path construction and 154 validation for the client. For a client uses these services, the 155 client inherently trusts the SCVP server as much as it would its own 156 path validation software (if it contained such software). There are 158 Malpani, Housley, & Freeman [Page4] 159 two main reasons that a client may want to trust such an SCVP 160 server: 162 - The client does not want to incur the overhead of including 163 certification path validation software and running it for each 164 certificate it receives. 165 - The client is in an organization or community that wants to 166 centralize its PKI policies. These policies might dictate which 167 trust anchors are used and the types of policy checking that are 168 performed during certification path validation. 170 1.2 Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in [STDWORDS]. 176 1.3 Validation Policies 178 A validation policy can be used to specify the SCVP configuration. 179 The validation policy is determined by private agreement between the 180 client and the server, but it MUST be represented as an OBJECT 181 IDENTIFIER. The SCVP server can assign identifiers that indicate 182 that some settings are used in addition to values provided in the 183 SCVP request. These values might include certificate policies and 184 trust anchors. 186 In a separate, yet to be written, document application-specific 187 validation policies will be defined. These validation policies 188 should serve as guides for the development of further application- 189 specific validation policies. S/MIME, IPsec, and TLS likely 190 candidate applications for this document. 192 For a certification path to meet the validation policy, it MUST be a 193 valid certification path as defined in [PKIX-1] and all validation 194 policy constraints that apply to the certification path MUST be 195 verified. 197 Revocation checking is one aspect of certification path validation 198 defined in [PKIX-1]. Therefore, the validation policy MUST specify 199 the source of revocation information. Five alternatives are 200 envisioned: 202 1. full CRLs (or full Authority Revocation Lists) have to be 203 collected; 205 2. OCSP responses, using [OCSP], have to be collected; 207 3. delta CRLs and the relevant associated full CRLs (or full 208 Authority Revocation Lists) are to be collected; 210 Malpani, Housley, & Freeman [Page5] 211 4. any available revocation information has to be collected; 212 and 214 5. no revocation information need be collected. 216 2 Protocol Overview 217 The SCVP uses a simple request-response model. That is, the SCVP 218 client creates a request and sends it to the SCVP server, and then 219 the SCVP server creates a single response and sends it to the client. 220 The typical use of SCVP is expected to be over HTTP, but it can also 221 be used with email. Appendix A and Appendix B provide the details 222 necessary to use SCVP with HTTP. 224 SCVP includes two request-response pairs. The primary request- 225 response pair handles certificate validation. The secondary 226 request- response pair is used to determine the list of validation 227 policies supported by a specific SCVP server. 229 Section 3 defines the certificate validation request, and section 4 230 defines the corresponding response. 232 Section 5 defines the validation policies request, and section 6 233 defines the corresponding response. 235 Appendix A registers MIME types for SCVP requests and responses, and 236 Appendix B describes the use of these MIME types with HTTP. 238 3 Validation Request 240 A SCVP client request to the server MUST be a single SCVPRequest 241 item. When a SCVPRequest is encapsulated in a MIME body part, 242 application/scvp-request MUST be used. 244 There are two forms of SCVP request: unsigned and signed. A signed 245 request can be used to authenticate the client to the server. A 246 server MAY require all requests to be signed, and a server MAY 247 discard all unsigned requests. Alternatively, a server MAY choose 248 to process unsigned requests. 250 The unsigned request consists of a certValRequest encapsulated in a 251 ContentInfo. An overview of this structure is provided below. 252 Many details are not shown, but the way that SCVP makes use of CMS 253 is clearly illustrated. 255 ContentInfo { 256 contentType id-ct-scvp-certValRequest, 257 -- (1.2.840.113549.1.9.16.1.10) 258 content CVRequest } 260 Malpani, Housley, & Freeman [Page6] 261 The signed request consists of a certValRequest encapsulated in 262 either a SignedData or AuthenticatedData which is in turn 263 encapsulated in a ContentInfo. An overview of this structure is 264 provided below. Again, many details are not shown, but the way that 265 SCVP makes use of CMS is clearly illustrated. 267 SignedData example: 269 ContentInfo { 270 contentType id-signedData, -- (1.2.840.113549.1.7.2) 271 content SignedData } 273 SignedData { 274 version CMSVersion, 275 digestAlgorithms DigestAlgorithmIdentifiers, 276 encapContentInfo EncapsulatedContentInfo, 277 certificates CertificateSet, -- (Optional) 278 crls CertificateRevocationLists, -- (Optional) 279 signerInfos SET OF SignerInfos } -- (only one in SCVP) 281 SignerInfo { 282 version CMSVersion, 283 sid SignerIdentifier, 284 digestAlgorithm DigestAlgorithmIdentifier, 285 signedAttrs SignedAttributes, -- (Required) 286 signatureAlgorithm SignatureAlgorithmIdentifier, 287 signature SignatureValue, 288 unsignedAttrs UnsignedAttributes } -- (not used in SCVP) 290 AuthenticatedData example: 292 ContentInfo { 293 contentType id-ct-authData, -- (1.2.840.113549.1.9.16.1.2) 294 content AuthenticatedData } 296 AuthenticatedData ::= SEQUENCE { 297 version CMSVersion, 298 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 299 recipientInfos RecipientInfos, 300 macAlgorithm MessageAuthenticationCodeAlgorithm, 301 digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, 302 encapContentInfo EncapsulatedContentInfo, 303 authAttrs [2] IMPLICIT AuthAttributes OPTIONAL, 304 mac MessageAuthenticationCode, 305 unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL } 306 -- Not used in SCVP 308 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 310 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 312 Malpani, Housley, & Freeman [Page7] 313 MessageAuthenticationCode ::= OCTET STRING 315 EncapsulatedContentInfo { 316 eContentType id-ct-scvp-certValRequest, 317 -- (1.2.840.113549.1.9.16.1.10) 318 eContent OCTET STRING } -- Contains CVRequest 320 The syntaxes for SignedData, AuthenticatedData and ContentInfo are 321 defined in [CMS]. The syntax for CVRequest is defined below. The 322 CVRequest item contains the client request. The CVRequest item 323 contains the scvpVersion and query items; and the CVRequest item MAY 324 also contain the requestor, requestNonce, and reqExtensions items. 326 The CVRequest MUST have the following syntax: 328 CVRequest ::= SEQUENCE { 329 scvpVersion INTEGER, 330 query Query, 331 requestor [0] OCTET STRING OPTIONAL, 332 requestNonce [1] OCTET STRING OPTIONAL, 333 reqExtensions [2] Extensions OPTIONAL } 335 Each of the items within the CVRequest are described in the 336 following sections. 338 3.1 scvpVersion 339 The scvpVersion item tells the version of SCVP used in a request or 340 a response. The value of the scvpVersion item MUST be one (1). 341 Future updates to this specification ought to specify other integer 342 values. 344 3.2 Query 346 The query specifies one or more certificates that are the object of 347 the request; the certificates can be either public key certificates 348 [PKIX-1] or attribute certificates [PKIX-AC]. A query MUST contain 349 a sequence of one or more certificate references, checks, and 350 wantBack items; and a query MAY also contain valPolicy, validityTime, 351 trustAnchors, intermediateCerts, revInfos, and queryExtensions items. 353 Query MUST have the following syntax: 355 Query ::= SEQUENCE { 356 queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, 357 checks CertChecks, 358 wantBack WantBack, 359 serverContextInfo [0] OCTET STRING OPTIONAL, 360 valPolicy [1] ValidationPolicy, 361 validityTime [2] GeneralizedTime OPTIONAL, 363 Malpani, Housley, & Freeman [Page8] 364 trustAnchors [3] TrustAnchors OPTIONAL, 365 intermediateCerts [4] CertBundle OPTIONAL, 366 revInfos [5] RevocationInfos OPTIONAL, 367 queryExtensions [6] Extensions OPTIONAL } 369 The list of certificate references in the Query item tells the 370 server the certificate(s) for which the client wants information. 371 The OPTIONAL serverContextInfo item tells the server that additional 372 information from a previous request-response in desired. The 373 OPTIONAL validityTime item tells the date and time relative to which 374 the client wants the server to perform the checks. The OPTIONAL 375 valPolicy, trustAnchors, intermediateCerts, and revInfos items 376 provide context for the client request. The OPTIONAL 377 queryExtensions item provides for future expansion of the query 378 syntax. 380 3.2.1 queriedCerts 382 The queriedCerts item, using the CertReference type, identifies the 383 certificate that is the object of the request. The certificate is 384 either a public key certificate or an attribute certificate. The 385 certificate is either directly included or it is referenced. When 386 referenced, a SHA-1 hash value of the referenced item is included to 387 ensure that the SCVP client and the SCVP server both obtain the same 388 certificate when the referenced certificate is fetched. Certificate 389 references use the ESSCertID type defined in [ESS]. CertReference 390 has the following syntax: 392 CertReference ::= CHOICE { 393 pkc PKCReference, 394 ac ACReference } 396 PKCReference ::= CHOICE { 397 cert [1] Certificate, 398 pkcRef [2] ESSCertID } 400 ACReference ::= CHOICE { 401 attrCert [3] AttributeCertificate, 402 acRef [4] ESSCertID } 404 The ASN.1 definition of Certificate is imported from [PKIX-1]; the 405 definition of AttributeCertificate is imported from [PKIX-AC]; and 406 the definition of ESSCertID is imported from [ESS]. 408 3.2.2 checks 410 The checks item describes the checking that the SCVP client wants 411 the SCVP server to perform on the certificate(s) in the queriedCerts 412 item. The checks item MUST contain a sequence of object identifiers. 413 Each object identifier tells the SCVP server what checking the 415 Malpani, Housley, & Freeman [Page9] 416 client expects the server to perform. For each check specified in 417 the request, the SCVP server MUST perform all of the requested 418 checks, or return an error. 420 Revocation status checking inherently includes path construction. 421 Also, building a validated certification path does not imply 422 revocation status checks (although a server may still choose to 423 perform revocation status checks). 425 The checks item uses the CertChecks type, which has the following 426 syntax: 428 CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 430 A list of object identifiers (OIDs) indicates the checking that the 431 client wants the SCVP server to perform on the certificate(s) in the 432 queriedCerts item. 434 For public key certificates, OIDs are defined for the following 435 checks: 437 - Build a certification path to a trusted root; 438 - Build a validated certification path to a trusted root; and 439 - Do revocation status checks on the certification path. 441 For attribute certificates, OIDs are defined for the following 442 checks: 444 - Build a certification path to a trusted root for the AC issuer; 445 - Build a validated certification path to a trusted root for the 446 AC issuer; 447 - Do revocation status checks on the certification path for the AC 448 issuer; and 449 - Do revocation status checks on the AC as well as the 450 certification path for the AC issuer. 452 For these purposes, the following OIDs are defined: 454 id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 455 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 } 457 id-stc-build-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 } 458 id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 2 } 459 id-stc-build-status-checked-pkc-path 460 OBJECT IDENTIFIER ::= { id-stc 3 } 461 id-stc-build-aa-path OBJECT IDENTIFIER ::= { id-stc 4 } 462 id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 5 } 463 id-stc-build-status-checked-aa-path 464 OBJECT IDENTIFIER ::= { id-stc 6 } 465 id-stc-status-check-ac-and-build-status-checked-aa-path 467 Malpani, Housley, & Freeman [Page10] 468 OBJECT IDENTIFIER ::= { id-stc 7 } 469 3.2.3 wantBack 471 The wantBack item describes the kind of information the SCVP client 472 wants from the SCVP server for the certificate(s) in the 473 queriedCerts item. The wantBack item MUST contain a sequence of 474 object identifiers. Each object identifier tells the SCVP server 475 what the client wants to know about the queriedCerts item. For each 476 type of information specified in the request, the server MUST return 477 information regarding its finding (in a successful response). 479 For example, a request might include a checks item that only 480 specifies certification path building and include a wantBack item 481 that requests the return of the certification path built by the 482 server. In this case, the response would not include a status for 483 the validation of the certification path, but it would include a 484 certification path that the server considers to be valid. A client 485 that wants to perform its own certification path validation might 486 use a request of this form. 488 Alternatively, a request might include a checks item that requests 489 the server to build a certification path and validate it, including 490 revocation checking, and include a wantBack item that requests the 491 return of the status. In this case, the response would include only 492 a status for the validation of the certification path. A client 493 that completely delegates certification path validation might use a 494 request of this form. 496 The wantBack item uses the WantBack type, which has the following 497 syntax: 499 WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 501 For public key certificates, the types of information that can be 502 requested are: 504 - Certification path built for the certificate; 505 - Proof of revocation status for each certificate in the 506 certification path; 507 - Status indication; and 508 - Public key from the certificate. 510 For attribute certificates, the types of information that can be 511 requested are: 513 - Certification path built for the AC issuer certificate; 514 - Proof of revocation status for each certificate in the AC 515 issuer certification path; 516 - Proof of revocation status for the attribute certificate; and 517 - Status indication. 519 Malpani, Housley, & Freeman [Page11] 520 For these purposes, the following OIDs are defined: 522 id-swb OBJECT IDENTIFIER ::= { id-pkix 18 } -- SCVP want back 524 id-swb-pkc-cert-path OBJECT IDENTIFIER ::= { id-swb 1 } 525 id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 } 526 id-swb-pkc-cert-status OBJECT IDENTIFIER ::= { id-swb 3 } 527 id-swb-pkc-public-key-info OBJECT IDENTIFIER ::= { id-swb 4 } 528 id-swb-aa-cert-path OBJECT IDENTIFIER ::= { id-swb 5 } 529 id-swb-aa-revocation-info OBJECT IDENTIFIER ::= { id-swb 6 } 530 id-swb-ac-revocation-info OBJECT IDENTIFIER ::= { id-swb 7 } 531 id-swb-ac-cert-status OBJECT IDENTIFIER ::= { id-swb 8 } 533 3.2.4 serverContextInfo 535 The serverContextInfo item, if present, contains context from a 536 previous request-response transaction with the same SCVP server. It 537 allows the server to return more than one certification path for the 538 same certificate to the client. For example, if a server constructs 539 a particular certification path for a certificate, but the client 540 finds it unacceptable, the client can then send the same query back 541 to the server with the serverContextInfo from the first response, 542 and the server will be able to provide a different certification 543 path (if another one can be found). 545 Contents of the serverContextInfo are opaque to the SCVP client. 546 That is, the client only knows that it needs to return the value 547 provided by the server with the subsequent request to get a 548 different certification path. Note that the subsequent query needs 549 be essentially identical to the previous query. The client MUST NOT 550 change any items other than: 552 - requestNonce; 553 - serverContextInfo; and 554 - the client's signature on the request 556 3.2.5 valPolicy 558 The valPolicy item, defines the validation policy to be used by the 559 SCVP server during certificate validation. The client can use this 560 instead of specifying other SCVP configuration items such as 561 trustAnchors. The value of this item can be determined by private 562 agreement between the client and the server, but it MUST be 563 represented as an object identifier. The server might want to 564 assign identifiers that indicate that some settings are used in 565 addition to others given in the request. In this way, the 566 validation policy object identifier can be a shorthand for some SCVP 567 options, but not others. 569 Malpani, Housley, & Freeman [Page12] 570 The valPolicy item uses the ValidationPolicy type, which has the 571 following syntax: 573 ValidationPolicy ::= SEQUENCE { 574 valPolicyId OBJECT IDENTIFIER, 575 parameters ANY DEFINED BY valPolicyId OPTIONAL } 577 The client can request the SCVP server's default validation policy 578 is used or another policy. The object identifier to identify the 579 default validation policy is: 581 id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 582 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 } 584 id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 } 586 All SCVP servers MUST support the default policy. 588 The meaning of the default validation policy is: 590 - Trust anchors will come from the trustAnchors item. If no 591 certificates are specified in the trustAnchors item, then the 592 SCVP server will use trust anchors of its own choosing. 594 - The acceptable policy set will come from the certPolicies item 595 associated with the selected trust anchor. If no certificate 596 policies are specified in the certPolicies item, then the SCVP 597 server will use any-policy. 599 - The SCVP server will check for certificate revocation using 600 CRLs, delta CRLs, OCSP responses, or any other source of 601 revocation information that is available. 603 3.2.5.1 Name Validation Policy 605 The name validation policy allows the client to supply a name to the 606 server along with a application identifier. The application 607 identifier defines the name matching rules use to compare the name 608 supplied in the request with the names in the certificate being 609 validated. 611 id-svp-NameValPol OBJECT IDENTIFIER ::= { id-svp 2 } 613 NameValidation ::= SEQUENCE { 614 KeyPurposeId OBJECT IDENTIFIER, 615 ValidationName GeneralName } 617 KeyPurposeId and GeneralName are defined in [PKIX-1]. 619 Malpani, Housley, & Freeman [Page13] 620 If the KeyPurposeID supplied in the request is id-kp-serverAuth 621 [PKIX-1] then GeneralName supplied in the request MUST be a DNS name, 622 and the matching rules to be used are defined in [HTTP-TLS]. 624 If the KeyPurposeID supplied in the request is id-kp-mailProtection 625 [PKIX-1] then GeneralName supplied in the request MUST be a rfc822 626 name, and the matching rule MUST be a case insensitive whole sting 627 comparison. For example user@foo.com matches USER@FOO.COM, but not 628 auser@foo.com or user@afoo.com 630 3.2.5.2 Name Validation Policy Errors 632 The following errors are defined for the Name Validation Policy 634 id-nvpe OBJECT IDENTIFIER ::= { id-svp-NameValPol 1 } 636 id-nvpe-NameMismatch OBJECT IDENTIFIER ::= { id-nvpe 1 } 637 id-nvpe-NoCertName OBJECT IDENTIFIER ::= { id-nvpe 2 } 638 id-nvpe-UnknownPupose OBJECT IDENTIFIER ::= { id-nvpe 3 } 639 id-nvpe-BadName OBJECT IDENTIFIER ::= { id-nvpe 4 } 640 id-nvpe-BadNameType OBJECT IDENTIFIER ::= { id-nvpe 5 } 642 Name mismatch means the client supplied a name with the validation 643 policy, which the server recognized and the server found 644 corresponding name type in the certificate, but was unable to find a 645 match to the name supplied. For example the client supplied a DNS 646 name of foo.com, the certificate contained a DNS name of bar.com. 648 NoCertName means the client supplied a name with the validation 649 policy, which the server recognized, but the server could not find 650 the corresponding name type in the certificate. For example the 651 client supplied a DNS name of foo.com, the certificate only 652 contained a rfc822 name of user@bar.com. 654 UnknownPupose means the client supplied KeyPurposeID which the 655 server does not recognize. 657 BadName means the client supplied either and empty or malformed name 658 in the request. 660 BadNameType means the client supplied an inappropriate name type for 661 the key purpose. For example the client specified a key purpose ID 662 of id-kp-serverAuth, and a rfc822 name of user@foo.com. 664 3.2.6 validityTime 666 The OPTIONAL validityTime item tells the date and time relative to 667 which the SCVP client wants the server to perform the checks. If 668 the validityTime is present, it MUST be encoded as GeneralizedTime. 669 If the validityTime is not present, the server MUST perform the 671 Malpani, Housley, & Freeman [Page14] 672 using the date and time at which the server processes the request. 673 The validityTime provided MUST be retrospective since the server can 674 only perform a validity check using the current time (default) or 675 previous time. 677 GeneralizedTime values MUST be expressed Greenwich Mean Time (Zulu) 678 and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even 679 when the number of seconds is zero. GeneralizedTime values MUST NOT 680 include fractional seconds. 682 The information in the corresponding CertReply item in the response 683 MUST be formatted as if the server created the response at the time 684 indicated in the validityTime. However, if the server does not have 685 appropriate historical information, the server MUST return an error. 687 3.2.7 trustAnchors 689 The OPTIONAL trustAnchors item specifies the trust anchors to be 690 used by the SCVP server. One or more certificate policy MAY be 691 associated with each trust anchor. If a trustAnchors item is 692 present, the server MUST NOT use any certification path trust 693 anchors other than those provided. 695 The TrustAnchors type contains one or more trust anchor 696 specification. A certificate reference can be used to identify the 697 trust anchor distinguished name, public key algorithm, associated 698 public key parameters, if needed, and the trusted public key. 699 Alternatively, these items can be provided directly. The order of 700 trust anchor specifications within the sequence is not important. 701 The OPTIONAL certPolicies item specifies a list of policy 702 identifiers that the SCVP server MUST use when forming and 703 validating a certification path that terminates at the associated 704 trust anchor. If certPolicies is not specified, then any-policy 705 MUST be used. 707 The trust anchor itself, regardless of its form, MUST NOT be 708 included in any certification path constructed by the SCVP server. 710 TrustAnchors has the following syntax: 712 TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF TrustAnchor 714 TrustAnchor ::= SEQUENCE { 715 anchor PKCReference, 716 certPolicies [1] SEQUENCE SIZE (1..MAX) OF 717 OBJECT IDENTIFIER OPTIONAL } 718 -- if absent, use any-policy 720 Malpani, Housley, & Freeman [Page15] 721 3.2.8 intermediateCerts 723 The OPTIONAL intermediateCerts item helps the SCVP server create 724 valid certification paths. The intermediateCerts item, when present, 725 provides certificates that the server MAY use when forming a 726 certification path. The certificates in the intermediateCerts item 727 MAY be used by the server in addition to any other certificates that 728 the server can access when building certification paths. The 729 intermediateCerts item, when present, MUST contain at least one 730 certificate. The intermediateCerts item MUST be structured as a 731 CertBundle. The certificates in the intermediateCerts MUST NOT be 732 trusted by the server just because they are present in this item. 734 The CertBundle type contains one or more certificate references. 735 The order of the entries in the bundle is not important. CertBundle 736 has the following syntax: 738 CertBundle ::= SEQUENCE SIZE (1..MAX) OF PKCReference 740 3.2.9 revInfos 742 The OPTIONAL revInfo item specifies revocation information such as 743 CRLs, delta CRLs [PKIX-1], and OCSP responses [OCSP] that the SCVP 744 server MAY use when validating certification paths. The purpose of 745 the revInfos item is to provide revocation information to which the 746 server might not otherwise have access (for example, an OCSP 747 response that the client received along with the certificate). Note 748 that the information in the revInfos item might not be used by the 749 server. For example, the revocation information might be associated 750 with certificates that the server does not use in certification path 751 building. 753 It is courteous to the SCVP server to separate CRLs and delta CRLs. 754 However, since the two share a common syntax, SCVP servers SHOULD 755 accept delta CRLs even if they are identified as regular CRLs by the 756 SCVP client. 758 CRLs, delta CRLs, and OCSP responses can be provided as revocation 759 information. If needed, additional object identifiers can be 760 assigned for additional revocation information types in the future. 762 The revInfos item uses the RevocationInfos type, which has the 763 following syntax: 765 RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo 767 RevocationInfo ::= CHOICE { 768 crl [0] CertificateList, 769 delta-crl [1] CertificateList, 770 ocsp [2] OCSPResponse, 772 Malpani, Housley, & Freeman [Page16] 773 other [3] OtherRevInfo } 775 OtherRevInfo ::= SEQUENCE { 776 retype OBJECT IDENTIFIER, 777 revalue ANY DEFINED BY retype } 779 3.2.10 queryExtensions 781 The OPTIONAL queryExtensions item contains Extensions. If present, 782 each extension in the sequence extends the query. This 783 specification does not define any extensions, the facility is 784 provided to allow future specifications to extend SCVP. The syntax 785 for extensions is imported from [PKIX-1]. The queryExtensions item, 786 when present, MUST contain a sequence of extension items, and each 787 of extension MUST 788 contain extnID, critical, and extnValue items. 790 The extnID item is an identifier for the extension. It contains the 791 object identifier that names the extension. 793 The critical item is a BOOLEAN. Each extension is designated as 794 either critical (with a value of TRUE) or non-critical (with a value 795 of FALSE). An SCVP server MUST reject the query if it encounters a 796 critical extension it does not recognize; however, a non-critical 797 extension MAY be ignored if it is not recognized. 799 The extnValue item contains an octet string. Within the octet 800 string is the extension value. An ASN.1 type is specified for each 801 extension, identified by the associated extnID object identifier. 803 3.3 Requestor 805 The OPTIONAL requestor item is used to identify the requestor. The 806 value is only of local significance to the requestor. If the SCVP 807 client includes a requestor value in the request, then the SCVP 808 server MUST return the same value in the response. 810 The requestor item MUST be an octet string. No provisions are made 811 to ensure uniqueness of the requestor octet string; however, all of 812 the octets MUST have values other than zero. 814 3.4 requestNonce 816 The OPTIONAL requestNonce item contains an identifier generated by 817 the SCVP client for the request. If the client includes a 818 requestNonce value in the request, then the server MUST return the 819 same value in the response. The client SHOULD include a 820 requestNonce item in every request to prevent an attacker from 821 acting as a man-in-the-middle by replaying old responses from the 823 Malpani, Housley, & Freeman [Page17] 824 server. The requestNonce value SHOULD change with every request 825 sent by the client. 827 The requestNonce item MUST be an octet string. 829 3.5 reqExtensions 831 The OPTIONAL reqExtensions item contains Extensions. If present, 832 each Extension in the sequence extends the request. This 833 specification does not define any extensions, the facility is 834 provided to allow future specifications to extend the SCVP. The 835 syntax for Extensions is imported from [PKIX-1]. The reqExtensions 836 item, when present, MUST contain a sequence of extension items, and 837 each of extension MUST contain extnID, critical, and extnValue items. 839 The extnID item is an identifier for the extension. It contains the 840 object identifier that names the extension. 842 The critical item is a BOOLEAN. Each extension is designated as 843 either critical (with a value of TRUE) or non-critical (with a value 844 of FALSE). An SCVP server MUST reject the query if it encounters a 845 critical extension it does not recognize; however, a non-critical 846 extension MAY be ignored if it is not recognized. 848 The extnValue item contains an octet string. Within the octet 849 string is the extension value. An ASN.1 type is specified for each 850 extension, identified by the associated extnID object identifier. 852 4 Validation Response 854 A SCVP server response to the client MUST be a single SCVPResponse 855 item. A SCVPResponse item is carried in an application/scvp- 856 response MIME body part. 858 There are two forms of an SCVP response: unsigned and signed. An 859 unsigned response MUST only be generated for an error status. An 860 overview of the structure used for an unsigned response is provided 861 below. Many details are not shown, but the way that SCVP makes use 862 of CMS is clearly illustrated. 864 ContentInfo { 865 contentType id-ct-scvp-certValResponse, 866 -- (1.2.840.113549.1.9.16.1.11) 867 content CVResponse } 869 The signed response consists of a CVResponse encapsulated in either 870 a SignedData or a AuthenticatedData which is in turn encapsulated in 871 a ContentInfo. An overview of the structure used for a signed 872 response is provided below. Again, many details are not shown, but 873 the way that SCVP makes use of CMS is clearly illustrated. 875 Malpani, Housley, & Freeman [Page18] 876 Signed Data Example: 878 ContentInfo { 879 contentType id-signedData, -- (1.2.840.113549.1.7.2) 880 content SignedData } 882 SignedData { 883 version CMSVersion, 884 digestAlgorithms DigestAlgorithmIdentifiers, 885 encapContentInfo EncapsulatedContentInfo, 886 certificates CertificateSet, -- (MUST include server cert) 887 crls CertificateRevocationLists, -- (Optional) 888 signerInfos SET OF SignerInfos } -- Only 1 in SCVP 890 SignerInfo { 891 version CMSVersion, 892 sid SignerIdentifier, 893 digestAlgorithm DigestAlgorithmIdentifier, 894 signedAttrs SignedAttributes, -- (Required) 895 signatureAlgorithm SignatureAlgorithmIdentifier, 896 signature SignatureValue, 897 unsignedAttrs UnsignedAttributes } -- Not used in SCVP 899 AuthenticatedData Example: 901 ContentInfo { 902 contentType id-ct-authData, -- (1.2.840.113549.1.9.16.1.2) 903 content AuthenticatedData } 905 AuthenticatedData ::= SEQUENCE { 906 version CMSVersion, 907 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 908 recipientInfos RecipientInfos, 909 macAlgorithm MessageAuthenticationCodeAlgorithm, 910 digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, 911 encapContentInfo EncapsulatedContentInfo, 912 authAttrs [2] IMPLICIT AuthAttributes OPTIONAL, 913 mac MessageAuthenticationCode, 914 unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL } 915 -- Not used in SCVP 917 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 919 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 921 MessageAuthenticationCode ::= OCTET STRING 923 EncapsulatedContentInfo { 924 eContentType id-ct-scvp-psResponse, 926 Malpani, Housley, & Freeman [Page19] 927 -- (1.2.840.113549.1.9.16.1.11) 928 eContent OCTET STRING } -- Contains CVResponse 930 The SCVP server MUST include its own certificate in the certificates 931 field within SignedData. Other certificates can also be included. 932 The SCVP server MAY also provide one or more CRLs in the crls field 933 within SignedData. 935 The signedAttrs within SignerInfo MUST include the content-type and 936 message-digest attributes defined in [CMS] as well as the 937 SigningCertificate attribute as defined in [ESS]. Within the 938 SigningCertificate attribute, the first certificate identified in 939 the sequence of certificate identifiers MUST be the certificate of 940 the SCVP server. The inclusion of other certificate identifiers in 941 the SigningCertificate attribute is OPTIONAL. The inclusion of 942 policies in the SigningCertificate attribute is also OPTIONAL. 944 The value of the message-digest attribute in the signedAttrs within 945 SignerInfo MAY be used as an identifier of the reponse generated by 946 the SCVP server. 948 The CVResponse item contains the server response. The CVResponse 949 MUST contain the scvpVersion, producedAt, responseStatus, and 950 requestRef items. The CVResponse MAY also contain the requestor, 951 responder, replyObjects, requestNonce, serverContextInfo, and 952 respExtensions optional items. The replyObjects item MUST contain 953 exactly one CertReply item for each certificate requested. The 954 requestor and the responder items MUST be included if the request 955 included a requestor item. The requestNonce item MUST be included 956 if the request included a requestNonce item. 958 The CVResponse MUST have the following syntax: 960 CVResponse ::= SEQUENCE { 961 scvpVersion INTEGER, 962 producedAt GeneralizedTime, 963 responseStatus ResponseStatus, 964 requestRef RequestReference, 965 requestor [1] OCTET STRING OPTIONAL, 966 responder [2] OCTET STRING OPTIONAL, 967 replyObjects [3] ReplyObjects OPTIONAL, 968 requestNonce [4] OCTET STRING OPTIONAL, 969 serverContextInfo [5] OCTET STRING OPTIONAL, 970 respExtensions [6] Extensions OPTIONAL } 972 4.1 scvpVersion 974 The syntax and semantics of the scvpVersion item is described in 975 section 3.1. 977 Malpani, Housley, & Freeman [Page20] 978 4.2 producedAt 980 The producedAt item tells the date and time at which the SCVP server 981 generated the response. The producedAt item represents the date and 982 time in UTC, using the GeneralizedTime type. 984 GeneralizedTime value MUST be expressed Greenwich Mean Time (Zulu) 985 and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even 986 where the number of seconds is zero. GeneralizedTime values MUST 987 NOT include fractional seconds. 989 4.3 responseStatus 991 The responseStatus item gives status information to the SCVP client 992 about its request. The responseStatus item has a numeric status 993 code and an optional string that is a sequence of characters from 994 the ISO/IEC 10646-1 character set encoded with the UTF-8 995 transformation format defined in [UTF8]. 997 The string MAY optionally be used to transmit status information. 998 The client MAY choose to display the string to the human user. 999 However, because there is no way to know the languages understood by 1000 the human user, the string may be of little or no assistance. 1002 The responseStatus item uses the ResponseStatus type, which has the 1003 following syntax: 1005 ResponseStatus ::= SEQUENCE { 1006 statusCode SCVPStatusCode, 1007 errorMessage [0] UTF8String OPTIONAL } 1009 SCVPStatusCode ::= ENUMERATED { 1010 okay (0), 1011 skipUnrecognizedItems (1), 1012 tooBusy (10), 1013 internalError (12), 1014 badStructure (20), 1015 unsupportedVersion (21), 1016 abortUnrecognizedItems (22), 1017 unrecognizedSigKey (23), 1018 badSignature (24), 1019 unableToDecode (25), 1020 notAuthorized (26), 1021 unsupportedChecks (27), 1022 unsupportedWantBacks (28), 1023 unsupportedSignature (29), 1024 invalidSignature (30), 1025 relayingLoop (40) } 1027 The SCVPStatusCode values have the following meaning: 1029 Malpani, Housley, & Freeman [Page21] 1030 0 The request was fully processed 1031 1 The request included some unrecognized items; however, 1032 processing was able to continue ignoring them 1033 10 Too busy; try again later 1034 20 The structure of the request was wrong 1035 21 The version of request is not supported by this server 1036 22 The request included unrecognized items, and the server was 1037 not able to continue processing 1038 23 The key given in the RequestSignature is not recognized 1039 24 The signature did not match the body of the request 1040 25 The encoding was not understood 1041 26 The request was not authorized 1042 27 The request included unsupported checks items, and the server 1043 was not able to continue processing 1044 28 The request included unsupported want back items, and the 1045 server was not able to continue processing 1046 29 The server does not support the signature algorithm used by 1047 the client to sign the request 1048 30 The server could not validate the client's signature on the 1049 request 1050 40 The request was previously relayed by the same server 1052 4.4 requestReference 1054 The requestRef allows the SCVP server to identify the request that 1055 corresponds to this response. It associates the response to a 1056 particular request using a hash of the request or a copy of 1057 CVRequest from the request. 1059 The requestRef item does not provide authentication, but the 1060 requestRef does allow the client to determine that the request was 1061 not maliciously modified. 1063 When using connectionless protocols, the requestRef item allows the 1064 client to associate a response with a request. However, the 1065 requestNonce provides a better mechanism for matching requests and 1066 responses. When the fullRequest alternative is used, the response 1067 provides a single data structure that is suitable for archive of the 1068 transaction. 1070 The requestRef item uses the RequestReference type, which has the 1071 following syntax: 1072 RequestReference ::= CHOICE { 1073 requestHash [1] HashValue, -- hash of CVRequest 1074 fullRequest [2] CVRequest } 1076 4.4.1 requestHash 1078 Malpani, Housley, & Freeman [Page22] 1079 The requestHash item is the hash of the CVRequest. By default, SHA- 1080 1 is used as the one-way hash function, but others can be used. 1081 The requestHash item serves two purposes. First, it allows a client 1082 to determine that the request was not maliciously modified. Second, 1083 it allows the client to associate a response with a request when 1084 using connectionless protocols. However, the requestNonce provides 1085 a better mechanism for matching requests and responses. 1087 The requestHash item uses the HashValue type, which has the 1088 following syntax: 1090 HashValue ::= SEQUENCE { 1091 algorithm AlgorithmIdentifier DEFAULT { sha-1 }, 1092 value OCTET STRING } 1094 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1095 oiw(14) secsig(3) algorithm(2) 26 } 1097 The algorithm identifier for SHA-1 is imported from [PKIX-ALG]. It 1098 is repeated here for convenience. 1100 4.4.2 fullRequest 1102 Like requestHash, the fullRequest alternative allows a client to 1103 determine that the request was not maliciously modified. It also 1104 provides a single data structure that is suitable for archive of the 1105 transaction. 1107 The fullRequest item uses the CVRequest type. The syntax and 1108 semantics of the PSRequest type are described in section 3. 1110 4.5 Requestor 1112 The OPTIONAL requestor item is used to identify the requestor. The 1113 value is only of local significance to the requestor. If the SCVP 1114 client includes a requestor value in the request, then the SCVP 1115 server MUST return the same value in the response. 1117 The requestor item MUST be an octet string. No provisions are made 1118 to ensure uniqueness of the requestor octet string; however, all of 1119 the octets MUST have values other than zero. 1121 4.6 responder 1123 The OPTIONAL responder item is used to identify the server. The 1124 value chosen is only of local significance to the SCVP server. The 1125 responder items MUST be included if the request included a requestor 1126 item. 1128 Malpani, Housley, & Freeman [Page23] 1129 The responder item MUST be an octet string. No provisions are made 1130 to ensure uniqueness of the requestor octet string; however, all of 1131 the octets MUST have values other than zero. 1133 4.7 replyObjects 1135 The replyObjects item returns requested objects to the SCVP client, 1136 each of which tells the client about a single certificate from the 1137 request. The replyObjects item MUST be present in the response, 1138 unless the response is reporting an error. The CertReply item MUST 1139 contain cert, replyStatus, replyValTime, replyChecks, replyWantBack, 1140 and valPolicy items; and the CertReply item MAY contain the 1141 nextUpdate and certReplyExtensions optional items. 1143 A non-error response MUST contain one CertReply for each Query item 1144 in the request. The order is important. The first CertReply in the 1145 sequence MUST correspond to the first Query item in the request; the 1146 second CertReply in the sequence MUST correspond to the second Query 1147 item in the request; and so on. 1149 The checks item in the request determines the content of the 1150 replyChecks item in the response. The wantBack item in the request 1151 determines the content of the replyWantBacks item in the response. 1152 The queryExtensions items in the request controls the absence or the 1153 presence and content of the certReplyExtensions item in the response. 1155 The replyObjects item uses the ReplyObjects type, which has the 1156 following syntax: 1158 ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply 1160 CertReply ::= SEQUENCE { 1161 cert CertReference, 1162 replyStatus ReplyStatus, 1163 replyValTime GeneralizedTime, 1164 replyChecks ReplyChecks, 1165 replyWantBacks ReplyWantBacks, 1166 valPolicy ValidationPolicy, 1167 nextUpdate [1] GeneralizedTime OPTIONAL, 1168 certReplyExtensions [2] Extensions OPTIONAL } 1170 4.7.1 cert 1172 The cert item contains either the public key certificate or the 1173 attribute certificate or a reference to the certificate about which 1174 the client is requesting information. 1176 The ASN.1 definition of Certificate is imported from [PKIX-1]; and 1177 the definition of AttributeCertificate is imported from [PKIX-AC]. 1179 Malpani, Housley, & Freeman [Page24] 1180 4.7.2 replyStatus 1182 The replyStatus item gives status information to the client about 1183 the request for the specific certificate. Note that the 1184 responseStatus item is different than the replyStatus item. The 1185 responseStatus item is the status of the whole request, while the 1186 replyStatus item is the status for the individual query item. 1188 The replyStatus item uses the ReplyStatus type, which has the 1189 following syntax: 1191 ReplyStatus ::= ENUMERATED { 1192 success (0), 1193 unrecognizedCheck (1), 1194 unrecognizedWantBack (2), 1195 malformedPKC (3), 1196 malformedAC (4), 1197 unrecognizedCertPolicy (5), 1198 unrecognizedValPolicy (6), 1199 unrecognizedExtension (7), 1200 unavailableValidityTime (8), 1201 referenceCertHashFail (9), 1202 certPathConstructFail (10), 1203 certPathNotValid (11), 1204 certPathNotValidNow (12) } 1206 The meaning of the various ReplyStatus values are: 1208 0 Success: a definitive answer follows 1209 1 Failure: an OID in the check item is not recognized 1210 2 Failure: an OID in the wantBack item is not recognized 1211 3 Failure: the public key certificate was malformed 1212 4 Failure: the attribute certificate was malformed 1213 5 Failure: the certificate policy OID is not recognized 1214 6 Failure: the validation policy OID is not recognized 1215 7 Failure: the extension OID is not recognized 1216 8 Failure: historical data for the requested validity time is 1217 not available 1218 9 Failure: the referenced certificate did not match the hash 1219 value provided 1220 10 Failure: no certification path could be constructed 1221 11 Failure: the constructed certification path is invalid 1222 12 Failure: the constructed certification path is invalid, but a 1223 query at a later time may be successful 1225 Codes 3 and 4 are used to tell the client that the request was 1226 properly formed, but the certificate in question was not. This is 1227 especially useful to clients that do not parse certificates. 1229 Malpani, Housley, & Freeman [Page25] 1230 4.7.3 replyValTime 1232 The replyValTime item tells the time at which the information in the 1233 CertReply was correct. The replyValTime item represents the date 1234 and time in UTC, using GeneralizedTime type. The encoding rules for 1235 GeneralizedTime in section 4.2 MUST be used. 1237 Within the request, the optional validityTime item tells the date 1238 and time relative to which the SCVP client wants the server to 1239 perform the checks. If the validityTime is not present, the server 1240 MUST respond as if the client provided the date and time at which 1241 the server processes the request. 1243 The information in the CertReply item MUST be formatted as if the 1244 server created this portion of response at the time indicated in the 1245 validityTime item of the query. However, if the server does not 1246 have appropriate historical information, the server MAY either 1247 return an error or return information for a later time. 1249 4.7.4 replyChecks 1251 The replyChecks contains the responses to the checks item in the 1252 query. The replyChecks item repeats the object identifier (OID) 1253 from the query and an integer. The value of the integer indicates 1254 whether the requested check was successful. The OIDs in the checks 1255 item of the query are used to identify the corresponding replyChecks 1256 values. The OIDs in the replyChecks item MUST match the OIDs in the 1257 checks item in the request. 1259 The replyChecks item uses the ReplyChecks type, which has the 1260 following syntax: 1262 ReplyChecks ::= SEQUENCE OF ReplyCheck 1264 ReplyCheck ::= SEQUENCE { 1265 check OBJECT IDENTIFIER, 1266 status INTEGER } 1268 The status value for public key certification path building to a 1269 trusted root, { id-stc 1 }, can be one of the following: 1271 0: Built a path 1272 1: Could not build a path 1274 The status value for public key certification path building to a 1275 trusted root along with simple validation processing, { id-stc 2 }, 1276 can be one of the following: 1278 0: Valid 1279 1: Not valid 1281 Malpani, Housley, & Freeman [Page26] 1282 The status value for public key certification path building to a 1283 trusted root along with complete status checking, { id-stc 3 }, can 1284 be one of the following: 1286 0: Good 1287 1: Revoked 1288 2: Unknown 1289 3: Unavailable 1291 The status value for AC issuer certification path building to a 1292 trusted root, { id-stc 4 }, can be one of the following: 1294 0: Built a path 1295 1: Could not build a path 1297 The status value for AC issuer certification path building to a 1298 trusted root along with simple validation processing, { id-stc 5 }, 1299 can be one of the following: 1301 0: Valid 1302 1: Not valid 1304 The status value for AC issuer certification path building to a 1305 trusted root along with complete status checking, { id-stc 6 }, can 1306 be one of the following: 1308 0: Good 1309 1: Revoked 1310 2: Unknown 1311 3: Unavailable 1313 The status value for revocation status checking of an AC as well as 1314 AC issuer certification path building to a trusted root along with 1315 complete status checking, { id-stc 7 }, can be one of the following: 1317 0: Good 1318 1: Revoked 1319 2: Unknown 1320 3: Unavailable 1322 4.7.5 replyWantBack 1324 The replyWantBack contains the responses to the wantBack item in the 1325 request. The replyWantBack item includes the object identifier 1326 (OID) from the wantBack item in the request and an octet string. 1327 Within the octet string is the requested value. The OIDs in the 1328 wantBack item in the request are used to identify the corresponding 1329 reply value. The OIDs in the replyWantBack item MUST match the OIDs 1330 in the wantBack item in the request. 1332 Malpani, Housley, & Freeman [Page27] 1333 The replyWantBack item uses the ReplyWantBack type, which has the 1334 following syntax: 1336 ReplyWantBacks ::= SEQUENCE OF ReplyWantBack 1338 ReplyWantBack::= SEQUENCE { 1339 wb OBJECT IDENTIFIER, 1340 value OCTET STRING } 1342 The octet string value for the certification path used to verify the 1343 certificate in the request, { id-swb 1 }, contains the CertBundle 1344 type. The syntax and semantics of the CertBundle type are described 1345 in section 3.2.7. 1347 The octet string value for the proof of revocation status, { id-swb 1348 2 }, contains the RevocationInfo type. The syntax and semantics of 1349 the RevocationInfo type are described in section 3.2.9. 1351 The octet string value for the public key certificate status, { id- 1352 swb 3 }, contains an ASN.1 BOOLEAN type. The value will be TRUE if 1353 the certificate is valid, and the value will be FALSE if the 1354 certificate is not valid. 1356 The octet string value for the public key information, { id-swb 4 }, 1357 contains the SubjectPublicKeyInfo type. The syntax and semantics of 1358 the SubjectPublicKeyInfo type are described in [PKIX-1]. 1360 The octet string value for the AC issuer certification path used to 1361 verify the certificate in the request, { id-swb 5 }, contains the 1362 CertBundle type. The syntax and semantics of the CertBundle type 1363 are described in section 3.2.7. 1365 The octet string value for the proof of revocation status of the AC 1366 issuer certification path, { id-swb 6 }, contains the RevocationInfo 1367 type. The syntax and semantics of the RevocationInfo type are 1368 described in section 3.2.9. 1370 The octet string value for the proof of revocation status of the 1371 attribute certificate, { id-swb 7 }, contains the RevocationInfo 1372 type. The syntax and semantics of the RevocationInfo type are 1373 described in section 3.2.9. 1375 The octet string value for the attribute certificate status, { id- 1376 swb 8 }, contains an ASN.1 BOOLEAN type. The value will be TRUE if 1377 the certificate is valid, and the value will be FALSE if the 1378 certificate is not valid. 1380 4.7.6 valPolicy 1382 Malpani, Housley, & Freeman [Page28] 1383 The valPolicy item tells the validation policy used by the SCVP 1384 server. Even if the query does not include a validation policy, the 1385 server MUST indicate the validation policy that was used. The 1386 valPolicy value MUST NOT be id-svp-defaultValPolicy. 1388 The syntax and semantics of the valPolicy item are descried in 1389 section 3.2.5. 1391 4.7.7 nextUpdate 1393 The nextUpdate item tells the time at which the server expects a 1394 refresh of information regarding the validity of the certificate to 1395 become available. The nextUpdate is especially interesting if the 1396 certificate revocation status information is not available or the 1397 certificate is suspended. The nextUpdate item represents the date 1398 and time in UTC, using the GeneralizedTime type. The encoding rules 1399 for GeneralizedTime in section 4.2 MUST be used. 1401 4.7.8 certReplyExtensions 1403 The certReplyExtensions contains the responses to the queryExtension 1404 item in the request. The singleReplyExtensions item uses the 1405 Extensions type defined in [PKIX-1]. The object identifiers (OIDs) 1406 in the queryExtension item in the request are used to identify the 1407 corresponding reply value. The certReplyExtensions item, when 1408 present, contains a sequence of Extension items, each of which 1409 contains an extnID item, a critical item, and an extnValue item. 1411 The extnID item is an identifier for the extension. It contains the 1412 OID that names the extension, and it MUST match one of the OIDs in 1413 the queryExtension item in the request. 1415 The critical item is a BOOLEAN, and it MUST be set to FALSE. 1416 The extnValue item contains an OCTET STRING. Within the OCTET 1417 STRING is the extension value. An ASN.1 type is specified for each 1418 extension, and identified by extnID. 1420 4.8 requestNonce 1422 The requestNonce optional item contains an identifier generated by 1423 the client for the request. If the client includes a requestNonce 1424 value in the request, then the server MUST return the same value in 1425 the response. 1427 The requestNonce item uses the octet string type. 1429 4.9 serverContextInfo 1431 The serverContextInfo item in a response is a mechanism for the 1432 server to pass some opaque context information to the client. If 1434 Malpani, Housley, & Freeman [Page29] 1435 the client does not like the certification path retuned, it can make 1436 a new query and pass along this context information. 1438 Section 3.2.4 contains information about the client usage of this 1439 item. 1441 The context information is opaque to the client, but it provides 1442 information to the server that ensures that a different 1443 certification path will be returned (if another one can be found). 1444 The context information could indicate state on the server or it 1445 could contain a sequence of hashes of certification paths that have 1446 already returned to the client. The protocol does not dictate any 1447 structure or requirements for this item. However, implementers 1448 should review the Security Considerations section of this document 1449 before selecting a structure. 1451 Servers that are incapable of returning additional paths MUST NOT 1452 include the serverContextInfo item in the response. 1454 4.10 respExtensions 1456 The respExtensions item MAY contain Extensions. If present, each 1457 Extension in the sequence extends the request. This specification 1458 does not define any extensions, the facility is provided to allow 1459 future specifications to extend the SCVP. The syntax for Extensions 1460 is imported from [PKIX-1]. The respExtensions item, when present, 1461 contains a sequence of Extension items, each of which contains an 1462 extnID item, a critical item, and an extnValue item. 1464 The extnID item is an identifier for the extension. It contains the 1465 object identifier (OID) that names the extension. 1466 The critical item is a BOOLEAN. Each extension is designated as 1467 either critical (with a value of TRUE) or non-critical (with a value 1468 of FALSE). An SCVP client MUST reject the response if it encounters 1469 a critical extension it does not recognize; however, a non-critical 1470 extension MAY be ignored if it is not recognized. 1472 The extnValue item contains an OCTET STRING. Within the OCTET 1473 STRING is the extension value. An ASN.1 type is specified for each 1474 extension, and identified by extnID. 1476 5 Validation Policies Request 1478 A SCVP client uses the VPRequest item to request the list of 1479 validation policies supported by the SCVP server. When a VPRequest 1480 is encapsulated in a MIME body part, it MUST be carried in an 1481 application/scvp-policies-request MIME body part. 1483 The request consists of a VPRequest encapsulated in a ContentInfo. 1484 The request is not signed by the client. 1486 Malpani, Housley, & Freeman [Page30] 1487 ContentInfo { 1488 contentType id-ct-scvp-valPolRequest, 1489 -- (1.2.840.113549.1.9.16.1.12) 1490 content VPRequest } 1492 The VPRequest type has the following syntax: 1494 VPRequest ::= SEQUENCE { 1495 scvpVersion INTEGER } 1497 The scvpVersion item is described in section 3.1. 1499 6 Validation Policies Response 1501 In response to a VPRequest, the SCVP server provides a VPResponse. 1502 When a VPResponse is encapsulated in a MIME body part, it MUST be 1503 carried in an application/scvp-policies-response MIME body part. 1505 The request consists of a VPRequest encapsulated in a ContentInfo. 1506 The response is not signed by the server. 1508 ContentInfo { 1509 contentType id-ct-scvp-valPolResponse, 1510 -- (1.2.840.113549.1.9.16.1.13) 1511 content VPResponse } 1513 The VPResponse type has the following syntax: 1515 ValPoliciesResponse ::= SEQUENCE { 1516 scvpVersion INTEGER, 1517 valPolicies SEQUENCE OF OBJECT IDENTIFIER } 1519 The scvpVersion item is described in section 3.1. 1520 The valPolicies item contains a sequence of object identifiers 1521 (OIDs). Each OID identifies a single validation policy supported by 1522 the server. 1524 7 SCVP Server Relay 1526 In some network environments, especially ones that include firewalls, 1527 an SCVP server might not be able to obtain all of the information 1528 that it needs to process a request. However, the server might be 1529 configured to use the services of one or more other SCVP servers to 1530 fulfill all requests. In such cases, the SCVP client is unaware 1531 that the initial SCVP server is using the services of other SCVP 1532 servers. The initial SCVP server acts as a client to another SCVP 1533 server. Unlike the original client, the SCVP server is expected to 1534 have moderate computing and memory resources. This section 1535 describes SCVP server-to-SCVP server exchanges. This section does 1537 Malpani, Housley, & Freeman [Page31] 1538 not impose any requirements on SCVP clients that are not also SCVP 1539 servers. Further, this section does not impose any requirements on 1540 SCVP servers that do not relay requests to other SCVP servers. 1542 When one SCVP server relays a request to another server, in an 1543 incorrectly configured system of servers, it is possible that the 1544 same request will be relayed back again. Any SCVP server that 1545 relays requests MUST implement the conventions described in this 1546 section to detect and break loops. 1548 When an SCVP server relays a request, the request MUST include the 1549 requestor item. If the request to be relayed already contains a 1550 requestor item, then server-generated request MUST contain a 1551 requestor item constructed from this value followed by a zero octet 1552 followed by the identifier of the SCVP server. If the request to be 1553 relayed does not contain a requestor item, then server-generated 1554 request MUST contain only identifier of the SCVP server. 1556 When an SVCP server receives a request that contains a requestor 1557 item, the server MUST check for its own identifier. The identifier 1558 could be located at the beginning of the octet string followed by a 1559 zero octet, or it could be located between two zero octets. If the 1560 server discovers its own identifier in the requestor item, it MUST 1561 respond with an error, setting the responseStatus to 40. 1563 8 SCVP ASN.1 Module 1565 This section defines the syntax for SCVP request-response pairs. 1566 The semantics for the messages are defined in sections 3, 4, 5, and 1567 6. The SCVP ASN.1 module follows. 1569 SCVP 1571 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 1572 mechanisms(5) pkix(7) id-mod(0) 21 } 1574 DEFINITIONS IMPLICIT TAGS ::= BEGIN 1576 IMPORTS 1578 AlgorithmIdentifier, Certificate, Extensions, Name, 1579 SubjectPublicKeyInfo 1580 FROM PKIX1Explicit88 -- RFC 3280 1581 { iso(1) identified-organization(3) dod(6) internet(1) 1582 security(5) mechanisms(5) pkix(7) id-mod(0) 18 } 1584 AttributeCertificate 1585 FROM PKIXAttributeCertificate -- RFC 3281 1586 { iso(1) identified-organization(3) dod(6) internet(1) 1587 security(5) mechanisms(5) pkix(7) id-mod(0) 12 } 1589 Malpani, Housley, & Freeman [Page32] 1590 ESSCertID FROM ExtendedSecurityServices -- RFC 2634 1591 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1592 pkcs-9(9) smime(16) modules(0) 2 } ; 1594 -- SCVP Certificate Validation Request 1596 id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1597 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1598 id-smime(16) 1 } 1600 id-ct-scvp-certValRequest OBJECT IDENTIFIER ::= { id-ct 10 } 1602 CVRequest ::= SEQUENCE { 1603 scvpVersion INTEGER, 1604 query Query, 1605 requestor [0] OCTET STRING OPTIONAL, 1606 requestNonce [1] OCTET STRING OPTIONAL, 1607 reqExtensions [2] Extensions OPTIONAL } 1609 Query ::= SEQUENCE { 1610 queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, 1611 checks CertChecks, 1612 wantBack WantBack, 1613 serverContextInfo [0] OCTET STRING OPTIONAL, 1614 valPolicy [1] ValidationPolicy OPTIONAL, 1615 validityTime [2] GeneralizedTime OPTIONAL, 1616 trustAnchors [3] TrustAnchors OPTIONAL, 1617 intermediateCerts [4] CertBundle OPTIONAL, 1618 revInfos [5] RevocationInfos OPTIONAL, 1619 queryExtensions [6] Extensions OPTIONAL } 1621 CertReference::= CHOICE { 1622 pkc PKCReference, 1623 ac ACReference } 1625 PKCReference ::= CHOICE { 1626 cert [1] Certificate, 1627 pkcRef [2] ESSCertID } 1629 ACReference ::= CHOICE { 1630 attrCert [3] AttributeCertificate, 1631 acRef [4] ESSCertID } 1633 CertChecks ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 1635 WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 1637 ValidationPolicy ::= SEQUENCE { 1638 valPolicyId OBJECT IDENTIFIER, 1640 Malpani, Housley, & Freeman [Page33] 1641 parameters ANY DEFINED BY valPolicyId OPTIONAL } 1643 TrustAnchors ::= SEQUENCE SIZE (1..MAX) OF TrustAnchor 1645 TrustAnchor ::= SEQUENCE { 1646 anchor PKCReference, 1647 certPolicies [1] SEQUENCE SIZE (1..MAX) OF 1648 OBJECT IDENTIFIER OPTIONAL } 1649 -- if absent, use any-policy 1651 CertBundle ::= SEQUENCE SIZE (1..MAX) OF PKCReference 1653 RevocationInfos ::= SEQUENCE SIZE (1..MAX) OF RevocationInfo 1655 RevocationInfo ::= CHOICE { 1656 crl [0] CertificateList, 1657 delta-crl [1] CertificateList, 1658 ocsp [2] OCSPResponse, 1659 other [3] OtherRevInfo } 1661 OtherRevInfo ::= SEQUENCE { 1662 retype OBJECT IDENTIFIER, 1663 revalue ANY DEFINED BY retype } 1665 -- SCVP Certificate Validation Request 1667 id-ct-scvp-certValResponse OBJECT IDENTIFIER ::= { id-ct 11 } 1668 CVResponse ::= SEQUENCE { 1669 scvpVersion INTEGER, 1670 producedAt GeneralizedTime, 1671 responseStatus ResponseStatus, 1672 requestRef RequestReference, 1673 requestor [1] OCTET STRING OPTIONAL, 1674 responder [2] OCTET STRING OPTIONAL, 1675 replyObjects [3] ReplyObjects OPTIONAL, 1676 requestNonce [4] OCTET STRING OPTIONAL, 1677 serverContextInfo [5] OCTET STRING OPTIONAL, 1678 respExtensions [6] Extensions OPTIONAL } 1680 ResponseStatus ::= SEQUENCE { 1681 statusCode SCVPStatusCode, 1682 errorMessage [0] UTF8String OPTIONAL } 1684 SCVPStatusCode ::= ENUMERATED { 1685 okay (0), 1686 skipUnrecognizedItems (1), 1687 tooBusy (10), 1688 badStructure (20), 1689 unsupportedVersion (21), 1690 abortUnrecognizedItems (22), 1692 Malpani, Housley, & Freeman [Page34] 1693 unrecognizedSigKey (23), 1694 badSignature (24), 1695 unableToDecode (25), 1696 notAuthorized (26), 1697 unsupportedChecks (27), 1698 unsupportedWantBacks (28), 1699 unsupportedSignature (29), 1700 invalidSignature (30), 1701 relayingLoop (40) } 1703 RequestReference ::= CHOICE { 1704 requestHash [1] HashValue, -- hash of CVRequest 1705 fullRequest [2] CVRequest } 1707 HashValue ::= SEQUENCE { 1708 algorithm AlgorithmIdentifier DEFAULT { sha-1 }, 1709 value OCTET STRING } 1711 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1712 oiw(14) secsig(3) algorithm(2) 26 } 1714 ReplyObjects ::= SEQUENCE SIZE (1..MAX) OF CertReply 1716 CertReply ::= SEQUENCE { 1717 cert ReplyCertificate, 1718 replyStatus ReplyStatus, 1719 replyValTime GeneralizedTime, 1720 replyChecks ReplyChecks, 1721 replyWantBacks ReplyWantBacks, 1722 valPolicy ValidationPolicy, 1723 nextUpdate [1] GeneralizedTime OPTIONAL, 1724 certReplyExtensions [2] Extensions OPTIONAL } 1726 ReplyCertificate ::= CHOICE { 1727 pkc [1] Certificate, 1728 ac [2] AttributeCertificate } 1730 ReplyStatus ::= ENUMERATED { 1731 success (0), 1732 unrecognizedCheck (1), 1733 unrecognizedWantBack (2), 1734 malformedPKC (3), 1735 malformedAC (4), 1736 unrecognizedCertPolicy (5), 1737 unrecognizedValPolicy (6), 1738 unrecognizedExtension (7), 1739 unavailableValidityTime (8), 1740 referenceCertHashFail (9), 1741 certPathConstructFail (10), 1743 Malpani, Housley, & Freeman [Page35] 1744 certPathNotValid (11), 1745 certPathNotValidNow (12) } 1747 ReplyChecks ::= SEQUENCE OF ReplyCheck 1749 ReplyCheck ::= SEQUENCE { 1750 check OBJECT IDENTIFIER, 1751 status INTEGER } 1753 ReplyWantBacks ::= SEQUENCE OF ReplyWantBack 1755 ReplyWantBack::= SEQUENCE { 1756 wb OBJECT IDENTIFIER, 1757 value OCTET STRING } 1759 -- SCVP Validation Policies Request 1761 id-ct-scvp-valPolRequest OBJECT IDENTIFIER ::= { id-ct 12 } 1763 VPRequest ::= SEQUENCE { 1764 scvpVersion INTEGER } 1766 -- SCVP Validation Policies Response 1768 id-ct-scvp-valPolResponse OBJECT IDENTIFIER ::= { id-ct 13 } 1770 ValPoliciesResponse ::= SEQUENCE { 1771 scvpVersion INTEGER, 1772 valPolicies SEQUENCE OF OBJECT IDENTIFIER } 1774 -- SCVP Check Identifiers 1776 id-stc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1777 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 17 } 1779 id-stc-build-pkc-path OBJECT IDENTIFIER ::= { id-stc 1 } 1780 id-stc-build-valid-pkc-path OBJECT IDENTIFIER ::= { id-stc 2 } 1781 id-stc-build-status-checked-pkc-path 1782 OBJECT IDENTIFIER ::= { id-stc 3 } 1783 id-stc-build-aa-path OBJECT IDENTIFIER ::= { id-stc 4 } 1784 id-stc-build-valid-aa-path OBJECT IDENTIFIER ::= { id-stc 5 } 1785 id-stc-build-status-checked-aa-path 1786 OBJECT IDENTIFIER ::= { id-stc 6 } 1787 id-stc-status-check-ac-and-build-status-checked-aa-path 1788 OBJECT IDENTIFIER ::= { id-stc 7 } 1790 -- SCVP WantBack Identifiers 1792 id-swb OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1793 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 18 } 1795 Malpani, Housley, & Freeman [Page36] 1796 id-swb-pkc-cert-path OBJECT IDENTIFIER ::= { id-swb 1 } 1797 id-swb-pkc-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 } 1798 id-swb-pkc-cert-status OBJECT IDENTIFIER ::= { id-swb 3 } 1799 id-swb-pkc-public-key-info OBJECT IDENTIFIER ::= { id-swb 4 } 1800 id-swb-aa-cert-path OBJECT IDENTIFIER ::= { id-swb 5 } 1801 id-swb-aa-revocation-info OBJECT IDENTIFIER ::= { id-swb 6 } 1802 id-swb-ac-revocation-info OBJECT IDENTIFIER ::= { id-swb 7 } 1803 id-swb-ac-cert-status OBJECT IDENTIFIER ::= { id-swb 8 } 1805 -- SCVP Validation Policy Identifiers 1807 id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1808 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 } 1810 id-svp-defaultValPolicy OBJECT IDENTIFIER ::= { id-svp 1 } 1812 END 1814 9 Security Considerations 1816 A client that trusts a server's response for validation of a 1817 certificate inherently trusts that server as much as it would trust 1818 its own validation software. This means that if an attacker 1819 compromises a trusted SCVP server, the attacker can change the 1820 validation processing for every client that relies on that server. 1821 Thus, an SCVP server must be protected at least as well as the trust 1822 anchors that the SCVP server trusts. 1824 Clients MUST check the requestRef item in the response and ensure 1825 that it matches their original request. Requests contain a lot of 1826 information that affects the response and clients need to ensure 1827 that the server response corresponds to the expected request. 1829 When the SCVP response is used to determine the validity of a 1830 certificate, the client MUST validate the signature on the response 1831 to ensure that the expected SCVP server generated it. If the client 1832 does not check the signature on the response, a man-in-the-middle 1833 attack could fool the client into believing modified responses from 1834 the server, or responses to questions the client did not ask. 1836 If the client does not include a requestNonce item, or if the client 1837 does not check that the requestNonce in the response matches the 1838 value in the request, an attacker can replay previous responses from 1839 the SCVP server. 1841 If the server does not require some sort of authorization (such as 1842 signed requests), an attacker can get the server to respond to 1843 arbitrary requests. Such responses may give the attacker 1844 information about weaknesses in the server or about the timeliness 1846 Malpani, Housley, & Freeman [Page37] 1847 of the server's checking. This information may be valuable for a 1848 future attack. 1850 If the server uses the serverContextInformation to indicate some 1851 server state associated with a requestor, implementers must take 1852 appropriate measures against denial of service attacks where an 1853 attacker sends in a lot of requests at one time to force the server 1854 to keep a lot of state information. 1856 The request and response for which policies are supported on the 1857 server are unsigned. These could lead to a denial of service attack 1858 where a man-in-the-middle indicates that a server supports a 1859 different set of validation policies than it actually does. This 1860 could result in the client requesting validation based on a policy 1861 the server does not support or lead the client using a less 1862 desirable policy. 1864 SCVP does not include any confidentiality mechanisms. If 1865 confidentiality is needed, it can be achieved with a lower-layer 1866 security protocol. 1868 10 References 1870 Normative and informative references are provided. 1872 10.1 Normative References 1874 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1875 Requirement Levels", BCP 14, RFC 2119, March 1997. 1877 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, 1878 June 1999. 1880 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S. and 1881 C. Adams, "X.509 Internet Public Key Infrastructure - 1882 Online Certificate Status Protocol - OCSP", RFC 2560, 1883 June 1999. 1885 [PKIX-1] Housley, R., Polk, T, Ford, W. and Solo, D., "Internet 1886 X.509 Public Key Infrastructure Certificate and 1887 Certificate Revocation List (CRL) Profile", RFC 3280, 1888 April 2002. 1890 [PKIX-AC] Farrell, S., and R. Housley, "An Internet Attribute 1891 Certificate Profile for Authorization", RFC 3281, 1892 April 2002. 1894 [PKIX-ALG] Polk, W., Housley, R. and L. Bassham, "Algorithms and 1895 Identifiers for the Internet X.509 Public Key 1896 Infrastructure Certificate and Certificate Revocation 1898 Malpani, Housley, & Freeman [Page38] 1899 List (CRL) Profile", RFC 3279, April 2002. 1901 [SHA-1] National Institute of Standards and Technology, 1902 "Secure Hash Standard", NIST FIPS Pub 180-1, April 1995. 1904 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 1905 10646", RFC 2279, January 1998. 1907 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", 1908 RFC 2634, June 1999. 1910 [HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC2818, May 2000. 1912 10.2 Informative References 1914 [OpenPGP] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 1915 "OpenPGP Message Format", RFC 2440, November 1998. 1917 [RQMTS] Pinkas, D., and R. Housley, "Delegated Path Validation 1918 and Delegated Path Discovery Protocol Requirements", 1919 RFC 3379, September 2002. 1921 11 Acknowledgments 1923 The lively debate in the PKIX Working Group has made a significant 1924 impact on this protocol. Denis Pinkas and Phillip Hallam-Baker 1925 suggested additional requirements for the protocol. Mike Myers 1926 identified areas that needed clarification. Frank Balluffi and 1927 Ameya Talwalkar did an implementation based on an early draft of 1928 this protocol, and they identified a few deficiencies. John 1929 Thielens, Peter Sylvester, and Yuriy Dzambasow provided good input, 1930 greatly improving this document. 1932 Appendix A -- MIME Registrations 1934 Four MIME type registrations are provided in this appendix. 1936 A.1 application/scvp-request 1938 To: ietf-types@iana.org 1939 Subject: Registration of MIME media type application/scvp-request 1941 MIME media type name: application 1943 MIME subtype name: scvp-request 1945 Required parameters: format 1947 Optional parameters: None 1949 Malpani, Housley, & Freeman [Page39] 1950 Encoding considerations: binary 1952 Security considerations: Carries a request for information. This 1953 request may optionally be cryptographically signed. 1955 Interoperability considerations: None 1957 Published specification: IETF PKIX Working Group Draft on Simple 1958 Certificate Validation Protocol (SCVP) 1960 Applications which use this media type: SCVP clients 1962 Additional information: 1963 Magic number(s): None 1964 File extension(s): .SCQ 1965 Macintosh File Type Code(s): none 1967 Person & email address to contact for further information: 1968 Ambarish Malpani 1970 Intended usage: COMMON 1972 Author/Change controller: 1973 Ambarish Malpani 1975 A.2 application/scvp-response 1977 To: ietf-types@iana.org 1978 Subject: Registration of MIME media type application/scvp-response 1980 MIME media type name: application 1982 MIME subtype name: scvp-response 1984 Required parameters: format 1986 Optional parameters: None 1988 Encoding considerations: binary 1990 Security considerations: Unless reporting an error, the response is 1991 cryptographically signed 1993 Interoperability considerations: None 1995 Published specification: IETF PKIX Working Group Draft on Simple 1996 Certificate Validation Protocol (SCVP) 1998 Applications which use this media type: SCVP servers 2000 Malpani, Housley, & Freeman [Page40] 2001 Additional information: 2003 Magic number(s): None 2004 File extension(s): .SCS 2005 Macintosh File Type Code(s): none 2007 Person & email address to contact for further information: 2008 Ambarish Malpani 2010 Intended usage: COMMON 2012 Author/Change controller: Ambarish Malpani 2014 A.3 application/scvp-policies-request 2016 To: ietf-types@iana.org 2017 Subject: Registration of MIME media type application/scvp-policies- 2018 request 2020 MIME media type name: application 2022 MIME subtype name: scvp-policies-request 2024 Required parameters: format 2026 Optional parameters: None 2028 Encoding considerations: binary 2030 Security considerations: Carries a request for information. 2032 Interoperability considerations: None 2034 Published specification: IETF PKIX Working Group Draft on Simple 2035 Certificate Validation Protocol (SCVP) 2037 Applications which use this media type: SCVP clients 2039 Additional information: 2041 Magic number(s): None 2042 File extension(s): .SPQ 2043 Macintosh File Type Code(s): none 2045 Person & email address to contact for further information: 2046 Ambarish Malpani 2048 Intended usage: COMMON 2050 Author/Change controller: Ambarish Malpani 2052 Malpani, Housley, & Freeman [Page41] 2053 A.4 application/scvp-policies-response 2055 To: ietf-types@iana.org 2056 Subject: Registration of MIME media type application/scvp-policies- 2057 response 2059 MIME media type name: application 2061 MIME subtype name: scvp-policies-response 2063 Required parameters: format 2065 Optional parameters: None 2067 Encoding considerations: Binary 2069 Security considerations: None 2071 Interoperability considerations: None 2073 Published specification: IETF PKIX Working Group Draft on Simple 2074 Certificate Validation Protocol (SCVP) 2076 Applications which use this media type: SCVP servers 2078 Additional information: 2079 Magic number(s): None 2080 File extension(s): .SPP 2081 Macintosh File Type Code(s): none 2083 Person & email address to contact for further information: 2084 Ambarish Malpani 2086 Intended usage: COMMON 2088 Author/Change controller: 2089 Ambarish Malpani 2091 Appendix B -- SCVP over HTTP 2093 This appendix describes the formatting conventions for the SCVP 2094 request and response when carried by HTTP. 2096 B.1 SCVP Request 2098 HTTP based SCVP requests can use the POST method to submit their 2099 requests. Where privacy is a requirement, SCVP transactions 2100 exchanged using HTTP MAY be protected using either TLS/SSL or some 2101 other lower layer protocol. 2103 Malpani, Housley, & Freeman [Page42] 2104 An SCVP request using the POST method is constructed as follows: 2106 The Content-Type header MUST have the value "application/scvp- 2107 request". 2109 The Content-Length header MUST be present and have the exact 2110 length of the request. 2112 The body of the message is the binary value of the DER encoding 2113 of the CVRequest. Other HTTP headers MAY be present and MAY be 2114 ignored if not understood by the requestor. 2116 Sample Content-Type headers are: 2117 Content-Type: application/scvp-request 2119 B.2 SCVP Response 2121 An HTTP-based SCVP response is composed of the appropriate HTTP 2122 headers, followed by the binary value of the DER encoding of the 2123 CVResponse. 2125 The Content-Type header MUST have the value "application/scvp- 2126 response". 2128 The Content-Length header MUST be present and specify the length of 2129 the response. 2131 Other HTTP headers MAY be present and MAY be ignored if not 2132 understood by the requestor. 2134 Appendix C -- Author Contact Information 2136 Ambarish Malpani 2137 Malpani Consulting Services 2138 ambarish@malpani.biz 2140 Russell Housley 2141 Vigil Security, LLC 2142 918 Spring Knoll Drive 2143 Herndon, VA 20170 2144 USA 2145 housley@Vigilsec.com 2147 Trevor Freeman 2148 Microsoft Corporation, 2149 One Microsoft way. 2150 Redmond, WA 98052 2151 USA. 2152 trevorf@microsoft.com 2154 Malpani, Housley, & Freeman [Page43] 2155 Full Copyright Statement 2157 Copyright (C) The Internet Society (2002). All Rights Reserved. 2159 This document and translations of it may be copied and furnished to 2160 others, and derivative works that comment on or otherwise explain it 2161 or assist in its implementation may be prepared, copied, published 2162 and distributed, in whole or in part, without restriction of any 2163 kind, provided that the above copyright notice and this paragraph 2164 are included on all such copies and derivative works. In addition, 2165 the ASN.1 modules presented in Appendices A and B may be used in 2166 whole or in part without inclusion of the copyright notice. 2167 However, this document itself may not be modified in any way, such 2168 as by removing the copyright notice or references to the Internet 2169 Society or other Internet organizations, except as needed for the 2170 purpose of developing Internet standards in which case the 2171 procedures for copyrights defined in the Internet Standards process 2172 shall be followed, or as required to translate it into languages 2173 other than English. 2175 The limited permissions granted above are perpetual and will not be 2176 revoked by the Internet Society or its successors or assigns. This 2177 document and the information contained herein is provided on an "AS 2178 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 2179 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 2180 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 2181 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2182 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2184 Malpani, Housley, & Freeman [Page44]