idnits 2.17.00 (12 Aug 2021) /tmp/idnits12725/draft-ietf-pkix-scvp-04.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 1448 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 7 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** There is 1 instance 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 133: '...st to the server MUST be a single Full...' RFC 2119 keyword, line 225: '...Critical item is true, the server MUST...' RFC 2119 keyword, line 227: '...ical item is true, the client MUST NOT...' RFC 2119 keyword, line 238: '... that the server MAY use when forming ...' RFC 2119 keyword, line 242: '...s in the IntermediateCerts MUST NOT be...' (50 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 55 has weird spacing: '...ier for appli...' == Line 423 has weird spacing: '...est was not m...' ** 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 985 looks like a reference -- Missing reference section? 'PKIX' on line 992 looks like a reference -- Missing reference section? 'OpenPGP' on line 990 looks like a reference -- Missing reference section? 'OCSP' on line 988 looks like a reference -- Missing reference section? 'UTF8' on line 997 looks like a reference -- Missing reference section? '0' on line 671 looks like a reference -- Missing reference section? '1' on line 672 looks like a reference -- Missing reference section? '2' on line 673 looks like a reference -- Missing reference section? '3' on line 674 looks like a reference -- Missing reference section? '4' on line 621 looks like a reference -- Missing reference section? '5' on line 622 looks like a reference -- Missing reference section? '6' on line 623 looks like a reference -- Missing reference section? 'XMLDSIG' on line 999 looks like a reference -- Missing reference section? 'XML-ns' on line 713 looks like a reference -- Missing reference section? 'SHA-1' on line 994 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 4 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-04.txt ValiCert 3 November 2000 Paul Hoffman 4 Expires in six months VPN Consortium 5 Russ Housley 6 SPYRUS 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 environments, 43 the amount of processing an application needs to perform before it can 44 accept a certificate must be reduced. There are a variety of 45 applications that can use public key certificates but are burdened by 46 the overhead of validating the certificates when all the application 47 really wants is the public key and name from the certificate, and a 48 determination of whether or not the certificate may be used for a 49 particular purpose. There are other applications that can perform 50 certificate 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 certificate chains needed 65 for path validation. They can also give clients revocation information 66 such as CRLs and OCSP responses that the client can use in the client's 67 path validation. These services can be valuable to client systems that 68 do not include the protocols needed to find and download all of the 69 intermediate certificates, CRLs, and OCSP responses needed for the 70 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 - Need to specify how client asks for and gets back parsed pieces of a 117 certificate. Is this important? What fields do people want? 119 - Should CMS (RFC 2630) be used for signed ASN.1 messages? 121 - Should SCVP support validation of attribute certificates? 123 2. Protocol 125 The SCVP protocol uses a simple request-response model. That is, a SCVP 126 client creates a single request and sends it to the server; the server 127 creates a single response and sends it to the client. Typical use of 128 SCVP is expected to be over HTTP, and possibly email. This document 129 registers MIME types for SCVP requests and responses. 131 3. Requests 133 A SCVP client's request to the server MUST be a single FullRequest 134 item. The FullRequest item contains the entire request. A FullRequest 135 item is carried in an application/scvp-request MIME body part. 137 3.1 FullRequest 139 The FullRequest item encapsulates the client's request. The FullRequest 140 item contains a PSRequest item, and an optional RequestSignature item. 142 3.2 PSRequest 144 The PSRequest item contains the part of the client's request. The 145 PSRequest item contains a Version item, a Query item, a TypesOfCheck 146 item, and a WantBack item. It can also contain an optional 147 RequestNonce item and an optional ReqExtensions item. (The "PS" in 148 PSRequest means "possibly signed".) 150 A signed request can be used to authenticate the client to the 151 server and for non-repudiation of the client's request, such as for 152 accounting purposes. A server might require all requests to be signed 153 if the server did not want to respond to request unless they were from 154 authenticated clients. A server might want to allow unsigned requests 155 if the server is authenticating in some other fashion (such as by 156 IP address). 158 In this specification, the item(s) in the Query item are certificates. 159 The TypesOfCheck item tells the server what types of checking it should 160 do on the item(s) in the Query item. The WantBack item tells the server 161 what the client wants to know about the item(s). ReqExtensions in the 162 PSRequest item are used to extend the request, such as to request a 163 different type of item. 165 3.3 Version 167 The Version item tells the version of SCVP used in a request or a 168 response. The value of the Version item for this specification is 1. 170 3.4 Query 172 The Query item specifies the object of the request. One type of object 173 is defined in this specification: CertsQuery. (Other types of queries 174 might be specified in the future.) The CertsQuery is a request for 175 information on one or more certificates. A CertsQuery contains a list 176 of certificates, and can also optionally contain each of the 177 following items: ValidityTime, IntermediateCerts, TrustedCerts, 178 RevocationInfo, PolicyID, ConfigurationIdentifier, and QueryExtensions. 180 The list of certificates in the Query item tells the server the 181 certificate(s) the client wants a reply for. The optional ValidityTime 182 item tells the time at which the client wants to know about. The 183 optional IntermediateCerts, TrustedCerts, RevocationInfo, PolicyID, and 184 ConfigurationIdentifier items tell the server how to process the 185 request. 187 [[[Is it valuable to add a URL to a certificate in the query (for 188 wireless applications)? If so, how should that be indicated and how 189 does it change the fields that should be returned?]]] 191 3.5 CertBundle 193 The CertBundle item contains one or more Certs. The order of 194 the Cert(s) in the bundle is not important. 196 3.6 Cert 198 The Cert item contains a complete certificate. The Cert item 199 contains an identifier for the type of certificate and the octets of 200 the certificate itself. One type of certificate, for PKIX [PKIX], is 201 defined, but other types of certificates (such as for OpenPGP 202 [OpenPGP]) may be defined in the future. 204 3.8 QueryExtensions 206 The QueryExtensions item specifies a list of extensions to the SCVP 207 protocol. For example to request additional information about the 208 certificate(s) in the CertsQuery. The QueryExtensions item contains a 209 sequence of Extension items, each of which contain an ExtnID item, 210 a Critical item, and an ExtnValue item. 212 3.9 ExtnID 214 The ExtnID item is an identifier for the extension. It contains 215 the OID of the extension. 217 3.10 Critical 219 The Critical item tells whether the extension is critical. The 220 values for the item are: 222 False Not critical 223 True Critical 225 In a request, if the Critical item is true, the server MUST 226 NOT process the request unless it understands the extension. In a 227 reply, if the Critical item is true, the client MUST NOT 228 process the response unless it understands the extension. 230 3.11 ExtnValue 232 The ExtnValue item gives the value of an extension. It 233 contains a sequence of octets. 235 3.12 IntermediateCerts 237 The IntermediateCerts item specifies to the server the intermediate 238 certificates that the server MAY use when forming a certificate chain. 239 The certificates in the IntermediateCerts item can be used by the 240 server in addition to any other certificates that the server knows of 241 when building chains. The IntermediateCerts item contains a list of 242 certificates. The certificates in the IntermediateCerts MUST NOT be 243 self-signed certificates. 245 The purpose of the IntermediateCerts item is to help the server create 246 validation chains. 248 3.13 TrustedCerts 250 The TrustedCerts item specifies to the server the trusted certificates 251 that the server MUST use. If a TrustedCerts item is included in a 252 CertsQuery item, the server MUST NOT use any certificate chain anchors 253 other than the certificates in the TrustedCerts item when forming a 254 certificate chain for validation. The TrustedCerts item contains a 255 CertBundle item. 257 3.14 RevocationInfo 259 The RevocationInfo item specifies to the server revocation information 260 such as CRLs and OCSP [OCSP] responses that the server MAY use when 261 validating certificate chains. The purpose of the RevocationInfo item 262 is to provide revocation information to the server that the server may 263 not have access to, such as an OCSP response that the client received 264 along with the certificate. Note that the information in the 265 RevocationInfo item might not be used by the server, such as if the 266 information is for certificates that the server does not use in chain 267 building. 269 The types of revocation proof that can be provided are: 270 - CRL 271 - OCSP response 273 [[[Need to specify the format of the extensions for both CRLs and 274 for OCSP responses.]]] 276 3.15 PolicyID 278 The PolicyID item specifies to the server the policy ID that the server 279 MUST use when forming a certificate chain. The PolicyID item contains 280 a URL that, when resolved, defines the policy. 282 3.16 ConfigurationIdentifier 284 The ConfigurationIdentifier item tells the server the SCVP options that 285 the client wants the server to use. The client can use this option 286 instead of specifying other SCVP configuration such as PolicyID, 287 TrustedCerts, RevocationInfo, and so on. The value of this item is 288 determined by private agreement between the client and the server and 289 is not specified in this document. The server might want to have 290 identifiers that indicate that some settings are used in addition to 291 others given in the request; in this way, the configuration identifier 292 might be a shorthand for some SCVP options. 294 3.17 TypesOfCheck 296 The TypesOfCheck item describes the kind of checking that the client 297 wants the server to do on the certificate(s) in the Query item. If the 298 TypesOfCheck item is given in a request, it can contain one or more 299 types of checks. For each type of check specified in the request, the 300 server MUST perform all the checks requested, or return an error. 302 The types of checks are: 303 - Build a path to a trusted root 304 - Build a validated path to a trusted root 305 - Do revocation status checks on the path 306 Note that revocation status check inherently includes path construction. 308 3.18 WantBack 310 The WantBack item describes the kind of information the client wants 311 from the server for the certificate(s) in the Query item. If the 312 WantBack item is given in a request, it can contain one or more types 313 of information. For each type of information specified in the request, 314 the server MUST return information on what it found during the check 315 (in a successful response). 317 The types of information that can be requested are: 318 - Certificate chain built for the certificate 319 - Proof of revocation status 321 For example, a request might include a TypesOfCheck item that only specifies 322 path building, and include a WantBack item that specifies the 323 certificate chain built. The response would not include a 324 status for the validation, but would include a certificate chain that 325 the server thinks might validate. This set of options might be used by 326 a client that wants to do its own path validation. 328 3.19 ValidityTime 330 The ValidityTime indicates the time for which the client wants the 331 information to be relevant. Not specifying a ValidityTime means that 332 the server should use the current time. For example, when asking for 333 validation of a certificate, the client might ask "was this certificate 334 valid at this time". The information in the CertReply item in the 335 response MUST be formatted as if the server created the response at the 336 time indicated in the ValidityTime, if the server doesn't have 337 historical information about that time, it MAY either return an error 338 or return information for a later time. A client MUST be able to handle 339 responses that have ThisUpdate items that are later than the requested 340 ValidityTime. 342 3.20 RequestNonce 344 The RequestNonce item is an identifier generated by the client for the 345 request; the server MUST return the same RequestNonce in the signed 346 part of the server's response. The RequestNonce item is simply a 347 sequence of octets. The client SHOULD include a RequestNonce item in 348 every request to prevent an attacker acting as a man-in-the-middle from 349 replaying old responses from the server. The value of the nonce SHOULD 350 change with every request sent from the client. 352 3.22 RequestSignature 354 The RequestSignature item is the signature of the PSRequest item. The 355 details of how a RequestSignature is computed is defined in the 356 specific sections which describe how a request/response is represented 357 in various formats. 359 4. Responses 361 A SCVP server's response to the client MUST be a single FullResponse 362 item. The FullResponse item contains the entire response. A 363 FullResponse item is carried in an application/scvp-response MIME body 364 part. 366 4.1 FullResponse 368 The FullResponse item encapsulates the server's response. The 369 FullResponse item contains a PSResponse item and an optional 370 ResponseSignature item. 372 4.2 PSResponse 374 The PSResponse item contains the part of the server's response that is 375 signed by the ResponseSignature item. The item contains a Version 376 item, a ProducedAt item, a ResponseStatus item, and a RequestHash 377 item. The item can also contain an optional ReplyObjects item, an 378 optional RequestNonce item, and an optional RespExtensions item. The 379 PSResponse item MUST contain exactly one CertReply item for each 380 certificate requested in the request. The RequestNonce item MUST be 381 included if the request had a RequestNonce item. 383 4.3 ProducedAt 385 The ProducedAt item tells the time at which the whole response was 386 produced. The ProducedAt item represents the date at UTC. 388 4.4 ResponseStatus 390 The ResponseStatus item gives status information to the client about 391 its request. The ResponseStatus item has a numeric status code and an 392 optional string that is a sequence of characters from the ISO/IEC 393 10646-1 character set encoded with the UTF-8 transformation format 394 defined in [UTF8]. 396 The optional string may be used to transmit status information, but it 397 is optional. The client MAY choose to display the string to the client. 398 However, because there is no way to know the languages understood by 399 the user, the string may be of little or no use to them. 401 The complete list of status codes for the ResponseStatus item is: 403 0 The request was fully processable 404 1 The request included unrecognized items; continuing 406 10 Too busy; try again later 408 20 The structure of the request was wrong 409 21 The version of request is not supported by this server 410 22 The request included unrecognized items; aborting 411 23 The key given in the RequestSignature is not recognized 412 24 The signature did not match the body of the request 413 25 The encoding was not understood 414 26 The request was not authorized 415 27 The request included unsupported items; continuing 416 28 The request included unsupported items; aborting 418 4.4a RequestHash 420 The RequestHash item is the SHA-1 hash of the PSRequest item. The 421 RequestHash item serves the following purposes: 423 - It helps a client know that the request was not maliciously modified 424 when the client gets the response back 426 - It allows the client to associate a response with a request when 427 using connectionless protocols 429 The purpose of the RequestHash is not for authentication of the 430 client. 432 The server MUST return the RequestHash item in the response. 434 4.5 ReplyObjects 436 The ReplyObjects item returns objects to the client. In this 437 specification, the ReplyObjects item is always a CertReply, which tells 438 the client about a single certificate from the request. The CertReply 439 item contains a Cert item identifying the certificate, a 440 ReplyStatus item, a ThisUpdate item, and an optional NextUpdate item. There 441 may also be the following optional items: ValidationStatus, 442 RevocationStatus, PublicKey, CertSubject, ValidationChain, 443 RevocationProof, and SingleReplyExtensions. 445 The presence or absence of the ValidationStatus, RevocationStatus, 446 PublicKey, CertSubject, ValidationChain, and RevocationProof items in 447 the CertReply item is controlled by the TypesOfCheck, and WantBack 448 items in the request. A server MUST include one of the above items for 449 each related item requested in the TypesOfCheck, and WantBack items. 451 4.6 ReplyStatus 453 The ReplyStatus item gives status information to the client about the 454 request for the specific certificate. Note that the ResponseStatus item 455 is different than the ReplyStatus item. The ResponseStatus item is the 456 status of the whole request, while the ReplyStatus item is the status 457 for the individual certificate. 459 The complete list of status codes for the ReplyStatus item is: 461 0 Success: a definitive answer follows 462 1 Failure: the certificate type is not recognized 463 2 Failure: an item wanted in TypesOfCheck is not recognized 464 3 Failure: an item wanted in WantBack is not recognized 465 4 Failure: the certificate was malformed 466 5 Failure: the mandatory PolicyID is not recognized 467 6 Failure: the ConfigurationIdentifier is not recognized 468 7 Failure: unauthorized request 470 Status code 4 is used to tell the client that the request was properly 471 formed but the certificate in question was not. This is useful to 472 clients that cannot parse a certificate. 474 4.7 ThisUpdate 476 The ThisUpdate item tells the time at which the information in the 477 CertReply was correct. The ThisUpdate item represents the date as 478 UTC. 480 4.8 NextUpdate 482 The NextUpdate item tells the time until which the server expects the 483 information in the CertReply to be valid. The NextUpdate item 484 represents the date at UTC. [[[Is there a desire for another item that 485 says "the server takes liability for this response up to this 486 particular time?]]] 488 4.9 ReplyTypesOfCheck 490 The ReplyTypesOfCheck contains the responses to the client's 491 TypesOfCheck item in the request. It has the same form as the 492 Extensions item, and the OIDs in the ReplyTypesOfCheck item MUST match 493 the OIDS in the TypesOfCheck item. The criticality bit MUST NOT be set. 495 The value for path building to a trusted root, {type-arc 0}, can be 496 one of the following: 498 Value Meaning 499 ----- ------- 500 0 Built a path 501 1 Could not build a path 503 The value for path validation to a trusted root, {type-arc 1}, can be 504 one of the following: 506 Value Meaning 507 ----- ------- 508 0 Valid 509 1 Not valid 511 The value for the revocation status, {type-arc 2}, can be one of the 512 following: 514 Value Meaning 515 ----- ------- 516 0 Good 517 1 Revoked 518 2 Unknown 520 4.10 ReplyWantBack 522 The ReplyWantBack contains the responses to the client's WantBack item 523 in the request. It has the same form as the Extensions item, and the 524 OIDs in the ReplyWantBack item MUST match the OIDS in the WantBack 525 item. The criticality bit MUST NOT be set. 527 The value for the certificate chain used to verify the certificate 528 in the request, {want-arc 0}, is a CertBundle item. 530 The value for the proof of revocation status, {want-arc 1}, is a 531 RevocationProof item. 533 4.11 RevocationProof 535 The RevocationProof item gives the client the proof that the server 536 used to check revocation. The structure of the RevocationProof item is 537 the same as an Extensions item. The OIDs in the RevocationProof item 538 are the same as those in the RevocationInfo item. 540 4.12 ResponseSignature 542 The ResponseSignature item is the signature of the PSResponse item. 544 The client SHOULD check the signature on every signed message it 545 receives from the server. In order to check the signature, the client 546 MUST know and rely on the public signing key of the server. The client 547 could have obtained the server's public key through an out-of-band 548 mechanism of direct trust or through a certificate that chains to a 549 root that the client trusts to delegate this type of authority. 551 5. ASN.1 Syntax for SCVP 553 This section defines the syntax for SCVP messages. The semantics for 554 the messages are defined in sections 2, 3, and 4. 556 5.1 Signatures in ASN.1 558 Signatures in ASN.1 are done over the DER encoding of the 559 PSRequest/PSResponse item. The Name is the distinguished name of the 560 signer. The SignatureAlgorithm is the 561 algorithm used to sign the request, and a SignatureBits item that is 562 the signature itself. The signature may also contain an 563 optional CertBundle that represents a chain of certs to verify the key used 564 to sign the request. 566 5.1.1 SignatureAlgorithm 568 The SignatureAlgorithm identifies the algorithm used to sign a request 569 or response. The SigningAlgorithm item contains the OID of the 570 algorithm and any necessary parameters for the algorithm. 572 5.1.2 SignatureBits 574 The SignatureBits item holds the octets of a signature. The structure 575 of the SignatureBits item is determined by the value of the 576 SignatureAlgorithm item. 578 5.2 ASN.1 Module definition 580 SCVP DEFINITIONS EXPLICIT TAGS ::= 582 BEGIN 584 IMPORTS 586 -- Directory Authentication Framework (X.509) 587 Certificate, AlgorithmIdentifier 588 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 589 module(1) authenticationFramework(7) 3 } 591 -- PKIX Imports 592 Name, Extensions, 593 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 594 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 595 id-mod(0) id-pkix1-explicit-88(1)}; 597 FullRequest ::= SEQUENCE { 598 psRequest PSRequest, 599 requestSignature [0] Signature OPTIONAL 600 } 602 PSRequest ::= SEQUENCE { 603 version INTEGER, 604 query Query, 605 typesOfCheck TypesOfCheck, 606 wantBack WantBack, 607 requestNonce [1] OCTET STRING OPTIONAL, 608 reqExtensions [2] Extensions OPTIONAL 609 } 611 Query ::= CHOICE { 612 certsQuery [0] CertsQuery 613 } 615 CertsQuery ::= SEQUENCE { 616 queriedCerts SEQUENCE SIZE (1..MAX) OF Cert, 617 validityTime [0] GeneralizedTime OPTIONAL, 618 intermediateCerts [1] SEQUENCE SIZE (1..MAX) OF Cert OPTIONAL, 619 trustedCerts [2] CertBundle OPTIONAL, 620 revocationInfo [3] Extensions OPTIONAL, 621 policyID [4] UTF8String OPTIONAL, 622 configurationIdentifier [5] OBJECT IDENTIFIER OPTIONAL, 623 queryExtensions [6] Extensions OPTIONAL 624 } 626 CertBundle ::= SEQUENCE SIZE (1..MAX) OF Cert 628 Cert ::= CHOICE { 629 pkixCert [0] Certificate 630 } 632 TypesOfCheck ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 634 WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 636 Signature ::= SEQUENCE { 637 signerName Name, 638 signatureAlgorithm AlgorithmIdentifier, 639 signatureBits BIT STRING, 640 certs [0] CertBundle OPTIONAL 641 } 643 FullResponse ::= SEQUENCE { 644 psResponse PSResponse, 645 responseSignature [0] Signature OPTIONAL 646 } 648 PSResponse ::= SEQUENCE { 649 version INTEGER, 650 producedAt GeneralizedTime, 651 responseStatus ResponseStatus, 652 requestHash OCTET STRING, 653 replyObjects [0] ReplyObjects OPTIONAL, 654 requestNonce [1] OCTET STRING OPTIONAL, 655 respExtensions [2] Extensions OPTIONAL 656 } 658 ResponseStatus ::= SEQUENCE { 659 statusCode INTEGER, 660 errorMessage [0] UTF8String OPTIONAL 661 } 663 ReplyObjects ::= CHOICE { 664 certReplies [0] SEQUENCE SIZE (1..MAX) OF CertReply 665 } 667 CertReply ::= SEQUENCE { 668 cert Cert, 669 replyStatus ReplyStatus, 670 thisUpdate GeneralizedTime, 671 nextUpdate [0] GeneralizedTime OPTIONAL, 672 replyTypesOfCheck [1] Extensions OPTIONAL, 673 replyWantBack [2] Extensions OPTIONAL, 674 singleReplyExtensions [3] Extensions OPTIONAL 675 } 677 -- The encoding of the value for path validation and revocation status 678 -- will be as an INTEGER 680 ReplyStatus ::= ENUMERATED { 681 success (0), 682 certTypeUnrecognized (1), 683 typeOfCheckUnrecognized (2), 684 wantBackUnrecognized (3), 685 certMalformed (4), 686 policyIDUnrecognized (5), 687 configInfoUnrecognized (6), 688 unauthorizedRequest (7) 689 } 691 -- Need to include type-arc, want-arc, and revinfo-arc 693 END 695 6. XML Syntax for SCVP 697 This section defines the syntax for SCVP messages. The semantics for 698 the messages are defined in sections 2, 3, and 4. 700 TODO: We need to import the XML DSig data into our DTD. We also need 701 to provide more information about the format of the elements which map 702 to PCDATA. 704 Note: this is the second attempt at XML for SCVP. We invite any comments 705 on it. 707 6.1 Signatures in XML 709 Signatures are done using [XMLDSIG]. 711 6.2 Namespaces 713 The XML namespace [XML-ns] URI that MUST be used by implementations of 714 this (dated) specification is: 716 xmlns="http://www.ietf.org/pkixwg/01/scvp" 718 6.3 XML Request/Response syntax 720 723 725 728 729 735 738 740 742 751 753 755 757 759 761 763 765 767 769 771 773 775 777 779 781 783 785 787 789 791 793 796 798 806 809 811 814 816 818 820 822 824 826 834 836 838 840 842 843 853 855 6.3 Example of XML syntax 857 859 861 862 863 1 864 865 866 867 868 869 MIICEzCCAb0CAgfYMA0GCSqGSIb3D 870 QEBBAUAMIGTMQswCQYDVQQGEwJLTz 871 . . . 872 oeedsN6iA4IhpA4Ev2rWiM92OoKag 873 UvVGaQoBuDkz7JfYNw== 874 875 876 878 879 19991232235959 880 881 883 884 885 886 MIICEzCCAb0CAgfYMA0GCSqGSIb3D 887 QEBBAUAMIGTMQswCQYDVQQGEwJLTz 888 . . . 889 oeedsN6iA4IhpA4Ev2rWiM92OoKag 890 UvVGaQoBuDkz7JfYNw== 891 892 894 896 897 899 900 1.3.5.5.5.2.5.2 901 903 904 1.3.5.5.5.2.5.2 905 906 2888475218934 907 908 909 1.5.4.5.9.12.1 910 192812 911 912 914 916 917 918 920 922 923 924 926 927 928 930 a23bcd43 931 932 933 dd2323dd 934 935 936 937 C=US, ST=Illinois, L=Chicago, O=Aromatic 938 Penguin Playing Basketball, OU=Certificate 939 Authority, CN=www.ceramic.com 940 2007 941 942 943 MIICITCCAcsCAgfXMA0GCSqGSIb3DQEBBAUAMIGaMQswCQYDVQQG 944 EwJVUzERMA8GA1UECBMISWxsaW5vaXMxEDAOBgNVBAcTB0NoaWNh 945 . . . 946 bD2d2MixUSENihcgGbCEikUpNrMREO/eYkyKsiqmzAxlr3Tu/eKB 947 NBeu 948 949 950 951 952 954 TODO: Need to add an example of a response 956 7. Security Considerations 958 A client that trusts a server's responses for validation of 959 certificates inherently trusts that server as much as it would trust 960 its own validation software. This means that if an attacker compromises 961 a trusted SCVP server, the attacker can change the validation 962 processing for every client that relies on that server. Thus, an SCVP 963 server must be protected at least as well as the weakest root server 964 that the SCVP server trusts. 966 If the client does not check the signature on the response, a 967 man-in-the-middle attack could fool the client into believing modified 968 responses from the server, or responses to questions the client did not 969 ask. This attack does not affect the usefulness of some responses (such 970 as a response that returns a certificate path that the client will 971 validate itself) but does affect things such as a validation response. 973 If the client does not include a RequestNonce item, or if the client 974 does not check that the RequestNonce in the reply matches that in the 975 request, an attacker can replay previous responses from the server. 977 If the server does not require some sort of authorization (such as 978 signed requests), an attacker can get the server to reply to arbitrary 979 requests. Such responses may give the attacker information about 980 weaknesses in the server or about the timeliness of the server's 981 checking. This information may be valuable for a future attack. 983 A. References 985 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement 986 Levels", RFC 2119. 988 [OCSP] "PKIX Online Certificate Status Protocol (OCSP)", RFC 2560. 990 [OpenPGP] "OpenPGP Message Format", RFC 2440. 992 [PKIX] "PKIX Certificate and CRL Profile", RFC 2459. 994 [SHA-1] "Secure Hash Standard", NIST FIPS publication 180-1, April 995 1995. 997 [UTF8] "UTF-8, a transformation format of ISO 10646", RFC 2279. 999 [XMLDSIG] NEED THE REFERENCE 1001 B. Acknowledgments 1003 The lively debate in the PKIX Working Group also had a significant 1004 impact on the types of items described in this protocol. Denis Pinkas 1005 suggested some additional requirements for the protocol, and Mike Myers 1006 helped point out sections that needed clarification. Frank 1007 Balluffi and Ameya Talwalkar were responsible for the first 1008 implementation and suggestions on a few deficiencies in the document. 1010 C. Changes Between Versions of This Document 1012 C.1 Differences between -00 and -01 1014 1: Rewrote to both narrow focus and to explain the goals more fully. 1016 1.1: Removed second paragraph. 1018 2: Removed the discussion of the two syntaxes. 1020 3: Reorganized the section to put the Extensions items after the 1021 CertsQuery items. The section numbers below are from the -00 draft. 1022 Throughout the section, made RequestHash mandatory instead of optional. 1023 Added RevocationInfo item. Changed CertID to CertHash throughout. 1024 Fixed the names of the parts of the signature to match the text. 1026 3.1: Split the item into a TBSRequest followed by the hash and/or 1027 signature. Changed the order of the extensions item so that all the 1028 optional items were together. Changed CertsQuery into Query. Added the 1029 ValidityTime item. 1031 3.3: Redefined Extension to be Extensions to be more similar to 1032 Extensions in PKIX. Other wording changes. 1034 3.5: Gave more explanation for the ExtensionCritical bit, and made 1035 the values boolean. Note that this item may disappear, depending 1036 on discussion of the open issue on it. 1038 3.7: Changed CertsQuery into Query and described the one defined 1039 instance as CertsQuery. Moved the TypesOfCheck and WantBack from the 1040 Query and up one level to the TBSRequest. 1042 3.9: Removed OpenPGP cert, but allowed for it to be added back in the 1043 future. 1045 3.10: Removed OpenPGP cert hash, but allowed for it to be added back in 1046 the future. 1048 3.11 Made TypesOfCheck OIDs. 1050 3.12: Made WantBack OIDs. Removed the public key and the names. 1052 3.10: Added sentence about when a client might include a CertHash item 1053 in the TrustedRoots. 1055 3.13: Clarified use of IntermediateCerts 1057 3.18: Added wording that the RequestHash should not be used for 1058 authentication. 1060 3.19: Changed wording to make it clear that RequestSignature was needed 1061 only for authentication of the client. 1063 3.23: Clarified purpose of KeyID. 1065 4: The section numbers below are from the -00 draft. Throughout the 1066 section, made returning the RequestHash mandatory because it is now 1067 mandatory in the request. 1069 4.1: Split the item into a TBSResponse followed by the hash and/or 1070 signature. Made ResponseSignature mandatory. Made the items returned in 1071 the form of Extensions to match the fact that TypesOfCheck and WantBack 1072 are now sequences of OIDs. 1074 4.3: Made the status code a single number. 1076 4.4 Removed the subject names and public keys. Added NextUpdate. 1078 4.10: Clarified that CertSubject for PKIX certs must contain both the 1079 subject name and the subjectAltName. 1081 4.13: Made ResponseSignature mandatory; this might be changed back to 1082 optional for some types of responses in a future revision of the spec. 1083 Added a discussion of how the client can get the server's signing key. 1085 Old 5: Removed tiny syntax, renumbered old 6 to 5. 1087 5: Added note about semantics in 2-4. 1088 Split FullRequest into FullRequest and TBSRequest. 1089 Moved the extensions item in FullRequest. 1090 Changed the certsQuery to Query. 1091 Move TypesOfCheck and WantBack up to TBSRequest. 1092 Made TypesOfCheck and WantBack SEQUENCE of OIDs. 1093 Added ValidityTime. 1094 Changed "CertID" to "CertHash". 1095 Made the status code a single number. 1096 Added reminder in CertItem about full certs. 1097 Changed order of Signature items. 1098 Split FullResponse into FullResponse and TBSResponse. 1099 Added ReplyTypesOfChecks and ReplyWantBack items. 1100 Added Extensions item and sub-items. 1102 7: Updated to reflect mandatory RequestHash and ResponseSignature. 1103 Added explicit words about compromise of the SCVP server. Removed the 1104 first paragraph because it was confusing and will be fixed in later 1105 versions of the draft. 1107 A: Added reference to OCSP. 1109 D: Updated. 1111 C.2 Difference between -01 and -02 1113 Abstract: Updated to include design goals. 1115 Throughout: Changed TBSRequest to PSRequest. Changed UsageID to 1116 PolicyID. Changed Greenwich Mean Time to UTC. 1118 1.2: Changed wording to match RFC 2119. 1120 1.3: Removed first open issue (cert hashes) because we removed cert 1121 hashes. Removed third open issue (optional response signing) because 1122 the draft now clarifies which responses must be signed and which ones 1123 don't. Added new open issue (making signatures on responses optional). 1125 3.1: Removed the RequestHash from the request. 1127 3.2: Removed the RequestHash from the request. Added explanation of 1128 PSRequest name. Added SignerName here. 1130 3.4: Added note about other types of queries being added in the future. 1132 3.5: Removed CertHash. 1134 3.7: Removed the CertHash item. Filled in the hole that would have been 1135 created with SignerName from below. 1137 3.10: Minor edit to last line. 1139 3.12: Removed most of the second paragraph because it was confusing. 1141 3.14: Removed the arc stuff. 1143 3.15: Made the PolicyID be a URL instead of an OID. 1145 3.17: Removed the arc stuff. Also added last sentence after the list. 1147 3.18: Removed the arc stuff. 1149 3.19: Removed the surperfluous NextUpdate from the last sentence. 1150 Detailed what no ValidityTime request means. Changed what should happen 1151 if the client requests information for a time that the server does not 1152 have. 1154 3.21: Changed last sentence to indicate that the RequestHash is only 1155 returned in the response, not sent in the request. 1157 3.22: Removed the last sentence because the RequestHash is only 1158 returned in the response, not sent in the request. Moved the second 1159 paragraph up to 3.2 to make it clearer why someone might or might not 1160 sign their request. Got rid of the optional KeyID. Removed the 1161 SignerName. 1163 3.23: Moved SignerName up in the document to 3.7. Renumbered the rest 1164 of this section. 1166 3.26: Got rid of KeyID item. 1168 4.2: Added SignerName here. 1170 4.4: Got rid of 11 and 12 and made the description of 10 more sensible. 1171 Changed 25 to "encoding not understood". 1173 4.5: Removed the last sentence because it was confusing. 1175 4.9: Got rid of "temporarily unknown". 1177 4.12: Made the response signature optional in the first sentence of the 1178 second paragraph. Got rid of KeyID. Removed the SignerName. 1180 5: Removed RequestHash from FullRequest. Removed CertItem and made 1181 CertBundle a SEQUENCE OF Cert. Changed type of policyID to UTF8string 1182 to hold the URL. Got rid of KeyID. Moved signerName out of Signature 1183 and into PSRequest and TBSResponse, and made it optional. 1185 6: Added the XML syntax and example. 1187 7: Removed the second paragraph because it dealt with RequestHash in 1188 the request. 1190 C.3 Difference between -02 and -03 1192 1. Changed TBSResponse and TBSRequest to PSResponse and 1193 PSRequest. Made signatures optional in both requests and responses. 1195 2. Added a tag to the optional signatures in both requests and 1196 responses. 1198 3. Changed RevocationInfos to RevocationInfo. 1200 4. Removed CertHash completely. 1202 5. Simplified section 3.5, since FullCert has gone away 1204 6. Replaced section 3.6 to talk about Cert, rather than FullCert 1206 7. Replaced ExtensionParameter with ExtensionValue in Section 3.11. 1208 8. Made sure that all SEQUENCE OF are SEQUENCE SIZE (1..MAX) OF 1210 9. Import Extension and used the same definition for Extension as in 1211 RFC2459 1213 10. Replace "trusted root" with "trusted certificate", because a 1214 server or client might decide to put its trust in a certificate that 1215 might not be self-signed. Replaced trustedRoot with trustedCert. 1217 11. Fixed once occurance of definition of requestNonce 1219 12. Removed scvp, scvpReq and scvpResp tags in the XML. 1221 13. Removed the last 2 sentences of the second paragraph Section 3.4 1223 14. Changed last sentence of section 3.13, since you have have multiple 1224 cert chains for a certificate even if there is no cross certification. 1226 15. Changed last sentence of section 3.17. 1228 16. Moved section 3.21 to the response section - 4.4a. We need to 1229 renumber all sections when we are close to being done. 1231 17. Added a default value for the attribute value of ReplyStatus in 1232 the XML. 1234 18. Added IMPORTS to the ASN.1 module. 1236 19. Gave the extensions in different places different names. 1238 20. Changed the way criticality is specified for Extension in XML 1240 21. Added the mime type registration requests 1242 22. Added appendix E and moved Author Information to appendix F 1244 23. Moved signerName from the PSRequest and PSResponse to the 1245 signature part. 1247 24. Removed the second paragraph in section 3.13. 1249 25. Changed a line in section 3.14, first para (about where a client 1250 may have obtained an OCSP response to send to the SCVP server). 1252 26. Got rid of the multiple places where we say what is signed by the 1253 RequestSignature or ResponseSignature (e.g. section 3.1 and 3.2). Also 1254 simplified the definition of the RequestSignature and 1255 ResponseSignature in sections 3 and 4. The should be defined in detail 1256 in the encoding sections. 1258 C.4 Difference between -03 and -04 1260 1. Added format information in the http header in Appendix E.1.1 1262 2. Changed the numbers in the want-arc to start with 0 in section 4.10 1264 3. Added error states to indicate that the request contained 1265 unsupported items in section 4.4. 1267 4. Added acknowledgement to Frank Balluffi and Ameya Talwalkar in 1268 Appendix B. 1270 5. Made nextUpdate optional (renumbered tags in CertReply). 1272 6. Specified the criticality bit in ReplyTypesOfCheck and ReplyWantBack 1273 (sections 4.9 and 4.10) 1275 7. Specified the encoding for the replyTypesOfCheck field 1277 8. Renumbered tag fields for PSResponse. 1279 9. Added a TODO to section 3.4 about Cert URLs. 1281 10. Corrected the section on the ConfigurationIdentifier. 1283 11. Modified TypesOfCheck to allow client to request a non-validated 1284 path. 1286 12. Removed an old (unneeded) line in the security section. 1288 D. MIME Registrations 1290 D.1 application/scvp-request 1292 To: ietf-types@iana.org 1293 Subject: Registration of MIME media type application/scvp-request 1295 MIME media type name: application 1297 MIME subtype name: scvp-request 1299 Required parameters: format 1301 Optional parameters: None 1303 Encoding considerations: binary or XML 1305 Security considerations: Carries a request for information. This 1306 request may optionally be cryptographically signed. 1308 Interoperability considerations: None 1310 Published specification: IETF PKIX Working Group Draft on Simple 1311 Certificate Validation Protocol - SCVP 1313 Applications which use this media type: SCVP clients 1315 Additional information: 1317 Magic number(s): None 1318 File extension(s): .SCQ 1319 Macintosh File Type Code(s): none 1321 Person & email address to contact for further information: 1322 Ambarish Malpani 1324 Intended usage: COMMON 1326 Author/Change controller: 1327 Ambarish Malpani 1329 D.2 application/scvp-response 1331 To: ietf-types@iana.org 1332 Subject: Registration of MIME media type application/scvp-response 1334 MIME media type name: application 1336 MIME subtype name: scvp-response 1338 Required parameters: format 1340 Optional parameters: None 1342 Encoding considerations: binary or XML 1344 Security considerations: Carries a cryptographically signed response 1346 Interoperability considerations: None 1348 Published specification: IETF PKIX Working Group Draft on Simple 1349 Certificate Validation Protocol - SCVP 1351 Applications which use this media type: SCVP servers 1353 Additional information: 1355 Magic number(s): None 1356 File extension(s): .SCS 1357 Macintosh File Type Code(s): none 1359 Person & email address to contact for further information: 1360 Ambarish Malpani 1362 Intended usage: COMMON 1364 Author/Change controller: 1365 Ambarish Malpani 1367 E. SCVP data format 1369 E.1 SCVP over HTTP 1371 This section describes the formatting that will be done to the 1372 request and response to support HTTP. 1374 E.1.1 Request 1376 HTTP based SCVP requests can use the POST method to 1377 submit their requests. Where privacy is 1378 a requirement, SCVP transactions exchanged using HTTP MAY be 1379 protected using either TLS/SSL or some other lower layer protocol. 1381 An SCVP request using the POST method is constructed as follows: The 1382 Content-Type header MUST have the value "application/scvp-request". 1383 In addition, the format of the message must be specified as either 1384 "format=xml" or "format=asn1". The Content-Length header MUST be present 1385 and have the exact length of the request. The body of the message is the 1386 binary value of the DER encoding of the FullRequest, or XML 1387 encoding of FullRequest. Other HTTP headers MAY be present and MAY 1388 be ignored if not understood by the requestor. 1390 Sample Content-Type headers are: 1391 Content-Type: application/scvp-request;format=xml 1392 Content-Type: application/scvp-request;format=asn1 1394 E.1.2 Response 1396 An HTTP-based SCVP response is composed of the appropriate HTTP 1397 headers, followed by the binary value of the DER encoding of the 1398 FullResponse or XML encoding of FullResponse. The Content-Type 1399 header MUST have the value "application/scvp-response". 1400 In addition, the format of the message must be specified as either 1401 "format=xml" or "format=asn1". The 1402 Content-Length header MUST be present and specify 1403 the length of the response. Other HTTP headers MAY be present and MAY 1404 be ignored if not understood by the requestor. 1406 F. Author Contact Information 1408 Ambarish Malpani 1409 ValiCert, Inc. 1410 339 N. Bernardo Ave. 1411 Mountain View, CA 94043 1412 ambarish@valicert.com 1414 Paul Hoffman 1415 VPN Consortium 1416 127 Segre Place 1417 Santa Cruz, CA 95060 USA 1418 paul.hoffman@vpnc.org 1420 Russell Housley 1421 SPYRUS 1422 381 Elden Street 1423 Suite 1120 1424 Herndon, VA 20170 USA 1425 housley@spyrus.com