idnits 2.17.1 draft-ietf-pkix-scvp-05.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 1236 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 8 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 2 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 118: '...ODO: Need to add OPTIONAL variables in...' RFC 2119 keyword, line 131: '...st to the server MUST be a single SCVP...' RFC 2119 keyword, line 132: '...SCVPRequest item MUST be carried in an...' RFC 2119 keyword, line 137: '...server. A server MAY require all reque...' RFC 2119 keyword, line 138: '...a server MAY discard all unsigned requ...' (108 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 55 has weird spacing: '...ier for appli...' ** 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 945 looks like a reference -- Missing reference section? '1' on line 885 looks like a reference -- Missing reference section? '2' on line 886 looks like a reference -- Missing reference section? '0' on line 884 looks like a reference -- Missing reference section? '3' on line 887 looks like a reference -- Missing reference section? '4' on line 821 looks like a reference -- Missing reference section? '5' on line 822 looks like a reference -- Missing reference section? '6' on line 823 looks like a reference -- Missing reference section? 'PKIX' on line 954 looks like a reference -- Missing reference section? 'AC' on line 961 looks like a reference -- Missing reference section? 'OpenPGP' on line 952 looks like a reference -- Missing reference section? 'OCSP' on line 950 looks like a reference -- Missing reference section? 'UTF8' on line 959 looks like a reference -- Missing reference section? 'CMS' on line 948 looks like a reference -- Missing reference section? 'SHA-1' on line 956 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 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-05.txt ValiCert 3 June 2000 Paul Hoffman 4 Expires in six months VPN Consortium 5 Russ Housley 6 RSA Laboratories 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 the 34 certificate, such as whether or not the certificate is valid, a chain 35 to a trusted certificate, and so on. SCVP has many purposes, including 36 simplifying client implementations and allowing companies to centralize 37 their trust and policy managment. 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 name 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 path validation but have no reliable method of obtaining a 51 current chain to a trusted certificate. 53 1.1 SCVP overview and requirements 55 The primary goals of SCVP are to make it easier for applications to 56 deploy systems using a PKI and to allow central administration of 57 PKI policies. Parts of SCVP can be used by clients that do much of the 58 PKI processing themselves and simply want a useful but untrusted server 59 that will collect information for them. Other parts can be used by 60 clients that have complete trust in the server to both offload the work 61 of certificate validation and to ensure that policies are enforced in a 62 consistent fashion across an enterprise. 64 Untrusted SCVP servers can give clients the certification paths needed 65 for certificate path validation. They can also give clients 66 revocation information such as CRLs and OCSP responses that the client 67 can use in the client's path validation. These services can be 68 valuable to client systems that do not include the protocols needed to 69 find and download all of the intermediate certificates, CRLs, and OCSP 70 responses needed for the client to perform complete path validation. 72 Trusted SCVP servers can perform full certificate validation for the 73 client. If a client uses these services, it inherently trusts the SCVP 74 server as much as it would its own path validation software (if it 75 contained such software). There are two main reasons that a client may 76 want to trust such an SCVP server: 78 - The client does not want to incur the overhead of including path 79 validation software and running it for each certificate it receives. 81 - The client is in an enterprise that wants to centralize its PKI 82 validation policies, such as which root certificates are trusted and 83 which types of policy checking are performed during path validation. 85 1.2 Terminology 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [MUSTSHOULD]. 91 1.3 Open Issues 93 The following is a list of issues that were raised on earlier versions 94 of this document that have not been fully dealt with here. Comments on 95 these issues are particularly welcome. 97 - Extensions can be marked as critical. The usefulness and problems of 98 criticality have been long debated and there has not been a great deal 99 of consensus. In SCVP, marking a request extension as critical says to 100 the server "don't give me an answer unless you understand this 101 extension", and marking a response extension as critical says "don't 102 use this response unless you understand this extension". Without the 103 critical bit in the extensions, either the semantics of extensions 104 would have to be changed to essentially say "all extensions are 105 critical" (which is overkill for some extensions that might really be 106 optional), or the semantics would have to be changed to say "you can 107 never rely on the other party understanding an extension", which would 108 limit the usefulness of some extensions. 110 - Need to deal with certificate URLs, where a client doesn't have the 111 certificate, but just a pointer to where the certificate is 112 located. Should we even try and deal with this? 114 - Is there any value to an "unvalidated path"? 116 - Should SCVP support validation of attribute certificates? 118 - TODO: Need to add OPTIONAL variables in the request to be able to 119 control inputs to the path validation algorithm 121 2. Protocol 123 The SCVP protocol uses a simple request-response model. That is, a SCVP 124 client creates a single request and sends it to the server; the server 125 creates a single response and sends it to the client. Typical use of 126 SCVP is expected to be over HTTP, and possibly email. This document 127 registers MIME types for SCVP requests and responses. 129 3. Request 131 A SCVP client's request to the server MUST be a single SCVPRequest 132 item. A SCVPRequest item MUST be carried in an 133 application/scvp-request MIME body part. 135 There are two forms of SCVP request: unsigned and signed. 136 A signed request can be used to authenticate the client to the 137 server. A server MAY require all requests to be signed, and 138 a server MAY discard all unsigned requests. Alternatively, 139 a server MAY choose to process unsigned requests. 141 The unsigned request consists of a PSRequest encapsulated in a 142 ContentInfo. 144 ContentInfo { 145 contentType id-psRequest (TBD1), 146 content PSRequest } 148 The signed request consists of a PSRequest encapsulated in a 149 SignedData which is in turn encapsulated in a ContentInfo. 151 ContentInfo { 152 contentType id-signedData (1.2.840.113549.1.7.2), 153 content SignedData } 155 SignedData { 156 version CMSVersion, 157 digestAlgorithms DigestAlgorithmIdentifiers, 158 encapContentInfo EncapsulatedContentInfo, 159 certificates CertificateSet (Optional), 160 crls CertificateRevocationLists (Optional), 161 signerInfos SignerInfos } 163 SignerInfo { 164 version CMSVersion, 165 sid SignerIdentifier, 166 digestAlgorithm DigestAlgorithmIdentifier, 167 signedAttrs SignedAttributes (Required), 168 signatureAlgorithm SignatureAlgorithmIdentifier, 169 signature SignatureValue, 170 unsignedAttrs UnsignedAttributes (not used in SCVP) } 172 EncapsulatedContentInfo { 173 eContentType id-psRequest (TBD1), 174 eContent PSRequest } 176 3.1 PSRequest 178 The PSRequest item contains the client's request. The PSRequest 179 item contains version, query, typesOfCheck, and wantBack items. It MAY 180 also contain an requestNonce and reqExtensions items. (The "PS" in 181 PSRequest means "possibly signed".) 183 The version item MUST contain the integer one (1). 185 The query item MUST contain a Query. This specification includes only 186 the CertsQuery; however, the use of a CHOICE permits future versions 187 of this protocol to support validation of other objects. 189 The typesOfCheck item MUST contain a sequence of object identifiers. 190 Each object identifier tells the server what types of checking that the 191 client expects the server to perform on the in the query item(s). 193 The wantBack item MUST contain a sequence of object identifiers. Each 194 object identifier tells the server what the client wants to know about 195 the query item(s). 197 The RequestNonce item MAY contain an octet string. If present, the 198 octest string MUST contain an identifier generated by the client for 199 the request. 201 The reqExtensions item MAY contain Extensions. If present, each 202 Extension extends the request. For example, an Extension MAY be used 203 to request a different type of item. 205 The PRRequest MUST have the following syntax: 207 PSRequest ::= SEQUENCE { 208 version INTEGER, 209 query Query, 210 typesOfCheck TypesOfCheck, 211 wantBack WantBack, 212 requestNonce [1] OCTET STRING OPTIONAL, 213 reqExtensions [2] Extensions OPTIONAL 214 } 216 3.2 Version 218 The version item tells the version of SCVP used in a request or a 219 response. The value of the version item MUST be one (1). Updates to 220 this specification will specify other integer values. 222 3.3 Query 224 The Query item specifies the object of the request. One type of object 225 is defined in this specification: CertsQuery. (Other types of queries 226 might be specified in the future.) The CertsQuery is a request for 227 information on one or more certificates. A CertsQuery MUST contain a 228 sequence of one or more certificate. A CertsQuery MAY also contain 229 validityTime, IntermediateCerts, TrustedCerts, RevocationInfo, PolicyID, 230 ConfigurationIdentifier, and QueryExtensions items. Query MUST have 231 the following syntax: 233 Query ::= CHOICE { 234 certsQuery [0] CertsQuery 235 } 237 CertsQuery ::= SEQUENCE { 238 queriedCerts SEQUENCE SIZE (1..MAX) OF Cert, 239 validityTime [0] GeneralizedTime OPTIONAL, 240 intermediateCerts [1] CertBundle OPTIONAL, 241 trustedCerts [2] CertBundle OPTIONAL, 242 revocationInfos [3] SEQUENCE SIZE (1..MAX) OF RevocationInfo OPTIONAL, 243 policyID [4] UTF8String OPTIONAL, 244 configurationIdentifier [5] OBJECT IDENTIFIER OPTIONAL, 245 queryExtensions [6] Extensions OPTIONAL 246 } 248 The list of certificates in the Query item tells the server the 249 certificate(s) for which the client wants a reply. The optional 250 validityTime item tells the date and time relative to which the 251 client wants the server to perform the checks and generate responses. 252 The optional intermediateCerts, trustedCerts, revocationInfos, policyID, 253 and configurationIdentifier items provide context for the client request. 255 [[[Is it valuable to add a URL to a certificate in the query (for 256 wireless applications)? If so, how should that be indicated and how 257 does it change the fields that should be returned?]]] 259 3.4 QueriedCerts 261 The queriedCerts item MUST contain at least one complete certificate. 263 3.5 Cert 265 The Cert item MUST contain an identifier for the type of certificate 266 and the certificate itself. One type of certificate, for PKIX [PKIX], 267 is defined, but other types of certificates (such as attribute 268 certificates [AC] or OpenPGP certificates [OpenPGP]) might be 269 defined in the future. Cert MUST have the following syntax: 271 Cert ::= CHOICE { 272 pkixCert [0] Certificate } 274 3.6 ValidityTime 276 The optional validityTime item tells the date and time relative to which 277 the client wants the server to perform the checks and generate responses. 278 If the validityTime is present, it MUST be encoded as GeneralizedTime. 279 If the validityTime is not present, the server is expected to respond 280 as if the client provided the current date and time. 282 The information in the corresponding CertReply item in the response 283 MUST be formatted as if the server created the response at the time 284 indicated in the validityTime. However, if the server does not have 285 historical information about that time, it MAY either return an error 286 or return information for a later time. A client MUST be prepared to 287 handle responses that contain thisUpdate items that do not match the 288 requested validityTime. 290 3.7 IntermediateCerts 292 The the intermediateCerts item helps the server create valid 293 certification paths. The optional intermediateCerts item provides 294 intermediate certificates that the server MAY use when forming a 295 certification path. The certificates in the intermediateCerts 296 item MAY be used by the server in addition to any other certificates 297 that the server has access to when building certification paths. The 298 intermediateCerts item, if present, MUST contain a list of at least 299 one certificate. The intermediateCerts item MUST be structured as a 300 CertBundle. The certificates in the intermediateCerts MUST NOT 301 be trusted by the server just because they occur in this list. 302 [[IS THE LAST LINE CLEAR?]] 304 3.8 CertBundle 306 The CertBundle item contains one or more Cert. The order of the 307 Cert entries in the bundle are not important. CertBundle MUST have 308 the following syntax: 310 CertBundle ::= SEQUENCE SIZE (1..MAX) OF Cert 312 3.9 TrustedCerts 314 The trustedCerts item optionally specifies the trust anchors to 315 be used by the server. If a trustedCerts item is present, the 316 server MUST NOT use any certification path anchors other than 317 those provided. The trustedCerts item MUST be structured as a 318 CertBundle. 320 3.10 RevocationInfo 322 The revocationInfo item optionally specifies revocation information 323 such as CRLs [PKIX] and OCSP responses [OCSP] that the server MAY 324 use when validating certification paths. The purpose of the 325 revocationInfo item is to provide revocation information to which 326 the server might not otherwise be able to access. For example, an 327 OCSP response that the client received along with the certificate. 328 Note that the information in the revocationInfo item might not be 329 used by the server, such as if the information is for certificates 330 that the server does not use in certification path building. 332 The types of revocation information that can be provided are: a CRL 333 or an OCSP response. 335 RevocationInfo ::= SEQUENCE { 336 riType OBJECT IDENTIFIER, 337 riValue ANY DEFINED BY riType 338 } 340 [[TBD - Obtain OIDs to specify CRL and OCSP in RevocationInfo]] 342 3.11 PolicyID 344 The policyID optional item specifies the policy identifier that the 345 server MUST use when forming a certification path. The policyID item 346 MUST contain the OID that defines the policy. 348 3.12 ConfigurationIdentifier 350 The configurationIdentifier optional item tells the server the SCVP 351 options that the client wants the server to use. The client can use 352 this option instead of specifying other SCVP configuration such as 353 policyID and trustedCerts. The value of this item is determined by 354 private agreement between the client and the server, but it MUST be 355 represented as an OBJECT IDENTIFIER. The server might want to assign 356 identifiers that indicate that some settings are used in addition to 357 others given in the request; in this way, the configuration identifier 358 might be a shorthand for some SCVP options. 360 3.13 QueryExtensions 362 The QueryExtensions item specifies a list of extensions to the SCVP 363 protocol. For example to request additional information about the 364 certificate(s) in the CertsQuery. The QueryExtensions item contains 365 a sequence of Extension items, each of which contain an ExtnID item, 366 a Critical item, and an ExtnValue item. 368 3.14 ExtnID 370 The ExtnID item is an identifier for the extension. It contains 371 the object identifier (OID) of the extension. 373 3.15 Critical 375 The Critical item is a BOOLEAN that tells whether the extension is 376 critical. The values for the item are: 378 FALSE - Not critical 379 TRUE - Critical 381 In a request, if the Critical item is TRUE, the server MUST 382 NOT process the request unless it understands the extension. In a 383 reply, if the Critical item is TRUE, the client MUST NOT process 384 the response unless it understands the extension. 386 3.16 ExtnValue 388 The ExtnValue item contains an OCTET STRING. Within the OCTET 389 STRING is the extension value. An ASN.1 type is specified for 390 each extension (identified by ExtnID). 392 3.17 TypesOfCheck 394 The typesOfCheck item describes the checking that the client wants 395 the server to perform on the certificate(s) in the Query item. If the 396 typesOfCheck item is present in a request, it can contain one or more 397 type of check. For each type of check specified in the request, the 398 server MUST perform all the checks requested, or return an error. 400 The types of checks are: 401 - Build a certification path to a trusted root. 402 - Build a validated certification path to a trusted root. 403 - Do revocation status checks on the certification path. 405 Note that revocation status check inherently includes path construction. 406 Also, building a validated certification path DOES NOT imply revocation 407 status checks (although a server may still choose to do them). 409 The TypesOfCheck MUST have the following syntax: 411 TypesOfCheck ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 413 3.18 WantBack 415 The wantBack item describes the kind of information the client wants 416 from the server for the certificate(s) in the Query item. If the 417 wantBack item is given in a request, it MUST contain one or more types 418 of information. For each type of information specified in the request, 419 the server MUST return information regarding its finding during the 420 check (in a successful response). 422 The types of information that can be requested are: 423 - Certification path built for the certificate 424 - Proof of revocation status 426 For example, a request might include a typesOfCheck item that only 427 specifies certification path building, and include a wantBack item 428 that requests the return of the certification path built by the 429 server. In this case, the response would not include a status for 430 the validation of the certification path, but it would include a 431 certification path that the server considers to be valid. This 432 might be used by a client that wants to perform its own 433 certification path validation. 435 The wantBack MUST have the following syntax: 437 WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 439 3.19 RequestNonce 441 The requestNonce optional item is an identifier generated by the 442 client for the request. If the client includes a requestNonce value, 443 then the server MUST return the same RequestNonce in the signed 444 part of the server's response. The requestNonce item MUST be an 445 OCTET STRING. The client SHOULD include a requestNonce item in 446 every request to prevent an attacker acting as a man-in-the-middle 447 by replaying old responses from the server. The value of the nonce 448 SHOULD change with every request sent from the client. 450 3.20 ReqExtensions 452 The ReqExtensions optional item specifies a list of extensions to 453 the SCVP request. The QueryExtensions item contains a sequence of 454 Extension items, each of which contain an ExtnID item, a Critical 455 item, and an ExtnValue item. 457 4. Response 459 A SCVP server's response to the client MUST be a single SCVPResponse 460 item. A SCVPRequest item is carried in an application/scvp-response MIME 461 body part. 463 There is one forms of SCVP response: signed. The signed response consists 464 of a PSResponse encapsulated in a SignedData which is in turn encapsulated 465 in a ContentInfo. 467 ContentInfo { 468 contentType id-signedData (1.2.840.113549.1.7.2), 469 content SignedData } 471 SignedData { 472 version CMSVersion, 473 digestAlgorithms DigestAlgorithmIdentifiers, 474 encapContentInfo EncapsulatedContentInfo, 475 certificates CertificateSet (Optional), 476 crls CertificateRevocationLists (Optional), 477 signerInfos SignerInfos } 479 SignerInfo { 480 version CMSVersion, 481 sid SignerIdentifier, 482 digestAlgorithm DigestAlgorithmIdentifier, 483 signedAttrs SignedAttributes (Required), 484 signatureAlgorithm SignatureAlgorithmIdentifier, 485 signature SignatureValue, 486 unsignedAttrs UnsignedAttributes (not used in SCVP) } 488 EncapsulatedContentInfo { 489 eContentType id-psResponse (TBD2), 490 eContent PSResponse } 492 4.1 PSResponse 494 The PSResponse item contains the part of the server's response. 495 The PSResponse MUST contain version, producedAt, responseStatus, and 496 requestHash items. The PSResponse MAY also contain replyObjects, 497 requestNonce, and respExtensions optional items. The PSResponse MUST 498 contain exactly one CertReply item for each certificate requested in 499 the request. The requestNonce item MUST be included if the request 500 included a requestNonce item. 502 The PSResponse MUST have the following syntax: 504 PSResponse ::= SEQUENCE { 505 version INTEGER, 506 producedAt GeneralizedTime, 507 responseStatus ResponseStatus, 508 requestHash OCTET STRING, 509 replyObjects [0] ReplyObjects OPTIONAL, 510 requestNonce [1] OCTET STRING OPTIONAL, 511 respExtensions [2] Extensions OPTIONAL 512 } 514 4.2 Version 516 The version item tells the version of SCVP used in a request or a 517 request. The value of the version item MUST be one (1). Updates to 518 this specification will specify other integer values. 520 4.3 ProducedAt 522 The ProducedAt item tells the date and time at which the response was 523 produced. The producedAt item represents the date and time in UTC. 524 The producedAt item MUST be structured as GeneralizedTime. 526 4.3.1 GeneralizedTime 528 The generalized time type, GeneralizedTime, is a standard ASN.1 type 529 for variable precision representation of time. Optionally, the 530 GeneralizedTime field can include a representation of the time 531 differential between local and Greenwich Mean Time. 533 GeneralizedTime values MUST be expressed Greenwich Mean Time (Zulu) 534 and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even where 535 the number of seconds is zero. GeneralizedTime values MUST NOT 536 include fractional seconds. 538 This rule for GeneralizedTime applies to all occurrances of GeneralizedTime 539 in this specification. 541 4.4 ResponseStatus 543 The responseStatus item gives status information to the client about 544 its request. The responseStatus item has a numeric status code and an 545 optional string that is a sequence of characters from the ISO/IEC 546 10646-1 character set encoded with the UTF-8 transformation format 547 defined in [UTF8]. 549 The optional string MAY optionally be used to transmit status 550 information. The client MAY choose to display the string to the 551 human user. However, because there is no way to know the languages 552 understood by the human user, the string may be of little or no use 553 to them. 555 The ResponseStatus MUST have the following syntax: 557 ResponseStatus ::= SEQUENCE { 558 statusCode SCVPStatusCode, 559 errorMessage [0] UTF8String OPTIONAL 560 } 562 SCVPStatusCode ::= ENUMERATED { 563 okay (0), 564 skipUnrecognizedItems (1), 565 tooBusy (10), 566 badStructure (20), 567 unsupportedVersion (21), 568 abortUnrecognizedItems (22), 569 unrecognizedSigKey (23), 570 badSignature (24), 571 unableToDecode (25), 572 notAuthorized (26) 573 } 575 The meaning of the various status codes are: 577 0 The request was fully processable 578 1 The request included unrecognized items; continuing 580 10 Too busy; try again later 582 20 The structure of the request was wrong 583 21 The version of request is not supported by this server 584 22 The request included unrecognized items; aborting 585 23 The key given in the RequestSignature is not recognized 586 24 The signature did not match the body of the request 587 25 The encoding was not understood 588 26 The request was not authorized 589 27 The request included unsupported items; continuing 590 28 The request included unsupported items; aborting 592 4.5 RequestHash 594 The requestHash item is the SHA-1 hash of the PSRequest. The 595 requestHash item serves the following purposes: 597 - It helps a client know that the request was not maliciously modified 598 when the client gets the response back. 600 - It allows the client to associate a response with a request when 601 using connectionless protocols. 603 The purpose of the requestHash item is not for authentication of the 604 client. 606 The server MUST return the requestHash item in the response. 608 4.6 ReplyObjects 610 The replyObjects item returns objects to the client. In this 611 specification, the replyObjects item is always a CertReply, which tells 612 the client about a single certificate from the request. The CertReply 613 item MUST contain cert, replyStatus, and thisUpdate items, and it 614 MAY optionally contain a nextUpdate item. The CertReply MAY also 615 contain the following optional objects: ValidationStatus, 616 RevocationStatus, PublicKey, CertSubject, ValidationChain, 617 RevocationProof, and SingleReplyExtensions. 619 The presence or absence of the ValidationStatus, RevocationStatus, 620 PublicKey, CertSubject, ValidationChain, and RevocationProof objects in 621 the CertReply item is controlled by the TypesOfCheck, and WantBack 622 items in the request. A server MUST include one of the above items for 623 each related item requested in the TypesOfCheck, and WantBack items. 625 ReplyObjects ::= CHOICE { 626 certReplies [0] SEQUENCE SIZE (1..MAX) OF CertReply 627 } 629 CertReply ::= SEQUENCE { 630 cert Cert, 631 replyStatus ReplyStatus, 632 thisUpdate GeneralizedTime, 633 nextUpdate [0] GeneralizedTime OPTIONAL, 634 replyTypesOfCheck [1] Extensions OPTIONAL, 635 replyWantBack [2] Extensions OPTIONAL, 636 singleReplyExtensions [3] Extensions OPTIONAL 637 } 639 4.7 ReplyStatus 641 The ReplyStatus item gives status information to the client about the 642 request for the specific certificate. Note that the ResponseStatus item 643 is different than the ReplyStatus item. The ResponseStatus item is the 644 status of the whole request, while the ReplyStatus item is the status 645 for the individual certificate. 647 The complete list of status codes for the ReplyStatus item is: 649 ReplyStatus ::= ENUMERATED { 650 success (0), 651 certTypeUnrecognized (1), 652 typeOfCheckUnrecognized (2), 653 wantBackUnrecognized (3), 654 certMalformed (4), 655 policyIDUnrecognized (5), 656 configInfoUnrecognized (6), 657 unauthorizedRequest (7) 658 } 660 0 Success: a definitive answer follows 661 1 Failure: the certificate type is not recognized 662 2 Failure: an item wanted in TypesOfCheck is not recognized 663 3 Failure: an item wanted in WantBack is not recognized 664 4 Failure: the certificate was malformed 665 5 Failure: the mandatory PolicyID is not recognized 666 6 Failure: the ConfigurationIdentifier is not recognized 667 7 Failure: unauthorized request 669 Status code 4 is used to tell the client that the request was properly 670 formed but the certificate in question was not. This is useful to 671 clients that cannot parse a certificate. 673 4.8 ThisUpdate 675 The ThisUpdate item tells the time at which the information in the 676 CertReply was correct. The ThisUpdate item represents the date as 677 UTC. 679 4.9 NextUpdate 681 The NextUpdate item tells the time until which the server expects the 682 information in the CertReply to be valid. The NextUpdate item 683 represents the date at UTC. [[[Is there a desire for another item that 684 says "the server takes liability for this response up to this 685 particular time?]]] 687 4.10 ReplyTypesOfCheck 689 The ReplyTypesOfCheck contains the responses to the client's 690 TypesOfCheck item in the request. It has the same form as the 691 Extensions item, and the OIDs in the ReplyTypesOfCheck item MUST match 692 the OIDS in the TypesOfCheck item. The criticality bit MUST NOT be set. 694 The value for path building to a trusted root, {type-arc 0}, can be 695 one of the following: 697 Value Meaning 698 ----- ------- 699 0 Built a path 700 1 Could not build a path 702 The value for path validation to a trusted root, {type-arc 1}, can be 703 one of the following: 705 Value Meaning 706 ----- ------- 707 0 Valid 708 1 Not valid 710 The value for the revocation status, {type-arc 2}, can be one of the 711 following: 713 Value Meaning 714 ----- ------- 715 0 Good 716 1 Revoked 717 2 Unknown 719 4.11 ReplyWantBack 721 The ReplyWantBack contains the responses to the client's WantBack item 722 in the request. It has the same form as the Extensions item, and the 723 OIDs in the ReplyWantBack item MUST match the OIDS in the WantBack 724 item. The criticality bit MUST NOT be set. 726 The value for the certification chain used to verify the certificate 727 in the request, {want-arc 0}, is a CertBundle item. 729 The value for the proof of revocation status, {want-arc 1}, is a 730 RevocationProof item. 732 4.12 RevocationProof 734 The RevocationProof item gives the client the proof that the server 735 used to check revocation. The structure of the RevocationProof item is 736 the same as an Extensions item. The OIDs in the RevocationProof item 737 are the same as those in the RevocationInfo item. 739 4.13 ResponseSignature 741 The ResponseSignature item is the signature of the PSResponse item. 743 The client SHOULD check the signature on every signed message it 744 receives from the server. In order to check the signature, the client 745 MUST know and rely on the public signing key of the server. The client 746 could have obtained the server's public key through an out-of-band 747 mechanism of direct trust or through a certificate that chains to a 748 root that the client trusts to delegate this type of authority. 750 5. ASN.1 Syntax for SCVP 752 This section defines the syntax for SCVP messages. The semantics for 753 the messages are defined in sections 2, 3, and 4. 755 5.1 Signatures in ASN.1 757 Signatures in ASN.1 are done over the DER encoding of the 758 PSRequest/PSResponse item. The Name is the distinguished name of the 759 signer. The SignatureAlgorithm is the 760 algorithm used to sign the request, and a SignatureBits item that is 761 the signature itself. The signature may also contain an 762 optional CertBundle that represents a chain of certs to verify the key used 763 to sign the request. 765 5.1.1 SignatureAlgorithm 767 The SignatureAlgorithm identifies the algorithm used to sign a request 768 or response. The SigningAlgorithm item contains the OID of the 769 algorithm and any necessary parameters for the algorithm. 771 5.1.2 SignatureBits 773 The SignatureBits item holds the octets of a signature. The structure 774 of the SignatureBits item is determined by the value of the 775 SignatureAlgorithm item. 777 5.2 ASN.1 Module definition 779 SCVP DEFINITIONS EXPLICIT TAGS ::= 781 BEGIN 783 IMPORTS 785 -- Directory Authentication Framework (X.509) 786 Certificate, AlgorithmIdentifier 787 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 788 module(1) authenticationFramework(7) 3 } 790 -- CMS Imports 791 ContentInfo, SignedData, CMSVersion, 792 FROM CryptographicMessageSyntax { iso(1) member-body(2) 793 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 794 modules(0) cms(1) } 796 -- PKIX Imports 797 Name, Extensions, 798 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 799 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 800 id-mod(0) id-pkix1-explicit-88(1)}; 802 PSRequest ::= SEQUENCE { 803 version INTEGER, 804 query Query, 805 typesOfCheck TypesOfCheck, 806 wantBack WantBack, 807 requestNonce [1] OCTET STRING OPTIONAL, 808 reqExtensions [2] Extensions OPTIONAL 809 } 811 Query ::= CHOICE { 812 certsQuery [0] CertsQuery 813 } 815 CertsQuery ::= SEQUENCE { 816 queriedCerts SEQUENCE SIZE (1..MAX) OF Cert, 817 validityTime [0] GeneralizedTime OPTIONAL, 818 intermediateCerts [1] CertBundle OPTIONAL, 819 trustedCerts [2] CertBundle OPTIONAL, 820 revocationInfos [3] SEQUENCE SIZE (1..MAX) OF RevocationInfo OPTIONAL, 821 policyID [4] OBJECT IDENTIFIER OPTIONAL, 822 configurationIdentifier [5] OBJECT IDENTIFIER OPTIONAL, 823 queryExtensions [6] Extensions OPTIONAL 824 } 826 CertBundle ::= SEQUENCE SIZE (1..MAX) OF Cert 828 Cert ::= CHOICE { 829 pkixCert [0] Certificate 830 } 832 RevocationInfo ::= SEQUENCE { 833 riType OBJECT IDENTIFIER, 834 riValue ANY DEFINED BY riType 835 } 837 TypesOfCheck ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 839 WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 841 Signature ::= SEQUENCE { 842 signerName Name, 843 signatureAlgorithm AlgorithmIdentifier, 844 signatureBits BIT STRING, 845 certs [0] CertBundle OPTIONAL 846 } 848 PSResponse ::= SEQUENCE { 849 version INTEGER, 850 producedAt GeneralizedTime, 851 responseStatus ResponseStatus, 852 requestHash OCTET STRING, 853 replyObjects [0] ReplyObjects OPTIONAL, 854 requestNonce [1] OCTET STRING OPTIONAL, 855 respExtensions [2] Extensions OPTIONAL 856 } 858 ResponseStatus ::= SEQUENCE { 859 statusCode SCVPStatusCode, 860 errorMessage [0] UTF8String OPTIONAL 861 } 863 SCVPStatusCode ::= ENUMERATED { 864 okay (0), 865 skipUnrecognizedItems (1), 866 tooBusy (10), 867 badStructure (20), 868 unsupportedVersion (21), 869 abortUnrecognizedItems (22), 870 unrecognizedSigKey (23), 871 badSignature (24), 872 unableToDecode (25), 873 notAuthorized (26) 874 } 876 ReplyObjects ::= CHOICE { 877 certReplies [0] SEQUENCE SIZE (1..MAX) OF CertReply 878 } 880 CertReply ::= SEQUENCE { 881 cert Cert, 882 replyStatus ReplyStatus, 883 thisUpdate GeneralizedTime, 884 nextUpdate [0] GeneralizedTime OPTIONAL, 885 replyTypesOfCheck [1] Extensions OPTIONAL, 886 replyWantBack [2] Extensions OPTIONAL, 887 singleReplyExtensions [3] Extensions OPTIONAL 888 } 890 -- The encoding of the value for path validation and revocation status 891 -- will be as an INTEGER 893 ReplyStatus ::= ENUMERATED { 894 success (0), 895 certTypeUnrecognized (1), 896 typeOfCheckUnrecognized (2), 897 wantBackUnrecognized (3), 898 certMalformed (4), 899 policyIDUnrecognized (5), 900 configInfoUnrecognized (6), 901 unauthorizedRequest (7) 902 } 904 -- Need to include type-arc, want-arc, and revinfo-arc 906 id-psRequest OBJECT IDENTIFIER ::= { TBD } 907 id-psResponse OBJECT IDENTIFIER ::= { TBD2 } 909 END 911 6. Security Considerations 913 A client that trusts a server's responses for validation of 914 certificates inherently trusts that server as much as it would trust 915 its own validation software. This means that if an attacker compromises 916 a trusted SCVP server, the attacker can change the validation 917 processing for every client that relies on that server. Thus, an SCVP 918 server must be protected at least as well as the weakest root server 919 that the SCVP server trusts. 921 If the client does not check the signature on the response, a 922 man-in-the-middle attack could fool the client into believing modified 923 responses from the server, or responses to questions the client did not 924 ask. This attack does not affect the usefulness of some responses (such 925 as a response that returns a certification path that the client will 926 validate itself) but does affect things such as a validation response. 928 If the client does not include a RequestNonce item, or if the client 929 does not check that the RequestNonce in the reply matches that in the 930 request, an attacker can replay previous responses from the server. 932 If the server does not require some sort of authorization (such as 933 signed requests), an attacker can get the server to reply to arbitrary 934 requests. Such responses may give the attacker information about 935 weaknesses in the server or about the timeliness of the server's 936 checking. This information may be valuable for a future attack. 938 Clients MUST check the RequestHash in the response and ensure that it 939 matches their original request. Requests contain a lot of information 940 that affects the response and clients need to be very careful that the 941 response is for the request it made. 943 A. References 945 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement 946 Levels", RFC 2119. 948 [CMS] "Cryptographic Message Syntax", RFC 2630. 950 [OCSP] "PKIX Online Certificate Status Protocol (OCSP)", RFC 2560. 952 [OpenPGP] "OpenPGP Message Format", RFC 2440. 954 [PKIX] "PKIX Certificate and CRL Profile", RFC 2459. 956 [SHA-1] "Secure Hash Standard", NIST FIPS publication 180-1, April 957 1995. 959 [UTF8] "UTF-8, a transformation format of ISO 10646", RFC 2279. 961 [AC] NEED THE REFERENCE 963 B. Acknowledgments 965 The lively debate in the PKIX Working Group also had a significant 966 impact on the types of items described in this protocol. Denis Pinkas 967 suggested some additional requirements for the protocol, and Mike Myers 968 helped point out sections that needed clarification. Frank 969 Balluffi and Ameya Talwalkar were responsible for the first 970 implementation and suggestions on a few deficiencies in the document. 972 C. Changes Between Versions of This Document 974 C.1 Difference between -02 and -03 976 1. Changed TBSResponse and TBSRequest to PSResponse and 977 PSRequest. Made signatures optional in both requests and responses. 979 2. Added a tag to the optional signatures in both requests and 980 responses. 982 3. Changed RevocationInfos to RevocationInfo. 984 4. Removed CertHash completely. 986 5. Simplified section 3.5, since FullCert has gone away 988 6. Replaced section 3.6 to talk about Cert, rather than FullCert 990 7. Replaced ExtensionParameter with ExtensionValue in Section 3.11. 992 8. Made sure that all SEQUENCE OF are SEQUENCE SIZE (1..MAX) OF 994 9. Import Extension and used the same definition for Extension as in 995 RFC2459 997 10. Replace "trusted root" with "trusted certificate", because a 998 server or client might decide to put its trust in a certificate that 999 might not be self-signed. Replaced trustedRoot with trustedCert. 1001 11. Fixed once occurance of definition of requestNonce 1003 12. Removed scvp, scvpReq and scvpResp tags in the XML. 1005 13. Removed the last 2 sentences of the second paragraph Section 3.4 1007 14. Changed last sentence of section 3.13, since you have have multiple 1008 cert chains for a certificate even if there is no cross certification. 1010 15. Changed last sentence of section 3.17. 1012 16. Moved section 3.21 to the response section - 4.4a. We need to 1013 renumber all sections when we are close to being done. 1015 17. Added a default value for the attribute value of ReplyStatus in 1016 the XML. 1018 18. Added IMPORTS to the ASN.1 module. 1020 19. Gave the extensions in different places different names. 1022 20. Changed the way criticality is specified for Extension in XML 1024 21. Added the mime type registration requests 1026 22. Added appendix E and moved Author Information to appendix F 1028 23. Moved signerName from the PSRequest and PSResponse to the 1029 signature part. 1031 24. Removed the second paragraph in section 3.13. 1033 25. Changed a line in section 3.14, first para (about where a client 1034 may have obtained an OCSP response to send to the SCVP server). 1036 26. Got rid of the multiple places where we say what is signed by the 1037 RequestSignature or ResponseSignature (e.g. section 3.1 and 3.2). Also 1038 simplified the definition of the RequestSignature and 1039 ResponseSignature in sections 3 and 4. The should be defined in detail 1040 in the encoding sections. 1042 C.2 Difference between -03 and -04 1044 1. Added format information in the http header in Appendix E.1.1 1046 2. Changed the numbers in the want-arc to start with 0 in section 4.10 1048 3. Added error states to indicate that the request contained 1049 unsupported items in section 4.4. 1051 4. Added acknowledgement to Frank Balluffi and Ameya Talwalkar in 1052 Appendix B. 1054 5. Made nextUpdate optional (renumbered tags in CertReply). 1056 6. Specified the criticality bit in ReplyTypesOfCheck and ReplyWantBack 1057 (sections 4.9 and 4.10) 1059 7. Specified the encoding for the replyTypesOfCheck field 1061 8. Renumbered tag fields for PSResponse. 1063 9. Added a TODO to section 3.4 about Cert URLs. 1065 10. Corrected the section on the ConfigurationIdentifier. 1067 11. Modified TypesOfCheck to allow client to request a non-validated 1068 path. 1070 12. Removed an old (unneeded) line in the security section. 1072 C.3 Difference between -04 and -05 1074 1. Removed the XML format of the syntax 1076 2. Used CMS as the base formatting mechanism 1078 3. Changed the format of RevocationInfo 1080 4. Specified rules for GeneralizedTime usage 1082 D. MIME Registrations 1084 D.1 application/scvp-request 1086 To: ietf-types@iana.org 1087 Subject: Registration of MIME media type application/scvp-request 1089 MIME media type name: application 1091 MIME subtype name: scvp-request 1093 Required parameters: format 1095 Optional parameters: None 1097 Encoding considerations: binary 1099 Security considerations: Carries a request for information. This 1100 request may optionally be cryptographically signed. 1102 Interoperability considerations: None 1104 Published specification: IETF PKIX Working Group Draft on Simple 1105 Certificate Validation Protocol - SCVP 1107 Applications which use this media type: SCVP clients 1109 Additional information: 1111 Magic number(s): None 1112 File extension(s): .SCQ 1113 Macintosh File Type Code(s): none 1115 Person & email address to contact for further information: 1116 Ambarish Malpani 1118 Intended usage: COMMON 1120 Author/Change controller: 1121 Ambarish Malpani 1123 D.2 application/scvp-response 1125 To: ietf-types@iana.org 1126 Subject: Registration of MIME media type application/scvp-response 1128 MIME media type name: application 1130 MIME subtype name: scvp-response 1132 Required parameters: format 1134 Optional parameters: None 1136 Encoding considerations: binary 1138 Security considerations: Carries a cryptographically signed response 1140 Interoperability considerations: None 1142 Published specification: IETF PKIX Working Group Draft on Simple 1143 Certificate Validation Protocol - SCVP 1145 Applications which use this media type: SCVP servers 1147 Additional information: 1149 Magic number(s): None 1150 File extension(s): .SCS 1151 Macintosh File Type Code(s): none 1153 Person & email address to contact for further information: 1154 Ambarish Malpani 1156 Intended usage: COMMON 1158 Author/Change controller: 1159 Ambarish Malpani 1161 E. SCVP data format 1163 E.1 SCVP over HTTP 1165 This section describes the formatting that will be done to the 1166 request and response to support HTTP. 1168 E.1.1 Request 1170 HTTP based SCVP requests can use the POST method to 1171 submit their requests. Where privacy is 1172 a requirement, SCVP transactions exchanged using HTTP MAY be 1173 protected using either TLS/SSL or some other lower layer protocol. 1175 An SCVP request using the POST method is constructed as follows: 1176 The Content-Type header MUST have the value 1177 "application/scvp-request". The Content-Length header MUST be 1178 present and have the exact length of the request. The body of the 1179 message is the binary value of the DER encoding of the 1180 FullRequest. Other HTTP headers MAY be present and MAY be ignored 1181 if not understood by the requestor. 1183 Sample Content-Type headers are: 1184 Content-Type: application/scvp-request 1186 E.1.2 Response 1188 An HTTP-based SCVP response is composed of the appropriate HTTP 1189 headers, followed by the binary value of the DER encoding of the 1190 FullResponse. The Content-Type header MUST have the value 1191 "application/scvp-response". The Content-Length header MUST be 1192 present and specify the length of the response. Other HTTP headers 1193 MAY be present and MAY be ignored if not understood by the 1194 requestor. 1196 F. Author Contact Information 1198 Ambarish Malpani 1199 ValiCert, Inc. 1200 339 N. Bernardo Ave. 1201 Mountain View, CA 94043 1202 ambarish@valicert.com 1204 Paul Hoffman 1205 VPN Consortium 1206 127 Segre Place 1207 Santa Cruz, CA 95060 USA 1208 paul.hoffman@vpnc.org 1210 Russell Housley 1211 RSA Laboratories 1212 918 Spring Knoll Drive 1213 Herndon, VA 20170 1214 USA 1215 rhousley@rsasecurity.com