idnits 2.17.00 (12 Aug 2021) /tmp/idnits19528/draft-ietf-pkix-scvp-08.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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 1258 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. ** There are 12 instances of too long lines in the document, the longest one being 27 characters in excess of 72. ** There are 5 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 141: '...ODO: Need to add OPTIONAL variables in...' RFC 2119 keyword, line 172: '...st to the server MUST be a single SCVP...' RFC 2119 keyword, line 173: '...SCVPRequest item MUST be carried in an...' RFC 2119 keyword, line 178: '...server. A server MAY require all reque...' RFC 2119 keyword, line 179: '...a server MAY discard all unsigned requ...' (107 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [MUSTSHOULD], but that reference does not seem to mention RFC 2119 either. -- 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) -- Missing reference section? 'MUSTSHOULD' on line 1034 looks like a reference -- Missing reference section? '1' on line 948 looks like a reference -- Missing reference section? '2' on line 949 looks like a reference -- Missing reference section? '0' on line 947 looks like a reference -- Missing reference section? '3' on line 950 looks like a reference -- Missing reference section? '4' on line 884 looks like a reference -- Missing reference section? '5' on line 885 looks like a reference -- Missing reference section? '6' on line 886 looks like a reference -- Missing reference section? 'PKIX' on line 1043 looks like a reference -- Missing reference section? 'AC' on line 1050 looks like a reference -- Missing reference section? 'OpenPGP' on line 1041 looks like a reference -- Missing reference section? 'OCSP' on line 1039 looks like a reference -- Missing reference section? 'UTF8' on line 1048 looks like a reference -- Missing reference section? 'CMS' on line 1037 looks like a reference -- Missing reference section? 'SHA-1' on line 1045 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Ambarish Malpani 2 draft-ietf-pkix-scvp-08.txt ValiCert, Inc 3 March 2002 Russ Housley 4 Expires in six months RSA Laboratories 5 Trevor 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 all 13 provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 The SCVP protocol allows a client to offload certificate handling to a 33 server. The server can give a variety of valuable information about 34 the certificate, such as whether or not the certificate is valid, a 35 certification path to a trust anchor, and so on. SCVP has many 36 purposes, including simplifying client implementations and allowing 37 companies to centralize their trust and policy management. 39 1. Introduction 41 Certificate validation is a difficult problem. If certificate handling 42 is to be widely deployed in a variety of applications and 43 environments, the amount of processing an application needs to perform 44 before it can accept a certificate must be reduced. There are a 45 variety of applications that can use public key certificates but are 46 burdened by the overhead of validating the certificates when all the 47 application really wants is the public key and identity from the 48 certificate, and a determination of whether or not the certificate may 49 be used for a particular purpose. There are other applications that 50 can perform certification path validation but have no reliable method 51 of constructing a certification path to a trust anchor. 53 1.1 SCVP overview and requirements 55 [Once the DPV & DPD Requirements document passes WG Last Call, this 56 section will be updated to reference that document.] 58 The primary goals of SCVP are to make it easier for applications to 59 deploy systems using a PKI and to allow central administration of 60 PKI policies. Parts of SCVP can be used by clients that do much of the 61 PKI processing themselves and simply want a useful but untrusted server 62 that will collect information for them. Other parts can be used by 63 clients that have complete trust in the server to both offload the work 64 of certificate validation and to ensure that policies are enforced in a 65 consistent fashion across an enterprise. 67 Untrusted SCVP servers can provide clients the certification paths needed 68 for certificate path validation. They can also provide clients 69 revocation information such as CRLs and OCSP responses that the client 70 can use in certification path validation. These services can be 71 valuable to client systems that do not include the protocols needed to 72 find and download all of the intermediate certificates, CRLs, and OCSP 73 responses needed for the client to perform path validation. 75 Trusted SCVP servers can perform full certificate validation for the 76 client. If a client uses these services, it inherently trusts the SCVP 77 server as much as it would its own path validation software (if it 78 contained such software). There are two main reasons that a client may 79 want to trust such an SCVP server: 81 - The client does not want to incur the overhead of including 82 certification path validation software and running it for each 83 certificate it receives. 85 - The client is in an enterprise that wants to centralize its PKI 86 validation policies, such as which trust anchors and which types of 87 policy checking are performed during certification path validation. 89 1.2 Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [MUSTSHOULD]. 95 1.3 Open Issues 97 The following is a list of issues that were raised on earlier versions 98 of this document that have not been fully dealt with here. Comments on 99 these issues are particularly welcome. 101 - Extensions can be marked as critical. The usefulness and problems of 102 criticality have been long debated and there has not been a great deal 103 of consensus. In SCVP, marking a request extension as critical says to 104 the server "don't give me an answer unless you understand this 105 extension", and marking a response extension as critical says "don't 106 use this response unless you understand this extension". Without the 107 critical bit in the extensions, either the semantics of extensions 108 would have to be changed to essentially say "all extensions are 109 critical" (which is overkill for some extensions that might really be 110 optional), or the semantics would have to be changed to say "you can 111 never rely on the other party understanding an extension", which would 112 limit the usefulness of some extensions. 114 - Should we allow another way of specifying trust anchors? If so, it 115 needs to include (1) the trusted issuer name, (2) the trusted public 116 key algorithm, (3) the trusted public key, and (4) optionally, the 117 trusted public key parameters associated with the public key. 119 - Is there any value to an "unvalidated path"? 121 - The structure allows for the validation of other objects, such as 122 attribute certificates, to be easily added as Query CHOICE items. 123 Should we change the name of the protocol to reflect this flexibility? 125 - Can CertBundle contain objects of a different type than the object 126 being queried? For example, if the client wants the server to validate 127 a public key certificate, can the CertBundle contain an attribute 128 certificate? 130 - Can TrustedCerts contain objects of a different type than the object 131 being queried? For example, if, in the future, the client wants the 132 server to validate a attribute certificate, can the CertBundle contain 133 a public key certificate? 135 - Should we require the certReplies SEQUENCE items to be listed in a 136 particular order? 138 - ReplyTypesOfCheck and ReplyWantBack use the Extensions structure. 139 What does the critical bit mean? Should a different structure be used? 141 - TODO: Need to add OPTIONAL variables in the request to be able to 142 control inputs to the path validation algorithm. 144 - TODO: Show how to delegate SCVP signing authority. 146 - TODO: Add extensions to allow client to require server to validate 147 a certificate for a particular context, such as SSL/TLS, S/MIME, or 148 IPsec. 150 - TODO: Allow the response to be unsigned if it is simply reporting 151 an error. Generating malformed requests should not force the server 152 to perform a private key operation. 154 - TODO: Change the structure of RequestHash to be algorithm identifier 155 followed by hash value. This will allow any one-way hash algorithm 156 to be used. 158 - TODO: Explain semantics of thisUpdate and nextUpdate in responses 160 - TODO: Move error codes that apply to the whole request up a level 162 2. Protocol 164 The SCVP protocol uses a simple request-response model. That is, a SCVP 165 client creates a single request and sends it to the server; the server 166 creates a single response and sends it to the client. Typical use of 167 SCVP is expected to be over HTTP, and possibly email. This document 168 registers MIME types for SCVP requests and responses. 170 3. Request 172 A SCVP client request to the server MUST be a single SCVPRequest 173 item. A SCVPRequest item MUST be carried in an 174 application/scvp-request MIME body part. 176 There are two forms of SCVP request: unsigned and signed. 177 A signed request can be used to authenticate the client to the 178 server. A server MAY require all requests to be signed, and 179 a server MAY discard all unsigned requests. Alternatively, 180 a server MAY choose to process unsigned requests. 182 The unsigned request consists of a PSRequest encapsulated in a 183 ContentInfo. 185 ContentInfo { 186 contentType id-ct-scvp-psRequest, 187 -- (1.2.840.113549.1.9.16.1.10) 188 content PSRequest 189 } 191 The signed request consists of a PSRequest encapsulated in a 192 SignedData which is in turn encapsulated in a ContentInfo. 194 ContentInfo { 195 contentType id-signedData, -- (1.2.840.113549.1.7.2) 196 content SignedData 197 } 199 SignedData { 200 version CMSVersion, 201 digestAlgorithms DigestAlgorithmIdentifiers, 202 encapContentInfo EncapsulatedContentInfo, 203 certificates CertificateSet, -- (Optional) 204 crls CertificateRevocationLists, -- (Optional) 205 signerInfos SET OF SignerInfos -- (only one in SCVP) 206 } 208 SignerInfo { 209 version CMSVersion, 210 sid SignerIdentifier, 211 digestAlgorithm DigestAlgorithmIdentifier, 212 signedAttrs SignedAttributes, -- (Required) 213 signatureAlgorithm SignatureAlgorithmIdentifier, 214 signature SignatureValue, 215 unsignedAttrs UnsignedAttributes -- (not used in SCVP) 216 } 218 EncapsulatedContentInfo { 219 eContentType id-ct-scvp-psRequest, 220 -- (1.2.840.113549.1.9.16.1.10) 221 eContent OCTET STRING -- Contains PSRequest 222 } 224 3.1 PSRequest 226 The PSRequest item contains the client request. The PSRequest 227 item contains scvpVersion, query, typesOfCheck, and wantBack items. It MAY 228 also contain an requestNonce and reqExtensions items. (The "PS" in 229 PSRequest means "possibly signed".) 231 The scvpVersion item MUST contain the integer one (1). 233 The query item MUST contain a Query. This specification includes only 234 the CertsQuery; however, the use of a CHOICE permits future versions 235 of this protocol to support validation of other objects. 237 The typesOfCheck item MUST contain a sequence of object identifiers. 238 Each object identifier tells the server what types of checking the 239 client expects the server to perform on the on the query item(s). 241 The wantBack item MUST contain a sequence of object identifiers. Each 242 object identifier tells the server what the client wants to know about 243 the query item(s). 245 The RequestNonce item MAY contain an octet string. If present, the 246 octet string MUST contain an identifier generated by the client for 247 the request. 249 The reqExtensions item MAY contain Extensions. If present, each 250 Extension extends the request. For example, an Extension MAY be used 251 to request a different type of item. 253 The PSRequest MUST have the following syntax: 255 PSRequest ::= SEQUENCE { 256 scvpVersion INTEGER, 257 query Query, 258 typesOfCheck TypesOfCheck, 259 wantBack WantBack, 260 requestNonce [1] OCTET STRING OPTIONAL, 261 reqExtensions [2] Extensions OPTIONAL 262 } 264 3.2 scvpVersion 266 The scvpVersion item tells the version of SCVP used in a request or a 267 response. The value of the scvpVersion item MUST be one (1). Updates to 268 this specification ought to specify other integer values. 270 3.3 Query 272 The Query item specifies the object of the request. One type of object 273 is defined in this specification: CertsQuery. (Other types of queries 274 might be specified in the future.) The CertsQuery is a request for 275 information on one or more certificates. A CertsQuery MUST contain a 276 sequence of one or more certificate. A CertsQuery MAY also contain 277 validityTime, IntermediateCerts, TrustedCerts, RevocationInfo, PolicyID, 278 ConfigurationIdentifier, and QueryExtensions items. Query MUST have 279 the following syntax: 281 Query ::= CHOICE { 282 certsQuery [0] CertsQuery 283 } 285 CertsQuery ::= SEQUENCE { 286 queriedCerts SEQUENCE SIZE (1..MAX) OF Cert, 287 validityTime [0] GeneralizedTime OPTIONAL, 288 intermediateCerts [1] CertBundle OPTIONAL, 289 trustedCerts [2] CertBundle OPTIONAL, 290 revInfos [3] SEQUENCE SIZE (1..MAX) OF RevocationInfo OPTIONAL, 291 policyID [4] OBJECT IDENTIFIER OPTIONAL, 292 configID [5] OBJECT IDENTIFIER OPTIONAL, 293 queryExtensions [6] Extensions OPTIONAL 294 } 296 The list of certificates in the Query item tells the server the 297 certificate(s) for which the client wants a reply. The optional 298 validityTime item tells the date and time relative to which the 299 client wants the server to perform the checks and generate responses. 300 The optional intermediateCerts, trustedCerts, revocationInfos, policyID, 301 and configID items provide context for the client request. 303 3.4 QueriedCerts 305 The queriedCerts item MUST contain at least one certificate. 307 3.5 Cert 309 The Cert item MUST contain an identifier for the type of certificate 310 and the certificate itself. One type of certificate, for the Internet 311 X.509 PKI [PKIX], is defined, but other types of certificates (such as 312 attribute certificates [AC] or OpenPGP certificates [OpenPGP]) might 313 be defined in the future. Cert MUST have the following syntax: 315 Cert ::= CHOICE { 316 pkixCert [0] Certificate } 318 The ASN.1 definition of Certificate is imported from [PKIX]. 320 3.6 ValidityTime 322 The optional validityTime item tells the date and time relative to which 323 the client wants the server to perform the checks and generate responses. 324 If the validityTime is present, it MUST be encoded as GeneralizedTime. 325 If the validityTime is not present, the server MUST respond as if the 326 client provided the at which the server processes the request. 328 The information in the corresponding CertReply item in the response 329 MUST be formatted as if the server created the response at the time 330 indicated in the validityTime. However, if the server does not have 331 historical information about that time, it MAY either return an error 332 or return information for a later time. A client MUST be prepared to 333 handle responses that contain thisUpdate items that do not match the 334 requested validityTime. 336 3.7 IntermediateCerts 338 The intermediateCerts item helps the server create valid 339 certification paths. The intermediateCerts item, when present, provides 340 certificates that the server MAY use when forming a 341 certification path. The certificates in the intermediateCerts 342 item MAY be used by the server in addition to any other certificates 343 that the server has access to when building certification paths. The 344 intermediateCerts item, when present, MUST contain at least 345 one certificate. The intermediateCerts item MUST be structured as a 346 CertBundle. The certificates in the intermediateCerts MUST NOT 347 be trusted by the server just because they are present in this item. 349 3.8 CertBundle 351 The CertBundle item contains one or more Cert. The order of the 352 Cert entries in the bundle is not important. CertBundle MUST have 353 the following syntax: 355 CertBundle ::= SEQUENCE SIZE (1..MAX) OF Cert 357 3.9 TrustedCerts 359 The trustedCerts item optionally specifies the trust anchors to 360 be used by the server. If a trustedCerts item is present, the 361 server MUST NOT use any certification path anchors other than 362 those provided. The trustedCerts item MUST be structured as a 363 CertBundle. 365 3.10 RevocationInfo 367 The revInfo item optionally specifies revocation information 368 such as CRLs [PKIX] and OCSP responses [OCSP] that the server MAY 369 use when validating certification paths. The purpose of the 370 revInfo item is to provide revocation information to which 371 the server might not otherwise have access (for example, an 372 OCSP response that the client received along with the certificate). 373 Note that the information in the revInfo item might not be 374 used by the server, such as if the information is for certificates 375 that the server does not use in certification path building. 377 The types of revocation information that can be provided are: a CRL 378 or an OCSP response. 380 RevocationInfo ::= SEQUENCE { 381 riType OBJECT IDENTIFIER, 382 riValue ANY DEFINED BY riType } 384 The object identifiers for riType for CRLs and OCSP are id-ri-crl and 385 id-ri-ocsp-response, respectively. 387 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 388 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 390 id-ri OBJECT IDENTIFIER ::= { id-pkix 16 } 392 id-ri-crl OBJECT IDENTIFIER ::= { id-ri 1 } 394 id-ri-ocsp-response OBJECT IDENTIFIER ::= { id-ri 2 } 396 3.11 PolicyID 398 The policyID optional item specifies the policy identifier that the 399 server MUST use when forming a certification path. The policyID item 400 MUST contain the OID that defines the policy. 402 3.12 ConfigID 404 The configID item, when present, tells the server the SCVP 405 options that the client wants the server to use. The client can use 406 this option instead of specifying other SCVP configuration items such as 407 policyID and trustedCerts. The value of this item is determined by 408 private agreement between the client and the server, but it MUST be 409 represented as an OBJECT IDENTIFIER. The server might want to assign 410 identifiers that indicate that some settings are used in addition to 411 others given in the request; in this way, the configuration identifier 412 might be a shorthand for some SCVP options, but not others. 414 3.13 QueryExtensions 416 The QueryExtensions item specifies a list of extensions to the SCVP 417 protocol. For example, a client might request additional information 418 about the certificate(s) in the CertsQuery. The QueryExtensions item, 419 when present, contains a sequence of Extension items, each of which 420 contains an ExtnID item, a Critical item, and an ExtnValue item. 422 The syntax for Extensions is imported from [PKIX]. 424 3.14 ExtnID 426 The ExtnID item is an identifier for the extension. It contains 427 the object identifier (OID) of the extension. 429 3.15 Critical 431 The Critical item is a BOOLEAN that tells whether the extension is 432 critical. The values for the item are: 434 FALSE - Not critical 435 TRUE - Critical 437 In a request, if the Critical item is TRUE, the server MUST 438 NOT process the request unless it understands the extension. In a 439 reply, if the Critical item is TRUE, the client MUST NOT process 440 the response unless it understands the extension. 442 3.16 ExtnValue 444 The ExtnValue item contains an OCTET STRING. Within the OCTET 445 STRING is the extension value. An ASN.1 type is specified for 446 each extension (identified by ExtnID). 448 3.17 TypesOfCheck 450 The typesOfCheck item describes the checking that the client wants 451 the server to perform on the certificate(s) in the Query item. If the 452 typesOfCheck item is present in a request, it can contain one or more 453 types of check. For each type of check specified in the request, the 454 server MUST perform all the checks requested, or return an error. 456 The types of checks are: 457 - Build a certification path to a trusted root. 458 - Build a validated certification path to a trusted root. 459 - Do revocation status checks on the certification path. 461 Note that revocation status check inherently includes path construction. 462 Also, building a validated certification path does not imply revocation 463 status checks (although a server may still choose to perform them). 465 The TypesOfCheck MUST have the following syntax: 467 TypesOfCheck ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 469 id-stc OBJECT IDENTIFIER ::= { id-pkix 17 } 471 id-stc-build-path OBJECT IDENTIFIER ::= { id-stc 1 } 473 id-stc-build-valid-path OBJECT IDENTIFIER ::= { id-stc 2 } 475 id-stc-build-valid-status-checked-path 476 OBJECT IDENTIFIER ::= { id-stc 3 } 478 3.18 WantBack 480 The wantBack item describes the kind of information the client wants 481 from the server for the certificate(s) in the Query item. If the 482 wantBack item is present in a request, it MUST contain one or more types 483 of information. For each type of information specified in the request, 484 the server MUST return information regarding its finding during the 485 check (in a successful response). 487 The types of information that can be requested are: 488 - Certification path built for the certificate 489 - Proof of revocation status 491 For example, a request might include a typesOfCheck item that only 492 specifies certification path building, and include a wantBack item 493 that requests the return of the certification path built by the 494 server. In this case, the response would not include a status for 495 the validation of the certification path, but it would include a 496 certification path that the server considers to be valid. This 497 might be used by a client that wants to perform its own 498 certification path validation. 500 The wantBack MUST have the following syntax: 502 WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 504 id-swb OBJECT IDENTIFIER ::= { id-pkix 18 } -- SCVP want back types 505 id-swb-cert-path OBJECT IDENTIFIER ::= { id-swb 1 } 506 want-arc-status ::= {want-arc 1} 507 id-swb-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 } 509 3.19 RequestNonce 511 The requestNonce optional item is an identifier generated by the 512 client for the request. If the client includes a requestNonce value, 513 then the server MUST return the same RequestNonce in the response. The requestNonce item MUST be an 514 OCTET STRING. The client SHOULD include a requestNonce item in 515 every request to prevent an attacker acting as a man-in-the-middle 516 by replaying old responses from the server. The value of the nonce 517 SHOULD change with every request sent from the client. 519 3.20 ReqExtensions 521 The ReqExtensions optional item specifies a list of extensions to 522 the SCVP request. The ReqExtensions item contains a sequence of 523 Extension items, each of which contains an ExtnID item, a Critical 524 item, and an ExtnValue item. 526 4. Response 528 A SCVP server response to the client MUST be a single SCVPResponse 529 item. A SCVPRequest item is carried in an application/scvp-response MIME 530 body part. 532 There are two forms of an SCVP response: unsigned and signed. An unsigned 533 may only be generated for an error status. 535 An unsigned response is as follows: 537 ContentInfo { 538 contentType id-ct-scvp-psResponse, 539 -- (1.2.840.113549.1.9.16.1.11) 540 content PSResponse 541 } 543 The signed response consists 544 of a PSResponse encapsulated in a SignedData which is in turn encapsulated 545 in a ContentInfo. 547 ContentInfo { 548 contentType id-signedData, -- (1.2.840.113549.1.7.2) 549 content SignedData 550 } 552 SignedData { 553 version CMSVersion, 554 digestAlgorithms DigestAlgorithmIdentifiers, 555 encapContentInfo EncapsulatedContentInfo, 556 certificates CertificateSet, -- (Optional) 557 crls CertificateRevocationLists, -- (Optional) 558 signerInfos SET OF SignerInfos -- Only 1 in SCVP 559 } 561 SignerInfo { 562 version CMSVersion, 563 sid SignerIdentifier, 564 digestAlgorithm DigestAlgorithmIdentifier, 565 signedAttrs SignedAttributes, -- (Required) 566 signatureAlgorithm SignatureAlgorithmIdentifier, 567 signature SignatureValue, 568 unsignedAttrs UnsignedAttributes -- (not used in SCVP) 569 } 571 EncapsulatedContentInfo { 572 eContentType id-ct-scvp-psResponse, 573 -- (1.2.840.113549.1.9.16.1.11) 574 eContent OCTET STRING -- Contains PSResponse 575 } 577 4.1 PSResponse 579 The PSResponse item contains the server response. The PSResponse 580 MUST contain scvpVersion, producedAt, responseStatus, and requestHash 581 items. The PSResponse MAY also contain replyObjects, requestNonce, and 582 respExtensions optional items. The PSResponse MUST contain exactly one 583 CertReply item for each certificate requested in the request. The 584 requestNonce item MUST be included if the request included a 585 requestNonce item. 587 The PSResponse MUST have the following syntax: 589 PSResponse ::= SEQUENCE { 590 scvpVersion INTEGER, 591 producedAt GeneralizedTime, 592 responseStatus ResponseStatus, 593 requestHash OCTET STRING, 594 replyObjects [0] ReplyObjects OPTIONAL, 595 requestNonce [1] OCTET STRING OPTIONAL, 596 respExtensions [2] Extensions OPTIONAL 597 } 599 4.2 scvpVersion 601 See section 3.2. 603 4.3 ProducedAt 605 The ProducedAt item tells the date and time at which the response was 606 produced by the server. The producedAt item represents the date and 607 time in UTC. The producedAt item MUST be structured as 608 GeneralizedTime. 610 4.3.1 GeneralizedTime 612 The generalized time type, GeneralizedTime, is a standard ASN.1 type 613 for variable precision representation of time. Optionally, the 614 GeneralizedTime field can include a representation of the time 615 differential between local and Greenwich Mean Time. 617 GeneralizedTime values MUST be expressed Greenwich Mean Time (Zulu) 618 and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even where 619 the number of seconds is zero. GeneralizedTime values MUST NOT 620 include fractional seconds. 622 This rule for GeneralizedTime applies to all occurrences of GeneralizedTime 623 in this specification and is the same as the rule used in certificate 624 profiles [PKIX]. 626 4.4 ResponseStatus 628 The responseStatus item gives status information to the client about 629 its request. The responseStatus item has a numeric status code and an 630 optional string that is a sequence of characters from the ISO/IEC 631 10646-1 character set encoded with the UTF-8 transformation format 632 defined in [UTF8]. 634 The optional string MAY optionally be used to transmit status 635 information. The client MAY choose to display the string to the 636 human user. However, because there is no way to know the languages 637 understood by the human user, the string may be of little or no use 638 to them. 640 The ResponseStatus MUST have the following syntax: 642 ResponseStatus ::= SEQUENCE { 643 statusCode SCVPStatusCode, 644 errorMessage [0] UTF8String OPTIONAL 645 } 647 SCVPStatusCode ::= ENUMERATED { 648 okay (0), 649 skipUnrecognizedItems (1), 650 tooBusy (10), 651 badStructure (20), 652 unsupportedVersion (21), 653 abortUnrecognizedItems (22), 654 unrecognizedSigKey (23), 655 badSignature (24), 656 unableToDecode (25), 657 notAuthorized (26) 658 } 660 The meaning of the various status codes are: 662 0 The request was fully processed 663 1 The request included unrecognized items; continuing 665 10 Too busy; try again later 667 20 The structure of the request was wrong 668 21 The version of request is not supported by this server 669 22 The request included unrecognized items; aborting 670 23 The key given in the RequestSignature is not recognized 671 24 The signature did not match the body of the request 672 25 The encoding was not understood 673 26 The request was not authorized 674 27 The request included unsupported items; continuing 675 28 The request included unsupported items; aborting 677 4.5 RequestHash 679 The requestHash item is the SHA-1 hash of the PSRequest. The 680 requestHash item serves the following purposes: 682 - It allows a client to determine that the request was not maliciously 683 modified. 685 - It allows the client to associate a response with a request when 686 using connectionless protocols. (Although, the RequestNonce provides 687 a better mechanism for matching requests and responses.) 689 The requestHash item does not provide authentication. 691 4.6 ReplyObjects 693 The replyObjects item returns objects to the client. In this 694 specification, the replyObjects item is always a certReplies, which is 695 a SEQUENCE of CertReply, each of which tells the client about a single 696 certificate from the request. The CertReply item MUST contain cert, 697 replyStatus, and thisUpdate items, and it MAY contain a 698 nextUpdate item. The CertReply MAY also contain the following optional 699 objects: ValidationStatus, RevocationStatus, PublicKey, CertSubject, 700 ValidationChain, RevocationProof, and SingleReplyExtensions. 702 The presence or absence of the ValidationStatus, RevocationStatus, 703 PublicKey, CertSubject, ValidationChain, and RevocationProof objects in 704 the CertReply item is controlled by the TypesOfCheck, and WantBack 705 items in the request. A server MUST include one of the above items for 706 each related item requested in the TypesOfCheck, and WantBack items. 708 ReplyObjects ::= CHOICE { 709 certReplies [0] SEQUENCE SIZE (1..MAX) OF CertReply 710 } 712 CertReply ::= SEQUENCE { 713 cert Cert, 714 replyStatus ReplyStatus, 715 thisUpdate GeneralizedTime, 716 nextUpdate [0] GeneralizedTime OPTIONAL, 717 replyTypesOfCheck [1] Extensions OPTIONAL, 718 replyWantBack [2] Extensions OPTIONAL, 719 singleReplyExtensions [3] Extensions OPTIONAL 720 } 722 4.7 ReplyStatus 724 The ReplyStatus item gives status information to the client about the 725 request for the specific certificate. Note that the ResponseStatus item 726 is different than the ReplyStatus item. The ResponseStatus item is the 727 status of the whole request, while the ReplyStatus item is the status 728 for the individual query item. 730 The complete list of status codes for the ReplyStatus item is: 732 ReplyStatus ::= ENUMERATED { 733 success (0), 734 certTypeUnrecognized (1), 735 typeOfCheckUnrecognized (2), 736 wantBackUnrecognized (3), 737 certMalformed (4), 738 policyIDUnrecognized (5), 739 configInfoUnrecognized (6), 740 unauthorizedRequest (7) 741 } 743 The ReplyStatus codes have the following meaning: 745 0 Success: a definitive answer follows 746 1 Failure: the certificate type is not recognized 747 2 Failure: an item wanted in TypesOfCheck is not recognized 748 3 Failure: an item wanted in WantBack is not recognized 749 4 Failure: the certificate was malformed 750 5 Failure: the mandatory PolicyID is not recognized 751 6 Failure: the ConfigurationIdentifier is not recognized 752 7 Failure: unauthorized request 754 Status code 4 is used to tell the client that the request was properly 755 formed but the certificate in question was not. This is useful to 756 clients that cannot parse a certificate. 758 4.8 ThisUpdate 760 The ThisUpdate item tells the time at which the information in the 761 CertReply was correct. The ThisUpdate item represents the date as 762 UTC. 764 4.9 NextUpdate 766 The NextUpdate item tells the time at which the server expects 767 additional information regarding the validity of the certificate to 768 become available. Such information could change the status of the 769 certificate, but it might not change the status of the 770 certificate. The NextUpdate item represents the date at UTC. 772 4.10 ReplyTypesOfCheck 774 The ReplyTypesOfCheck contains the responses to the TypesOfCheck item 775 in the request. It has the same form as the Extensions item, and the 776 OIDs in the ReplyTypesOfCheck item MUST match the OIDS in the 777 TypesOfCheck item. The criticality bit MUST NOT be set. 779 The value for path building to a trusted root, {type-arc 0}, can be 780 one of the following: 782 Value Meaning 783 ----- ------- 784 0 Built a path 785 1 Could not build a path 787 The value for path validation to a trusted root, {type-arc 1}, can be 788 one of the following: 790 Value Meaning 791 ----- ------- 792 0 Valid 793 1 Not valid 795 The value for the revocation status, {type-arc 2}, can be one of the 796 following: 798 Value Meaning 799 ----- ------- 800 0 Good 801 1 Revoked 802 2 Unknown 804 4.11 ReplyWantBack 806 The ReplyWantBack contains the responses to the WantBack item 807 in the request. It has the same form as the Extensions item, and the 808 OIDs in the ReplyWantBack item MUST match the OIDS in the WantBack 809 item. The criticality bit MUST NOT be set. 811 The value for the certification chain used to verify the certificate 812 in the request, {want-arc 0}, is a CertBundle item. 814 The value for the proof of revocation status, {want-arc 1}, is a 815 RevocationProof item. 817 4.12 RevocationProof 819 The RevocationProof item gives the client the proof that the server 820 used to check revocation. The structure of the RevocationProof item is 821 the same as an Extensions item. The OIDs in the RevocationProof item 822 are the same as those in the RevocationInfo item. 824 4.13 ResponseSignature 826 The ResponseSignature item is the signature of the PSResponse item. 828 The client SHOULD check the signature on every signed message it 829 receives from the server. In order to check the signature, the client 830 MUST know and rely on the public signing key of the server. The client 831 could have obtained the server's public key through an out-of-band 832 mechanism of direct trust or through a certificate that chains to a 833 root that the client trusts to delegate this type of authority. 835 5. ASN.1 Syntax for SCVP 837 This section defines the syntax for SCVP messages. The semantics for 838 the messages are defined in sections 2, 3, and 4. 840 5.1 ASN.1 Module definition 842 SCVP DEFINITIONS EXPLICIT TAGS ::= 844 BEGIN 846 IMPORTS 848 -- Directory Authentication Framework (X.509) 849 Certificate, AlgorithmIdentifier 850 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 851 module(1) authenticationFramework(7) 3 } 853 -- CMS Imports 854 ContentInfo, SignedData, CMSVersion, 855 FROM CryptographicMessageSyntax { iso(1) member-body(2) 856 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 857 modules(0) cms(1) } 859 -- PKIX Imports 860 Name, Extensions, 861 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 862 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 863 id-mod(0) id-pkix1-explicit-88(1)}; 865 PSRequest ::= SEQUENCE { 866 scvpVersion INTEGER, 867 query Query, 868 typesOfCheck TypesOfCheck, 869 wantBack WantBack, 870 requestNonce [1] OCTET STRING OPTIONAL, 871 reqExtensions [2] Extensions OPTIONAL 872 } 874 Query ::= CHOICE { 875 certsQuery [0] CertsQuery 876 } 878 CertsQuery ::= SEQUENCE { 879 queriedCerts SEQUENCE SIZE (1..MAX) OF Cert, 880 validityTime [0] GeneralizedTime OPTIONAL, 881 intermediateCerts [1] CertBundle OPTIONAL, 882 trustedCerts [2] CertBundle OPTIONAL, 883 revocationInfos [3] SEQUENCE SIZE (1..MAX) OF RevocationInfo OPTIONAL, 884 policyID [4] OBJECT IDENTIFIER OPTIONAL, 885 configurationIdentifier [5] OBJECT IDENTIFIER OPTIONAL, 886 queryExtensions [6] Extensions OPTIONAL 887 } 889 CertBundle ::= SEQUENCE SIZE (1..MAX) OF Cert 891 Cert ::= CHOICE { 892 pkixCert [0] Certificate 893 } 895 RevocationInfo ::= SEQUENCE { 896 riType OBJECT IDENTIFIER, 897 riValue ANY DEFINED BY riType 898 } 900 TypesOfCheck ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 902 WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 904 Signature ::= SEQUENCE { 905 signerName Name, 906 signatureAlgorithm AlgorithmIdentifier, 907 signatureBits BIT STRING, 908 certs [0] CertBundle OPTIONAL 909 } 911 PSResponse ::= SEQUENCE { 912 scvpVersion INTEGER, 913 producedAt GeneralizedTime, 914 responseStatus ResponseStatus, 915 requestHash OCTET STRING, 916 replyObjects [0] ReplyObjects OPTIONAL, 917 requestNonce [1] OCTET STRING OPTIONAL, 918 respExtensions [2] Extensions OPTIONAL 919 } 921 ResponseStatus ::= SEQUENCE { 922 statusCode SCVPStatusCode, 923 errorMessage [0] UTF8String OPTIONAL 924 } 926 SCVPStatusCode ::= ENUMERATED { 927 okay (0), 928 skipUnrecognizedItems (1), 929 tooBusy (10), 930 badStructure (20), 931 unsupportedVersion (21), 932 abortUnrecognizedItems (22), 933 unrecognizedSigKey (23), 934 badSignature (24), 935 unableToDecode (25), 936 notAuthorized (26) 937 } 939 ReplyObjects ::= CHOICE { 940 certReplies [0] SEQUENCE SIZE (1..MAX) OF CertReply 941 } 943 CertReply ::= SEQUENCE { 944 cert Cert, 945 replyStatus ReplyStatus, 946 thisUpdate GeneralizedTime, 947 nextUpdate [0] GeneralizedTime OPTIONAL, 948 replyTypesOfCheck [1] Extensions OPTIONAL, 949 replyWantBack [2] Extensions OPTIONAL, 950 singleReplyExtensions [3] Extensions OPTIONAL 951 } 953 -- The encoding of the value for path validation and revocation status 954 -- will be as an INTEGER 956 ReplyStatus ::= ENUMERATED { 957 success (0), 958 certTypeUnrecognized (1), 959 typeOfCheckUnrecognized (2), 960 wantBackUnrecognized (3), 961 certMalformed (4), 962 policyIDUnrecognized (5), 963 configInfoUnrecognized (6), 964 unauthorizedRequest (7) 965 } 967 -- OIDs 969 id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2) 970 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 971 ct(1) } 973 id-psRequest OBJECT IDENTIFIER ::= { id-ct 10 } 974 id-psResponse OBJECT IDENTIFIER ::= { id-ct 11 } 976 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 977 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 978 id-ri OBJECT IDENTIFIER ::= { id-pkix 16 } -- revocation 979 -- information types 981 id-ri-crl OBJECT IDENTIFIER ::= { id-ri 1 } 982 id-ri-ocsp-response OBJECT IDENTIFIER ::= { id-ri 2 } 984 id-stc OBJECT IDENTIFIER ::= { id-pkix 17 } -- SCVP check type arc} 985 id-stc-build-path OBJECT IDENTIFIER ::= { id-stc 1 } 987 id-stc-build-valid-path OBJECT IDENTIFIER ::= { id-stc 2 } 988 id-stc-build-valid-status-checked-path 989 OBJECT IDENTIFIER ::= { id-stc 3 } 991 id-swb OBJECT IDENTIFIER ::= { id-pkix 18 } -- SCVP want back types 992 id-swb-cert-path OBJECT IDENTIFIER ::= { id-swb 1 } 993 want-arc-status ::= {want-arc 1} 994 id-swb-revocation-info OBJECT IDENTIFIER ::= { id-swb 2 } 996 END 998 6. Security Considerations 1000 A client that trusts a server's response for validation of a 1001 certificate inherently trusts that server as much as it would trust 1002 its own validation software. This means that if an attacker 1003 compromises a trusted SCVP server, the attacker can change the 1004 validation processing for every client that relies on that 1005 server. Thus, an SCVP server must be protected at least as well as the 1006 trust anchors that the SCVP server trusts. 1008 Clients MUST check the RequestHash in the response and ensure that it 1009 matches their original request. Requests contain a lot of information 1010 that affects the response and clients need to ensure that the server 1011 response corresponds to the expected request. 1013 When the SCVP response is used to determine the validity of a 1014 certificate, the client MUST validate the signature on the response 1015 to ensure that it was generated by the expected SCVP server.If the 1016 client does not check the signature on the response, a 1017 man-in-the-middle attack could fool the client into believing modified 1018 responses from the server, or responses to questions the client did not 1019 ask. 1021 If the client does not include a RequestNonce item, or if the client 1022 does not check that the RequestNonce in the reply matches that in the 1023 request, an attacker can replay previous responses from the server. 1024 [This is not true if the request hash is used as a nonce by the client.] 1026 If the server does not require some sort of authorization (such as 1027 signed requests), an attacker can get the server to reply to arbitrary 1028 requests. Such responses may give the attacker information about 1029 weaknesses in the server or about the timeliness of the server's 1030 checking. This information may be valuable for a future attack. 1032 A. References 1034 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement 1035 Levels", RFC 2119. 1037 [CMS] "Cryptographic Message Syntax", RFC 2630. 1039 [OCSP] "PKIX Online Certificate Status Protocol (OCSP)", RFC 2560. 1041 [OpenPGP] "OpenPGP Message Format", RFC 2440. 1043 [PKIX] "PKIX Certificate and CRL Profile", RFC 2459. 1045 [SHA-1] "Secure Hash Standard", NIST FIPS publication 180-1, April 1046 1995. 1048 [UTF8] "UTF-8, a transformation format of ISO 10646", RFC 2279. 1050 [AC] NEED THE REFERENCE 1052 B. Acknowledgments 1054 The lively debate in the PKIX Working Group also had a significant 1055 impact on the types of items described in this protocol. Denis Pinkas 1056 suggested some additional requirements for the protocol, and Mike Myers 1057 helped point out sections that needed clarification. Frank 1058 Balluffi and Ameya Talwalkar were responsible for the first 1059 implementation and suggestions on a few deficiencies in the document. 1060 John Thielens and Peter Sylvester provided a lot of good input 1061 to help improve this document. 1063 C. MIME Registrations 1065 C.1 application/scvp-request 1067 To: ietf-types@iana.org 1068 Subject: Registration of MIME media type application/scvp-request 1070 MIME media type name: application 1072 MIME subtype name: scvp-request 1074 Required parameters: format 1076 Optional parameters: None 1078 Encoding considerations: binary 1080 Security considerations: Carries a request for information. This 1081 request may optionally be cryptographically signed. 1083 Interoperability considerations: None 1085 Published specification: IETF PKIX Working Group Draft on Simple 1086 Certificate Validation Protocol - SCVP 1088 Applications which use this media type: SCVP clients 1090 Additional information: 1092 Magic number(s): None 1093 File extension(s): .SCQ 1094 Macintosh File Type Code(s): none 1096 Person & email address to contact for further information: 1097 Ambarish Malpani 1099 Intended usage: COMMON 1101 Author/Change controller: 1102 Ambarish Malpani 1104 C.2 application/scvp-response 1106 To: ietf-types@iana.org 1107 Subject: Registration of MIME media type application/scvp-response 1109 MIME media type name: application 1111 MIME subtype name: scvp-response 1113 Required parameters: format 1115 Optional parameters: None 1117 Encoding considerations: binary 1119 Security considerations: Carries a cryptographically signed response 1121 Interoperability considerations: None 1123 Published specification: IETF PKIX Working Group Draft on Simple 1124 Certificate Validation Protocol - SCVP 1126 Applications which use this media type: SCVP servers 1128 Additional information: 1130 Magic number(s): None 1131 File extension(s): .SCS 1132 Macintosh File Type Code(s): none 1134 Person & email address to contact for further information: 1135 Ambarish Malpani 1137 Intended usage: COMMON 1139 Author/Change controller: 1140 Ambarish Malpani 1142 D. SCVP over HTTP 1144 This section describes the formatting that will be done to the 1145 request and response to support HTTP. 1147 D.1 Request 1149 HTTP based SCVP requests can use the POST method to 1150 submit their requests. Where privacy is 1151 a requirement, SCVP transactions exchanged using HTTP MAY be 1152 protected using either TLS/SSL or some other lower layer protocol. 1154 An SCVP request using the POST method is constructed as follows: 1155 The Content-Type header MUST have the value 1156 "application/scvp-request". The Content-Length header MUST be 1157 present and have the exact length of the request. The body of the 1158 message is the binary value of the DER encoding of the 1159 FullRequest. Other HTTP headers MAY be present and MAY be ignored 1160 if not understood by the requestor. 1162 Sample Content-Type headers are: 1163 Content-Type: application/scvp-request 1165 D.2 Response 1167 An HTTP-based SCVP response is composed of the appropriate HTTP 1168 headers, followed by the binary value of the DER encoding of the 1169 FullResponse. The Content-Type header MUST have the value 1170 "application/scvp-response". The Content-Length header MUST be 1171 present and specify the length of the response. Other HTTP headers 1172 MAY be present and MAY be ignored if not understood by the 1173 requestor. 1175 E. Author Contact Information 1177 Ambarish Malpani 1178 ValiCert, Inc. 1179 339 N. Bernardo Ave. 1180 Mountain View, CA 94043 1181 ambarish@valicert.com 1183 Russell Housley 1184 RSA Laboratories 1185 918 Spring Knoll Drive 1186 Herndon, VA 20170 1187 USA 1188 rhousley@rsasecurity.com 1190 Trevor Freeman 1191 Microsoft Corporation, 1192 One Microsoft way 1193 Redmond, WA98052 1194 trevorf@microsoft.com 1196 F. Changes Between Versions of This Document 1198 F.1 Difference between -04 and -05 1200 1. Removed the XML format of the syntax 1202 2. Used CMS as the base formatting mechanism 1204 3. Changed the format of RevocationInfo 1206 4. Specified rules for GeneralizedTime usage 1208 5. Added a question about the benefit of other types of authentication 1209 of responses (not just signatures). 1211 F.2 Differences between -05 and -06 1213 1. Added authors 1215 2. Fixed language and spelling mistakes 1217 3. Changed version to scvpVersion 1219 F.3 Differences between -06 and -07 1221 1. Updated authors list 1223 2. Closed open issue of whether we should deal with cases where the 1224 client doesn't have the certificate itself 1226 3. Added text for different types of request and wantbacks 1228 4. Allow for unsigned error responses 1230 5. Moved changes to the end and renumbered sections 1232 6. Added some OIDs that were TBD