idnits 2.17.1 draft-ietf-pkix-scvp-03.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 1373 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 3 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 123: '...st to the server MUST be a single Full...' RFC 2119 keyword, line 212: '...Critical item is true, the server MUST...' RFC 2119 keyword, line 214: '...ical item is true, the client MUST NOT...' RFC 2119 keyword, line 225: '... that the server MAY use when forming ...' RFC 2119 keyword, line 229: '...s in the IntermediateCerts MUST NOT be...' (47 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 53 has weird spacing: '...ier for appli...' == Line 408 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 958 looks like a reference -- Missing reference section? 'PKIX' on line 965 looks like a reference -- Missing reference section? 'OpenPGP' on line 963 looks like a reference -- Missing reference section? 'OCSP' on line 961 looks like a reference -- Missing reference section? 'UTF8' on line 970 looks like a reference -- Missing reference section? '0' on line 646 looks like a reference -- Missing reference section? '1' on line 647 looks like a reference -- Missing reference section? '2' on line 648 looks like a reference -- Missing reference section? '3' on line 629 looks like a reference -- Missing reference section? '4' on line 595 looks like a reference -- Missing reference section? '5' on line 596 looks like a reference -- Missing reference section? '6' on line 597 looks like a reference -- Missing reference section? 'XMLDSIG' on line 972 looks like a reference -- Missing reference section? 'XML-ns' on line 684 looks like a reference -- Missing reference section? 'SHA-1' on line 967 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-03.txt ValiCert 3 June 12, 2000 Paul Hoffman 4 Expires in six months VPN Consortium 6 Simple Certificate Validation Protocol (SCVP) 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 The SCVP protocol allows a client to offload certificate handling to a 31 server. The server can give a variety of valuable information about the 32 certificate, such as whether or not the certificate is valid, a chain 33 to a trusted certificate, and so on. SCVP has many purposes, including 34 simplifying client implementations and allowing companies to centralize 35 their trust and policy managment. 37 1. Introduction 39 Certificate validation is a difficult problem. If certificate handling 40 is to be widely deployed in a variety of applications and environments, 41 the amount of processing an application needs to perform before it can 42 accept a certificate must be reduced. There are a variety of 43 applications that can use public key certificates but are burdened by 44 the overhead of validating the certificates when all the application 45 really wants is the public key and name from the certificate, and a 46 determination of whether or not the certificate may be used for a 47 particular purpose. There are other applications that can perform 48 certificate path validation but have no reliable method of obtaining a 49 current chain to a trusted certificate. 51 1.1 SCVP overview and requirements 53 The primary goals of SCVP are to make it easier for applications to 54 deploy systems using a PKI and to allow centralization of administering 55 PKI policies. Parts of SCVP can be used by clients that do much of the 56 PKI processing themselves and simply want a useful but untrusted server 57 that will collect information for them. Other parts can be used by 58 clients that have complete trust in the server to both offload the work 59 of certificate validation and to ensure that policies are enforced in a 60 consistent fashion across an enterprise. 62 Untrusted SCVP servers can give client the certificate chains needed 63 for path validation. They can also give clients revocation information 64 such as CRLs and OCSP responses that the client can use in the client's 65 path validation. These services can be valuable to client systems that 66 do not include the protocols needed to find and download all of the 67 intermediate certificates, CRLs, and OCSP responses needed for the 68 client to perform complete path validation. 70 Trusted SCVP servers can perform full certificate validation for the 71 client. If a client uses these services, it inherently trusts the SCVP 72 server as much as it would its own path validation software (if it 73 contained such software). There are two main reasons that a client may 74 want to trust such an SCVP server: 76 - The client does not want to incur the overhead of including path 77 validation software and running it for each certificate it receives. 79 - The client is in an enterprise that wants to centralize its PKI 80 validation policies, such as which root certificates are trusted and 81 which types of policy checking are performed during path validation. 83 1.2 Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [MUSTSHOULD]. 89 1.3 Open Issues 91 The following is a list of issues that were raised on earlier versions 92 of this document that have not been fully dealt with here. Comments on 93 these issues are particularly welcome. 95 - Extensions can be marked as critical. The usefulness and problems of 96 criticality have been long debated and there has not been a great deal 97 of consensus. In SCVP, marking a request extension as critical says to 98 the server "don't give me an answer unless you understand this 99 extension", and marking a response extension as critical says "don't 100 use this response unless you understand this extension". Without the 101 critical bit in the extensions, either the semantics of extensions 102 would have to be changed to essentially say "all extensions are 103 critical" (which is overkill for some extensions that might really be 104 optional), or the semantics would have to be changed to say "you can 105 never rely on the other party understanding an extension", which would 106 limit the usefulness of some extensions. 108 - All responses are signed. There may be cases where the server 109 doesn't want to sign the responses, such as on messages that 110 are only error responses, or where the message is travelling over a 111 medium that is already known to be secure. 113 2. Protocol 115 The SCVP protocol uses a simple request-response model. That is, a SCVP 116 client creates a single request and sends it to the server; the server 117 creates a single response and sends it to the client. Typical use of 118 SCVP is expected to be over HTTP, and possibly email. This document 119 registers MIME types for SCVP requests and responses. 121 3. Requests 123 A SCVP client's request to the server MUST be a single FullRequest 124 item. The FullRequest item contains the entire request. A FullRequest 125 item is carried in an application/scvp-request MIME body part. 127 3.1 FullRequest 129 The FullRequest item encapsulates the client's request. The FullRequest 130 item contains a PSRequest item, and an optional RequestSignature item. 132 3.2 PSRequest 134 The PSRequest item contains the part of the client's request. 135 The PSRequest item 136 contains a Version item, a Query item, a TypesOfCheck item, and a 137 WantBack item. It can also contain an optional RequestNonce item and 138 an optional ReqExtensions item. (The "PS" in PSRequest means "possibly 139 signed".) 141 A signed request can be used to authenticate the client to the 142 server and for non-repudiation of the client's request, such as for 143 accounting purposes. A server might require all requests to be signed 144 if the server did not want to respond to request unless they were from 145 authenticated clients. A server might want to allow unsigned requests 146 if the server is authenticating in some other fashion (such as by 147 IP address). 149 In this specification, the item(s) in the Query item are certificates. 150 The TypesOfCheck item tells the server what types of checking it should 151 do on the item(s) in the Query item. The WantBack item tells the server 152 what the client wants to know about the item(s). ReqExtensions in the 153 PSRequest item are used to extend the request, such as to request a 154 different type of item. 156 3.3 Version 158 The Version item tells the version of SCVP used in a request or a 159 response. The value of the Version item for this specification is 1. 161 3.4 Query 163 The Query item specifies the object of the request. One type of object 164 is defined in this specification: CertsQuery. (Other types of queries 165 might be specified in the future.) The CertsQuery is a request for 166 information on one or more certificates. A CertsQuery contains a list 167 of certificates, and can also contain zero or one of each of the 168 following items: ValidityTime, IntermediateCerts, TrustedCerts, 169 RevocationInfo, PolicyID, ConfigurationIdentifier, and QueryExtensions. 171 The list of certificates in the Query item tells the server the 172 certificate(s) the client wants a reply for. The optional ValidityTime 173 item tells the time at which the client wants to know about. The 174 optional IntermediateCerts, TrustedCerts, RevocationInfo, PolicyID, and 175 ConfigurationIdentifier items tell the server how to process the 176 request. 178 3.5 CertBundle 180 The CertBundle item contains one or more Certs. The order of 181 the Cert(s) in the bundle is not important. 183 3.6 Cert 185 The Cert item contains a complete certificate. The Cert item 186 contains an identifier for the type of certificate and the octets of 187 the certificate itself. One type of certificate, for PKIX [PKIX], is 188 defined, but other types of certificates (such as for OpenPGP 189 [OpenPGP]) may be defined in the future. 191 3.8 QueryExtensions 193 The QueryExtensions item specifies a list of extensions to the SCVP 194 protocol, for example to request additional information about the 195 certificate(s) in the CertsQuery. The QueryExtensions item contains a 196 sequence of Extension items, each of which contain an ExtnID item, 197 a Critical item, and an ExtnValue item. 199 3.9 ExtnID 201 The ExtnID item is an identifier for the extension. It contains 202 the OID of the extension. 204 3.10 Critical 206 The Critical item tells whether the extension is critical. The 207 values for the item are: 209 False Not critical 210 True Critical 212 In a request, if the Critical item is true, the server MUST 213 NOT process the request unless it understands the extension. In a 214 reply, if the Critical item is true, the client MUST NOT 215 process the reply unless it understands the extension. 217 3.11 ExtnValue 219 The ExtnValue item gives the value of an extension. It 220 contains a sequence of octets. 222 3.12 IntermediateCerts 224 The IntermediateCerts item specifies to the server the intermediate 225 certificates that the server MAY use when forming a certificate chain. 226 The certificates in the IntermediateCerts item can be used by the 227 server in addition to any other certificates that the server knows of 228 when building chains. The IntermediateCerts item contains a list of 229 certificates. The certificates in the IntermediateCerts MUST NOT be 230 self-signed certificates. 232 The purpose of the IntermediateCerts item is to help the server create 233 validation chains. 235 3.13 TrustedCerts 237 The TrustedCerts item specifies to the server the trusted certificates 238 that the server MUST use. If a TrustedCerts item is included in a 239 CertsQuery item, the server MUST NOT use any certificate chain anchors 240 other than the certificates in the TrustedCerts item when forming a 241 certificate chain for validation. The TrustedCerts item contains a 242 CertBundle item. 244 3.14 RevocationInfo 246 The RevocationInfo item specifies to the server revocation information 247 such as CRLs and OCSP [OCSP] responses that the server MAY use when 248 validating certificate chains. The purpose of the RevocationInfo item 249 is to provide revocation information to the server that the server may 250 not have access to, such as an OCSP response that the client received 251 along with the certificate. Note that the information in the 252 RevocationInfo item might not be used by the server, such as if the 253 information is for certificates that the server does not use in chain 254 building. 256 The types of revocation proof that can be provided are: 257 - CRL 258 - OCSP response 260 [[[Need to specify the format of the extensions for both CRLs and 261 for OCSP responses.]]] 263 3.15 PolicyID 265 The PolicyID item specifies to the server the policy ID that the server 266 MUST use when forming a certificate chain. The PolicyID item contains 267 a URL that, when resolved, defines the policy. 269 3.16 ConfigurationIdentifier 271 The ConfigurationIdentifier item tells the server the SCVP options that 272 the client wants the server to use. The client can use this option 273 instead of specifying other SCVP configuration such as PolicyID, 274 TrustedCerts, RevocationInfo, and so on. The value of this item is 275 determined by private agreement between the client and the server and 276 is not specified in this document. For example, the value might be the 277 hash of some set of options, or it might be a short identifier for a 278 common set of options. Further, the server might want to have 279 identifiers that indicate that some settings are used in addition to 280 others given in the request; in this way, the configuration identifier 281 might be a shorthand for some SCVP options. 283 3.17 TypesOfCheck 285 The TypesOfCheck item describes the kind of checking that the client 286 wants the server to do on the certificate(s) in the Query item. If the 287 TypesOfCheck item is given in a request, it can contain one or more 288 types of checks. For each type of check specified in the request, the 289 server MUST perform all the checks requested, or return an error. 291 The types of checks are: 292 - Path validation to a trusted root 293 - Revocation status 294 Note that revocation status check inherently includes path validation. 296 3.18 WantBack 298 The WantBack item describes the kind of information the client wants 299 from the server for the certificate(s) in the Query item. If the 300 WantBack item is given in a request, it can contain one or more types 301 of information. For each type of information specified in the request, 302 the server MUST return information on what it found during the check. 304 The types of information that can be requested are: 305 - Certificate chain used to validate the certificate 306 - Proof of revocation status 308 For example, a request might include a TypesOfCheck item that does not 309 specify path validation, and include a WantBack item that specifies the 310 certificate chain used to validate. The response would not include a 311 status for the validation, but would include a certificate chain that 312 the server thinks might validate. This set of options might be used by 313 a client that wants to do its own path validation. 315 3.19 ValidityTime 317 The ValidityTime indicates the time for which the client wants the 318 information to be relevant. Not specifying a ValidityTime means that 319 the server should use the current time. For example, when asking for 320 validation of a certificate, the client might ask "was this certificate 321 valid at this time". The information in the CertReply item in the 322 response MUST be formatted as if the server created the response at the 323 time indicated in the ValidityTime, if the server doesn't have 324 historical information about that time, it MAY either return an error 325 or return information for a later time. A client MUST be able to handle 326 responses that have ThisUpdate items that are later than the requested 327 ValidityTime. 329 3.20 RequestNonce 331 The RequestNonce item is an identifier generated by the client for the 332 request; the server MUST return the same RequestNonce in the signed 333 part of the server's response. The RequestNonce item is simply a 334 sequence of octets. The client SHOULD include a RequestNonce item in 335 every request to prevent an attacker acting as a man-in-the-middle from 336 replaying old responses from the server. The value of the nonce SHOULD 337 change with every request sent from the client. 339 3.22 RequestSignature 341 The RequestSignature item is the signature of the PSRequest item. The 342 details of how a RequestSignature is computed is defined in the 343 specific sections which describe how a request/response is represented 344 in various formats. 346 4. Responses 348 A SCVP server's response to the client MUST be a single FullResponse 349 item. The FullResponse item contains the entire response. A 350 FullResponse item is carried in an application/scvp-response MIME body 351 part. 353 4.1 FullResponse 355 The FullResponse item encapsulates the server's response. The 356 FullResponse item contains a PSResponse item and an optional 357 ResponseSignature item. 359 4.2 PSResponse 361 The PSResponse item contains the part of the server's response that is 362 signed by the ResponseSignature item. The item contains a Version 363 item, a ProducedAt item, a ResponseStatus item, and a RequestHash 364 item. The item can also contain an optional ReplyObjects item, an 365 optional RequestNonce item, and an optional RespExtensions item. The 366 PSResponse item MUST contain exactly one CertReply item for each 367 certificate requested in the request. The RequestNonce item MUST be 368 included if the request had a RequestNonce item. 370 4.3 ProducedAt 372 The ProducedAt item tells the time at which the whole response was 373 produced. The ProducedAt item represents the date at UTC. 375 4.4 ResponseStatus 377 The ResponseStatus item gives status information to the client about 378 its request. The ResponseStatus item has a numeric status code and an 379 optional string that is a sequence of characters from the ISO/IEC 380 10646-1 character set encoded with the UTF-8 transformation format 381 defined in [UTF8]. 383 The optional string may be used to transmit status information, but it 384 is optional. The client MAY choose to display the string to the client. 385 However, because there is no way to know the languages understood by 386 the user, the string may be of little or no use to them. 388 The complete list of status codes for the ResponseStatus item is: 390 0 The request was fully processable 391 1 The request included unrecognized items; continuing 393 10 Too busy; try again later 395 20 The structure of the request was wrong 396 21 The version of request is not supported by this server 397 22 The request included unrecognized items; aborting 398 23 The key given in the RequestSignature is not recognized 399 24 The signature did not match the body of the request 400 25 The encoding was not understood 401 26 The request was not authorized 403 4.4a RequestHash 405 The RequestHash item is the SHA-1 hash of the PSRequest item. The 406 RequestHash item serves the following purposes: 408 - It helps a client know that the request was not maliciously modified 409 when the client gets the response back 411 - It allows the client to associate a response with a request when 412 using connectionless protocols 414 The purpose of the RequestHash is not for authentication of the 415 client. 417 The server MUST return the RequestHash item in the response. 419 4.5 ReplyObjects 421 The ReplyObjects item returns objects to the client. In this 422 specification, the ReplyObjects item is always a CertReply, which tells 423 the client about a single certificate from the request. The CertReply 424 item contains a Cert item identifying the certificate, a 425 ReplyStatus item, a ThisUpdate item, and a NextUpdate item. There may 426 also be the following optional items: ValidationStatus, 427 RevocationStatus, PublicKey, CertSubject, ValidationChain, 428 RevocationProof, and SingleReplyExtensions. 430 The presence or absence of the ValidationStatus, RevocationStatus, 431 PublicKey, CertSubject, ValidationChain, and RevocationProof items in 432 the CertReply item is controlled by the TypesOfCheck, and WantBack 433 items in the request. A server MUST include one of the above items for 434 each related item requested in the TypesOfCheck, and WantBack items. 436 4.6 ReplyStatus 438 The ReplyStatus item gives status information to the client about the 439 request for the specific certificate. Note that the ResponseStatus item 440 is different than the ReplyStatus item. The ResponseStatus item is the 441 status of the whole request, while the ReplyStatus item is the status 442 for the individual certificate. 444 The complete list of status codes for the ReplyStatus item is: 446 0 Success: a definitive answer follows 447 1 Failure: the certificate type is not recognized 448 2 Failure: an item wanted in TypesOfCheck is not recognized 449 3 Failure: an item wanted in WantBack is not recognized 450 4 Failure: the certificate was malformed 451 5 Failure: the mandatory PolicyID is not recognized 452 6 Failure: the ConfigurationIdentifier is not recognized 453 7 Failure: unauthorized request 455 Status code 4 is used to tell the client that the request was properly 456 formed but the certificate in question was not. This is useful to 457 clients that cannot parse a certificate. 459 4.7 ThisUpdate 461 The ThisUpdate item tells the time at which the information in the 462 CertReply was correct. The ThisUpdate item represents the date as 463 UTC. 465 4.8 NextUpdate 467 The NextUpdate item tells the time until which the server expects the 468 information in the CertReply to be valid. The NextUpdate item 469 represents the date at UTC. [[[Is there a desire for another item that 470 says "the server takes liability for this response up to this 471 particular time?]]] 473 4.9 ReplyTypesOfCheck 475 The ReplyTypesOfCheck contains the responses to the client's 476 TypesOfCheck item in the request. It has the same form as the 477 Extensions item, and the OIDs in the ReplyTypesOfCheck item MUST match 478 the OIDS in the TypesOfCheck item. 480 The value for path validation to a trusted root, {type-arc 0}, can be 481 one of the following: 483 0 Valid 484 1 Not valid 485 2 Unknown 487 The value for the revocation status, {type-arc 1}, can be one of the 488 following: 490 0 Good 491 1 Revoked 492 2 Unknown 494 4.10 ReplyWantBack 496 The ReplyWantBack contains the responses to the client's WantBack item 497 in the request. It has the same form as the Extensions item, and the 498 OIDs in the ReplyWantBack item MUST match the OIDS in the WantBack 499 item. 501 The value for the certificate chain used to validate the certificate 502 in the request, {want-arc 1}, is a CertBundle item. 504 The value for the proof of revocation status, {want-arc 2}, is a 505 RevocationProof item. 507 4.11 RevocationProof 509 The RevocationProof item gives the client the proof that the server 510 used to check revocation. The structure of the RevocationProof item is 511 the same as an Extensions item. The OIDs in the RevocationProof item 512 are the same as those in the RevocationInfo item. 514 4.12 ResponseSignature 516 The ResponseSignature item is the signature of the PSResponse item. 518 The client SHOULD check the signature on every signed message it 519 receives from the server. In order to check the signature, the client 520 MUST know and rely on the public signing key of the server. The client 521 could have obtained the server's public key through an out-of-band 522 mechanism of direct trust or through a certificate that chains to a 523 root that the client trusts to delegate this type of authority. 525 5. ASN.1 Syntax for SCVP 527 This section defines the syntax for SCVP messages. The semantics for 528 the messages are defined in sections 2, 3, and 4. 530 5.1 Signatures in ASN.1 532 Signatures in ASN.1 are done over the DER encoding of the 533 PSRequest/PSResponse item. The Name is the distinguished name of the 534 signer. The SignatureAlgorithm is the 535 algorithm used to sign the request, and a SignatureBits item that is 536 the signature itself. The signature may also contain an 537 optional CertBundle that represents a chain of certs to verify the key used 538 to sign the request. 540 5.1.1 SignatureAlgorithm 542 The SignatureAlgorithm identifies the algorithm used to sign a request 543 or response. The SigningAlgorithm item contains the OID of the 544 algorithm and any necessary parameters for the algorithm. 546 5.1.2 SignatureBits 548 The SignatureBits item holds the octets of a signature. The structure 549 of the SignatureBits item is determined by the value of the 550 SignatureAlgorithm item. 552 5.2 ASN.1 Module definition 554 SCVP DEFINITIONS EXPLICIT TAGS ::= 556 BEGIN 558 IMPORTS 560 -- Directory Authentication Framework (X.509) 561 Certificate, AlgorithmIdentifier 562 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 563 module(1) authenticationFramework(7) 3 } 565 -- PKIX Imports 566 Name, Extensions, 567 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 568 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 569 id-mod(0) id-pkix1-explicit-88(1)}; 571 FullRequest ::= SEQUENCE { 572 psRequest PSRequest, 573 requestSignature [0] Signature OPTIONAL 574 } 576 PSRequest ::= SEQUENCE { 577 version INTEGER, 578 query Query, 579 typesOfCheck TypesOfCheck, 580 wantBack WantBack, 581 requestNonce [1] OCTET STRING OPTIONAL, 582 reqExtensions [2] Extensions OPTIONAL 583 } 585 Query ::= CHOICE { 586 certsQuery [0] CertsQuery 587 } 589 CertsQuery ::= SEQUENCE { 590 queriedCerts SEQUENCE SIZE (1..MAX) OF Cert, 591 validityTime [0] GeneralizedTime OPTIONAL, 592 intermediateCerts [1] SEQUENCE SIZE (1..MAX) OF Cert OPTIONAL, 593 trustedCerts [2] CertBundle OPTIONAL, 594 revocationInfo [3] Extensions OPTIONAL, 595 policyID [4] UTF8String OPTIONAL, 596 configurationIdentifier [5] OBJECT IDENTIFIER OPTIONAL, 597 queryExtensions [6] Extensions OPTIONAL 598 } 600 CertBundle ::= SEQUENCE SIZE (1..MAX) OF Cert 602 Cert ::= CHOICE { 603 pkixCert [0] Certificate 604 } 606 TypesOfCheck ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 608 WantBack ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER 610 Signature ::= SEQUENCE { 611 signerName Name, 612 signatureAlgorithm AlgorithmIdentifier, 613 signatureBits BIT STRING, 614 certs [0] CertBundle OPTIONAL 615 } 617 FullResponse ::= SEQUENCE { 618 psResponse PSResponse, 619 responseSignature [0] Signature OPTIONAL 620 } 622 PSResponse ::= SEQUENCE { 623 version INTEGER, 624 producedAt GeneralizedTime, 625 responseStatus ResponseStatus, 626 requestHash OCTET STRING, 627 replyObjects [0] ReplyObjects OPTIONAL, 628 requestNonce [2] OCTET STRING OPTIONAL, 629 respExtensions [3] Extensions OPTIONAL 630 } 632 ResponseStatus ::= SEQUENCE { 633 statusCode INTEGER, 634 errorMessage [0] UTF8String OPTIONAL 635 } 637 ReplyObjects ::= CHOICE { 638 certReplies [0] SEQUENCE SIZE (1..MAX) OF CertReply 639 } 641 CertReply ::= SEQUENCE { 642 cert Cert, 643 replyStatus ReplyStatus, 644 thisUpdate GeneralizedTime, 645 nextUpdate GeneralizedTime, 646 replyTypesOfCheck [0] Extensions OPTIONAL, 647 replyWantBack [1] Extensions OPTIONAL, 648 singleReplyExtensions [2] Extensions OPTIONAL 649 } 651 ReplyStatus ::= ENUMERATED { 652 success (0), 653 certTypeUnrecognized (1), 654 typeOfCheckUnrecognized (2), 655 wantBackUnrecognized (3), 656 certMalformed (4), 657 policyIDUnrecognized (5), 658 configInfoUnrecognized (6), 659 unauthorizedRequest (7) 660 } 662 -- Need to include type-arc, want-arc, and revinfo-arc 664 END 666 6. XML Syntax for SCVP 668 This section defines the syntax for SCVP messages. The semantics for 669 the messages are defined in sections 2, 3, and 4. 671 TODO: We need to import the XML DSig data into our DTD. We also need 672 to provide more information about the format of the elements which map 673 to PCDATA. 675 Note: this is the second attempt at XML for SCVP. We invite any comments 676 on it. 678 6.1 Signatures in XML 680 Signatures are done using [XMLDSIG]. 682 6.2 Namespaces 684 The XML namespace [XML-ns] URI that MUST be used by implementations of 685 this (dated) specification is: 687 xmlns="http://www.ietf.org/pkixwg/01/scvp" 689 6.3 XML Request/Response syntax 691 694 696 699 700 706 709 711 713 722 724 726 728 730 732 734 736 738 740 742 744 746 748 750 752 754 756 758 760 762 764 767 769 777 780 782 785 787 789 791 793 795 797 805 807 809 811 813 814 824 826 6.3 Example of XML syntax 828 830 832 833 834 1 835 836 837 838 839 840 MIICEzCCAb0CAgfYMA0GCSqGSIb3D 841 QEBBAUAMIGTMQswCQYDVQQGEwJLTz 842 . . . 843 oeedsN6iA4IhpA4Ev2rWiM92OoKag 844 UvVGaQoBuDkz7JfYNw== 845 846 847 849 850 19991232235959 851 852 854 855 856 857 MIICEzCCAb0CAgfYMA0GCSqGSIb3D 858 QEBBAUAMIGTMQswCQYDVQQGEwJLTz 859 . . . 860 oeedsN6iA4IhpA4Ev2rWiM92OoKag 861 UvVGaQoBuDkz7JfYNw== 862 863 865 867 868 870 871 1.3.5.5.5.2.5.2 872 874 875 1.3.5.5.5.2.5.2 876 877 2888475218934 878 879 880 1.5.4.5.9.12.1 881 192812 882 883 885 887 888 889 891 893 894 895 897 898 899 901 a23bcd43 902 903 904 dd2323dd 905 906 907 908 C=US, ST=Illinois, L=Chicago, O=Aromatic 909 Penguin Playing Basketball, OU=Certificate 910 Authority, CN=www.ceramic.com 911 2007 912 913 914 MIICITCCAcsCAgfXMA0GCSqGSIb3DQEBBAUAMIGaMQswCQYDVQQG 915 EwJVUzERMA8GA1UECBMISWxsaW5vaXMxEDAOBgNVBAcTB0NoaWNh 916 . . . 917 bD2d2MixUSENihcgGbCEikUpNrMREO/eYkyKsiqmzAxlr3Tu/eKB 918 NBeu 919 920 921 922 923 925 TODO: Need to add an example of a response 927 7. Security Considerations 929 A client that trusts a server's responses for validation of 930 certificates inherently trusts that server as much as it would trust 931 its own validation software. This means that if an attacker compromises 932 a trusted SCVP server, the attacker can change the validation 933 processing for every client that relies on that server. Thus, an SCVP 934 server must be protected at least as well as the weakest root server 935 that the SCVP server trusts. 937 If the client does not check the signature on the response, a 938 man-in-the-middle attack could fool the client into believing modified 939 responses from the server, or responses to questions the client did not 940 ask. This attack does not affect the usefulness of some responses (such 941 as a response that returns a certificate path that the client will 942 validate itself) but does affect things such as a validation response. 944 If the client does not include a RequestNonce item, or if the client 945 does not check that the RequestNonce in the reply matches that in the 946 request, an attacker can replay previous responses from the server. 947 This attack can also be mounted, even with signed requests, if the 948 server does not keep track of previous RequestNonce items. 950 If the server does not require some sort of authorization (such as 951 signed requests), an attacker can get the server to reply to arbitrary 952 requests. Such responses may give the attacker information about 953 weaknesses in the server or about the timeliness of the server's 954 checking. This information may be valuable for a future attack. 956 A. References 958 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement 959 Levels", RFC 2119. 961 [OCSP] "PKIX Online Certificate Status Protocol (OCSP)", RFC 2560. 963 [OpenPGP] "OpenPGP Message Format", RFC 2440. 965 [PKIX] "PKIX Certificate and CRL Profile", RFC 2459. 967 [SHA-1] "Secure Hash Standard", NIST FIPS publication 180-1, April 968 1995. 970 [UTF8] "UTF-8, a transformation format of ISO 10646", RFC 2279. 972 [XMLDSIG] NEED THE REFERENCE 974 B. Acknowledgments 976 The lively debate in the PKIX Working Group also had a significant 977 impact on the types of items described in this protocol. Denis Pinkas 978 suggested some additional requirements for the protocol, and Mike Myers 979 helped point out sections that needed clarification. 981 C. Changes Between Versions of This Document 983 C.1 Differences between -00 and -01 985 1: Rewrote to both narrow focus and to explain the goals more fully. 987 1.1: Removed second paragraph. 989 2: Removed the discussion of the two syntaxes. 991 3: Reorganized the section to put the Extensions items after the 992 CertsQuery items. The section numbers below are from the -00 draft. 993 Throughout the section, made RequestHash mandatory instead of optional. 994 Added RevocationInfo item. Changed CertID to CertHash throughout. 995 Fixed the names of the parts of the signature to match the text. 997 3.1: Split the item into a TBSRequest followed by the hash and/or 998 signature. Changed the order of the extensions item so that all the 999 optional items were together. Changed CertsQuery into Query. Added the 1000 ValidityTime item. 1002 3.3: Redefined Extension to be Extensions to be more similar to 1003 Extensions in PKIX. Other wording changes. 1005 3.5: Gave more explanation for the ExtensionCritical bit, and made 1006 the values boolean. Note that this item may disappear, depending 1007 on discussion of the open issue on it. 1009 3.7: Changed CertsQuery into Query and described the one defined 1010 instance as CertsQuery. Moved the TypesOfCheck and WantBack from the 1011 Query and up one level to the TBSRequest. 1013 3.9: Removed OpenPGP cert, but allowed for it to be added back in the 1014 future. 1016 3.10: Removed OpenPGP cert hash, but allowed for it to be added back in 1017 the future. 1019 3.11 Made TypesOfCheck OIDs. 1021 3.12: Made WantBack OIDs. Removed the public key and the names. 1023 3.10: Added sentence about when a client might include a CertHash item 1024 in the TrustedRoots. 1026 3.13: Clarified use of IntermediateCerts 1028 3.18: Added wording that the RequestHash should not be used for 1029 authentication. 1031 3.19: Changed wording to make it clear that RequestSignature was needed 1032 only for authentication of the client. 1034 3.23: Clarified purpose of KeyID. 1036 4: The section numbers below are from the -00 draft. Throughout the 1037 section, made returning the RequestHash mandatory because it is now 1038 mandatory in the request. 1040 4.1: Split the item into a TBSResponse followed by the hash and/or 1041 signature. Made ResponseSignature mandatory. Made the items returned in 1042 the form of Extensions to match the fact that TypesOfCheck and WantBack 1043 are now sequences of OIDs. 1045 4.3: Made the status code a single number. 1047 4.4 Removed the subject names and public keys. Added NextUpdate. 1049 4.10: Clarified that CertSubject for PKIX certs must contain both the 1050 subject name and the subjectAltName. 1052 4.13: Made ResponseSignature mandatory; this might be changed back to 1053 optional for some types of responses in a future revision of the spec. 1054 Added a discussion of how the client can get the server's signing key. 1056 Old 5: Removed tiny syntax, renumbered old 6 to 5. 1058 5: Added note about semantics in 2-4. 1059 Split FullRequest into FullRequest and TBSRequest. 1060 Moved the extensions item in FullRequest. 1061 Changed the certsQuery to Query. 1062 Move TypesOfCheck and WantBack up to TBSRequest. 1063 Made TypesOfCheck and WantBack SEQUENCE of OIDs. 1064 Added ValidityTime. 1065 Changed "CertID" to "CertHash". 1066 Made the status code a single number. 1067 Added reminder in CertItem about full certs. 1068 Changed order of Signature items. 1069 Split FullResponse into FullResponse and TBSResponse. 1070 Added ReplyTypesOfChecks and ReplyWantBack items. 1071 Added Extensions item and sub-items. 1073 7: Updated to reflect mandatory RequestHash and ResponseSignature. 1074 Added explicit words about compromise of the SCVP server. Removed the 1075 first paragraph because it was confusing and will be fixed in later 1076 versions of the draft. 1078 A: Added reference to OCSP. 1080 D: Updated. 1082 C.2 Difference between -01 and -02 1084 Abstract: Updated to include design goals. 1086 Throughout: Changed TBSRequest to PSRequest. Changed UsageID to 1087 PolicyID. Changed Greenwich Mean Time to UTC. 1089 1.2: Changed wording to match RFC 2119. 1091 1.3: Removed first open issue (cert hashes) because we removed cert 1092 hashes. Removed third open issue (optional response signing) because 1093 the draft now clarifies which responses must be signed and which ones 1094 don't. Added new open issue (making signatures on responses optional). 1096 3.1: Removed the RequestHash from the request. 1098 3.2: Removed the RequestHash from the request. Added explanation of 1099 PSRequest name. Added SignerName here. 1101 3.4: Added note about other types of queries being added in the future. 1103 3.5: Removed CertHash. 1105 3.7: Removed the CertHash item. Filled in the hole that would have been 1106 created with SignerName from below. 1108 3.10: Minor edit to last line. 1110 3.12: Removed most of the second paragraph because it was confusing. 1112 3.14: Removed the arc stuff. 1114 3.15: Made the PolicyID be a URL instead of an OID. 1116 3.17: Removed the arc stuff. Also added last sentence after the list. 1118 3.18: Removed the arc stuff. 1120 3.19: Removed the surperfluous NextUpdate from the last sentence. 1121 Detailed what no ValidityTime request means. Changed what should happen 1122 if the client requests information for a time that the server does not 1123 have. 1125 3.21: Changed last sentence to indicate that the RequestHash is only 1126 returned in the response, not sent in the request. 1128 3.22: Removed the last sentence because the RequestHash is only 1129 returned in the response, not sent in the request. Moved the second 1130 paragraph up to 3.2 to make it clearer why someone might or might not 1131 sign their request. Got rid of the optional KeyID. Removed the 1132 SignerName. 1134 3.23: Moved SignerName up in the document to 3.7. Renumbered the rest 1135 of this section. 1137 3.26: Got rid of KeyID item. 1139 4.2: Added SignerName here. 1141 4.4: Got rid of 11 and 12 and made the description of 10 more sensible. 1142 Changed 25 to "encoding not understood". 1144 4.5: Removed the last sentence because it was confusing. 1146 4.9: Got rid of "temporarily unknown". 1148 4.12: Made the response signature optional in the first sentence of the 1149 second paragraph. Got rid of KeyID. Removed the SignerName. 1151 5: Removed RequestHash from FullRequest. Removed CertItem and made 1152 CertBundle a SEQUENCE OF Cert. Changed type of policyID to UTF8string 1153 to hold the URL. Got rid of KeyID. Moved signerName out of Signature 1154 and into PSRequest and TBSResponse, and made it optional. 1156 6: Added the XML syntax and example. 1158 7: Removed the second paragraph because it dealt with RequestHash in 1159 the request. 1161 C.3 Difference between -02 and -03 1163 1. Changed TBSResponse and TBSRequest to PSResponse and 1164 PSRequest. Made signatures optional in both requests and responses. 1166 2. Added a tag to the optional signatures in both requests and 1167 responses. 1169 3. Changed RevocationInfos to RevocationInfo. 1171 4. Removed CertHash completely. 1173 5. Simplified section 3.5, since FullCert has gone away 1175 6. Replaced section 3.6 to talk about Cert, rather than FullCert 1177 7. Replaced ExtensionParameter with ExtensionValue in Section 3.11. 1179 8. Made sure that all SEQUENCE OF are SEQUENCE SIZE (1..MAX) OF 1181 9. Import Extension and used the same definition for Extension as in 1182 RFC2459 1184 10. Replace "trusted root" with "trusted certificate", because a 1185 server or client might decide to put its trust in a certificate that 1186 might not be self-signed. Replaced trustedRoot with trustedCert. 1188 11. Fixed once occurance of definition of requestNonce 1190 12. Removed scvp, scvpReq and scvpResp tags in the XML. 1192 13. Removed the last 2 sentences of the second paragraph Section 3.4 1194 14. Changed last sentence of section 3.13, since you have have multiple 1195 cert chains for a certificate even if there is no cross certification. 1197 15. Changed last sentence of section 3.17. 1199 16. Moved section 3.21 to the response section - 4.4a. We need to 1200 renumber all sections when we are close to being done. 1202 17. Added a default value for the attribute value of ReplyStatus in 1203 the XML. 1205 18. Added IMPORTS to the ASN.1 module. 1207 19. Gave the extensions in different places different names. 1209 20. Changed the way criticality is specified for Extension in XML 1211 21. Added the mime type registration requests 1213 22. Added appendix E and moved Author Information to appendix F 1215 23. Moved signerName from the PSRequest and PSResponse to the 1216 signature part. 1218 24. Removed the second paragraph in section 3.13. 1220 25. Changed a line in section 3.14, first para (about where a client 1221 may have obtained an OCSP response to send to the SCVP server). 1223 26. Got rid of the multiple places where we say what is signed by the 1224 RequestSignature or ResponseSignature (e.g. section 3.1 and 3.2). Also 1225 simplified the definition of the RequestSignature and 1226 ResponseSignature in sections 3 and 4. The should be defined in detail 1227 in the encoding sections. 1229 D. MIME Registrations 1231 D.1 application/scvp-request 1233 To: ietf-types@iana.org 1234 Subject: Registration of MIME media type application/scvp-request 1236 MIME media type name: application 1238 MIME subtype name: scvp-request 1240 Required parameters: None 1242 Optional parameters: None 1244 Encoding considerations: binary or XML 1246 Security considerations: Carries a request for information. This 1247 request may optionally be cryptographically signed. 1249 Interoperability considerations: None 1251 Published specification: IETF PKIX Working Group Draft on Simple 1252 Certificate Validation Protocol - SCVP 1254 Applications which use this media type: SCVP clients 1256 Additional information: 1258 Magic number(s): None 1259 File extension(s): .SCQ 1260 Macintosh File Type Code(s): none 1262 Person & email address to contact for further information: 1263 Ambarish Malpani 1265 Intended usage: COMMON 1267 Author/Change controller: 1268 Ambarish Malpani 1270 D.2 application/scvp-response 1272 To: ietf-types@iana.org 1273 Subject: Registration of MIME media type application/scvp-response 1275 MIME media type name: application 1277 MIME subtype name: scvp-response 1279 Required parameters: None 1281 Optional parameters: None 1282 Encoding considerations: binary or XML 1284 Security considerations: Carries a cryptographically signed response 1286 Interoperability considerations: None 1288 Published specification: IETF PKIX Working Group Draft on Simple 1289 Certificate Validation Protocol - SCVP 1291 Applications which use this media type: SCVP servers 1293 Additional information: 1295 Magic number(s): None 1296 File extension(s): .SCS 1297 Macintosh File Type Code(s): none 1299 Person & email address to contact for further information: 1300 Ambarish Malpani 1302 Intended usage: COMMON 1304 Author/Change controller: 1305 Ambarish Malpani 1307 E. SCVP data format 1309 E.1 SCVP over HTTP 1311 This section describes the formatting that will be done to the 1312 request and response to support HTTP. 1314 E.1.1 Request 1316 HTTP based SCVP requests can the POST method to 1317 submit their requests. Where privacy is 1318 a requirement, SCVP transactions exchanged using HTTP MAY be 1319 protected using either TLS/SSL or some other lower layer protocol. 1321 An SCVP request using the POST method is constructed as follows: The 1322 Content-Type header MUST have the value "application/scvp-request" 1323 while the Content-Length header MUST be present and have the exact 1324 length of the request. The body of the message is the binary value 1325 of the DER encoding of the FullRequest, or XML encoding of 1326 FullRequest. Other HTTP headers MAY be present and MAY 1327 be ignored if not understood by the requestor. 1329 E.1.2 Response 1331 An HTTP-based SCVP response is composed of the appropriate HTTP 1332 headers, followed by the binary value of the DER encoding of the 1333 FullResponse or XML encoding of FullResponse. The Content-Type 1334 header MUST have the value "application/scvp-response". The 1335 Content-Length header MUST be present and specify 1336 the length of the response. Other HTTP headers MAY be present and MAY 1337 be ignored if not understood by the requestor. 1339 F. Author Contact Information 1341 Ambarish Malpani 1342 ValiCert, Inc. 1343 339 N. Bernardo Ave. 1344 Mountain View, CA 94043 1345 ambarish@valicert.com 1347 Paul Hoffman 1348 VPN Consortium 1349 127 Segre Place 1350 Santa Cruz, CA 95060 USA 1351 paul.hoffman@vpnc.org