idnits 2.17.1 draft-ietf-pkix-ocsp-04.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** 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 853 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 71 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- The document date (June 1998) is 9447 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 744 -- Looks like a reference, but probably isn't: '1' on line 739 -- Looks like a reference, but probably isn't: '2' on line 740 == Unused Reference: 'HTTP' is defined on line 570, but no explicit reference was found in the text == Unused Reference: 'MUSTSHOULD' is defined on line 574, but no explicit reference was found in the text == Unused Reference: 'URL' is defined on line 577, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2068 (ref. 'HTTP') (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 1738 (ref. 'URL') (Obsoleted by RFC 4248, RFC 4266) Summary: 14 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group Michael Myers(VeriSign) 2 draft-ietf-pkix-ocsp-04.txt Rich Ankney (CertCo) 3 Ambarish Malpani (ValiCert) 4 Slava Galperin (Teknowledge) 5 Carlisle Adams (Entrust Technologies) 7 Expires in 6 months June 1998 9 X.509 Internet Public Key Infrastructure 10 Online Certificate Status Protocol - OCSP 11 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress." 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 1. Abstract 33 This document specifies a protocol useful in determining the current 34 status of a digital certificate without requiring CRLs. Additional 35 mechanisms addressing PKIX operational requirements are specified in 36 separate documents. 38 Section 2 provides an overview of the protocol. Section 3 establishes 39 functional requirements, while section 4 provides details of the 40 protocol. In section 5 we cover security issues with the 41 protocol. Appendix A demonstrates OCSP over HTTP and appendix B 42 accumulates ASN.1 syntactic elements. 44 2. Protocol Overview 46 In lieu of or as a supplement to checking against a periodic CRL, it 47 may be necessary to obtain timely status regarding a certificate's 48 revocation state (cf. PKIX Part 1, Section 3.3). Examples include 49 high- value funds transfer or large stock trades. 51 The Online Certificate Status Protocol (OCSP) enables applications to 52 determine the revocation state of an identified certificate. OCSP may 53 be used to satisfy some of the operational requirements of providing 54 more timely revocation information than is possible with CRLs. An 55 OCSP client issues a status request to an OCSP responder and suspends 56 acceptance of the certificate in question until the responder provides 57 a response. 59 This protocol specifies the data that needs to be exchanged between an 60 application checking the revocation status of a certificate and the 61 server providing that status. 63 2.1 Request 65 An OCSP request contains the following data: 67 - protocol version 68 - service request 69 - target certificate identifier or a single end-entity certificate 70 - optional extensions which MAY be processed by the OCSP Responder 72 Upon receipt of a request, an OCSP Responder determines if: 1) the 73 message is well formed, 2) the responder is configured to provide the 74 requested service and 3) the request contains the information needed 75 by the responder. If any one of the prior conditions are not met, the 76 OCSP responder produces an error message; otherwise, it returns a 77 definitive response. 79 2.2 Response 81 OCSP responses can be of various types. However, there is one basic 82 type of OCSP response that MUST be supported by all OCSP servers and 83 clients. The rest of this section only describes this basic response 84 type. 86 An OCSP response consists of a response type and the bytes of the 87 actual response. All definitive response messages SHALL be digitally 88 signed. The key used to sign the response MUST belong to one of the 89 following: 91 - the CA who issued the certificate in question 92 - a Trusted Responder whose public key is trusted by the requester 93 - a CA Designated Responder (Authorized Responder) who holds a special 94 certificate issued by the CA indicating that it may issue OCSP responses 95 for that CA 97 A definitive response message is composed of: 99 - version of the response 100 - name of the responder 101 - responses for each of the certificates in a request 102 - optional extensions 103 - signature algorithm OID 104 - signature computed across hash of the response 106 The response for each of the certificates in a request consists of 108 - target certificate identifier 109 - certificate status value 110 - response validity interval 111 - optional extensions 113 This specification defines the following definitive response indicators 114 for use in the certificate status value: 115 - notRevoked 116 - revoked 117 - unknown 119 The notRevoked state indicates that the certificate is not revoked. It 120 does not necessarily mean that the certificate was ever issued. Nor 121 does it mean that the certificate is in its validity interval. A 122 notRevoked state by an OCSP responder DOES NOT absolve the application 123 of the responsibility of checking that the certificate is in its 124 validity period and has been correctly signed. For example, it is 125 quite possible that an OCSP responder returns the notRevoked state if 126 a certificate was revoked, but has since expired (equivalent to a 127 serial number being dropped from the CRL). 129 The revoked state indicates that the certificate has been revoked. 131 The unknown state indicates that the responder doesn't know about the 132 certificate being requested. 134 2.3 Exception Cases 136 In case of errors, the OCSP Responder may return an error message. 137 Errors can be of the following types: 139 - malformedRequest 140 - internalError 141 - tryLater 142 - certRequired 143 - sigRequired 145 A server produces the malformedRequest response if the request 146 received does not conform to the OCSP syntax. 148 The response internalError indicates that the OCSP responder reached 149 an inconsistent internal state. The query should be retried, 150 potentially with another responder. 152 In the event that the OCSP responder is operational, but unable to 153 return a status for the requested certificate, the tryLater response 154 can be used to indicate that the service exists, but is temporarily 155 unable to respond. 157 The response certRequired is returned in cases where the server 158 requires the client to supply the certificate data itself in order to 159 construct a response. 161 The response sigRequired is returned in cases where the server 162 requires the client sign the request in order to construct a response. 164 2.4 Semantics of thisUpdate, nextUpdate and producedAt 166 Responses can contain three times in them - thisUpdate, nextUpdate and 167 producedAt. The semantics of these fields are: 169 - thisUpdate: the time at which the status being indicated is 170 known to be correct 171 - nextUpdate: the time at or before which newer information will 172 be available about the status of the certificate 173 - producedAt: the time at which the OCSP responder signed this 174 response. 176 If nextUpdate is not set, the responder is indicating that newer 177 revocation information is available all the time. 179 2.5 Response Pre-production 181 OCSP responders MAY pre-produce signed responses specifying the status 182 of certificates at a specified time. The time at which the status was 183 known to be correct SHALL be reflected in the thisUpdate field of the 184 response. The time at or before which newer information will be 185 available is reflected in the nextUpdate field, while the time at 186 which the response was produced will appear in the producedAt field of 187 the response. 189 2.6 OCSP Signature Authority Delegation 191 The key that signs a certificate's revocation information need not be 192 the same key that signed the certificate. A certificate's issuer 193 explicitly delegates OCSP signing authority by issuing a certificate 194 containing a unique value for extendedKeyUsage in the OCSP signer's 195 certificate. 197 3. Functional Requirements 199 3.1 Certificate Content 201 In order to convey to OCSP clients a well-known point of information 202 access, CAs SHALL provide the capability to include the 203 AuthorityInfoAccess extension (defined in PKIX Part 1, section 204 4.2.2.1) in certificates that can be checked using OCSP. 205 Alternatively, the accessLocation for the OCSP provider may be 206 configured locally at the OCSP client. 208 CAs that support an OCSP service, either hosted locally or provided by 209 an Authorized Responder, MAY provide a value for a 210 uniformResourceIndicator (URI) accessLocation and the OID value 211 id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE. 213 The value of the accessLocation field in the subject certificate 214 defines the transport (e.g. HTTP) used to access the OCSP responder 215 and may contain other transport dependent information (e.g. a URL). 217 3.2 Error Responses 219 Upon receipt of a request which fails to parse, the receiving OCSP 220 responder SHALL respond with an error message. 222 3.3 Signed Response Acceptance Requirements 224 Prior to accepting a signed response as valid, OCSP clients SHALL 225 confirm that: 227 a. The certificate identified in a received response corresponds to 228 that which was identified in the corresponding request; 229 b. The signature on the response is valid; 230 c. The identity of the signer matches the intended recipient of the 231 request. 232 d. The signer is currently authorized to sign the response. 233 e. The response is in its validity period. 235 4. Detailed Protocol 237 The ASN.1 syntax imports terms defined in the X.509 Certificate and 238 CRL Profile Internet Draft. For signature calculation, the data to be 239 signed is encoded using the ASN.1 distinguished encoding rules (DER) 240 [X.690]. 242 ASN.1 EXPLICIT tagging is used as a default unless specified otherwise. 244 The terms imported from elsewhere are: Extensions, 245 CertificateSerialNumber, SubjectPublicKeyInfo, Name, 246 AlgorithmIdentifier, CRLReason 248 4.1 Requests 250 This section specifies the ASN.1 specification for a confirmation 251 request. The actual formatting of the message could vary depending on 252 the transport mechanism used (HTTP, SMTP, LDAP, etc.). 254 4.1.1 Request Syntax 256 OCSPRequest ::= SEQUENCE { 257 tbsRequest TBSRequest 258 optionalSignature [0] Signature OPTIONAL } 260 TBSRequest ::= SEQUENCE { 261 version [0] EXPLICIT Version DEFAULT v1, 262 requestList SEQUENCE OF Request, 263 requestExtensions [1] EXPLICIT Extensions OPTIONAL } 265 Signature ::= SEQUENCE { 266 signatureAlgorithm AlgorithmIdentifier, 267 signature BIT STRING, 268 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL 269 } 271 Version ::= INTEGER { v1(0) } 273 Request ::= SEQUENCE { 274 reqCert RequestedCert, 275 singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } 277 RequestedCert ::= CHOICE { 278 certID [0] EXPLICIT CertID, 279 cert [1] EXPLICIT Certificate } 281 CertID ::= SEQUENCE { 282 hashAlgorithm AlgorithmIdentifier, 283 issuerNameHash OCTET STRING, -- Hash of Issuer's DN 284 issuerKeyHash OCTET STRING, -- Hash of Issuers public key 285 serialNumber CertificateSerialNumber } 287 issuerNameHash is the hash of the Issuer's distinguished name. The 288 hash shall be calculated over the DER encoding of the issuer's name 289 field in the certificate being checked. issuerKeyHash is the hash of 290 the Issuer's public key. The hash shall be calculated over the the 291 value (excluding tag and length) of the subject public key field in 292 the issuer's certificate. 294 4.1.2 Notes on the Request Syntax 296 The primary reason to use both the name and the public key to identify 297 the issuer is that it is possible that two CAs may choose to use the 298 same Name (uniqueness in the Name is a recommendation that cannot be 299 enforced). Two CAs will never, however, have the same public key 300 unless the CAs either explicitly decided to share their private key, 301 or the key of one of the CAs was compromised. 303 While it is possible to identify a certificate by sending over either 304 the entire certificate or just a CertID, it is recommended that 305 clients use just the CertID to reduce the size of the request. 306 However, certain OCSP responders MAY require the entire certificate 307 whose status is to be determined. 309 Support for extensions is OPTIONAL. The critical flag SHOULD NOT be 310 set for any of them. This standard suggests several useful extensions 311 in Section 4.5. Additional extensions MAY be defined in additional 312 RFCs. Unrecognized extensions SHOULD be ignored. 314 Requests may be signed or unsigned. For signed requests, the 315 optionalSignature field is present, while it is absent for unsigned 316 requests. 318 4.2 Response Syntax 320 This section specifies the ASN.1 specification for a confirmation 321 response. The actual formatting of the message could vary depending on 322 the transport mechanism used (HTTP, SMTP, LDAP, etc.). 324 4.2.1 ASN.1 Specification of the OCSP Response 326 An OCSP response at a minimum consists of a responseStatus field 327 indicating the processing status of the prior request. If the value 328 of responseStatus is one of the error conditions, responseBytes are 329 not set. 331 OCSPResponse ::= SEQUENCE { 332 responseStatus OCSPResponseStatus, 333 responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } 335 OCSPResponseStatus ::= ENUMERATED { 336 successful (0), --Response has valid confirmations-- 337 malformedRequest (1), --Illegal confirmation request-- 338 internalError (2), --Internal error in issuer-- 339 tryLater (3), --Try again later-- 340 certRequired (4), --Must supply certificate 341 sigRequired (5) --Must sign the request-- } 343 The value for responseBytes consists of an OBJECT IDENTIFIER and a 344 response syntax identified by that OID encoded as an OCTET STRING: 346 ResponseBytes ::= SEQUENCE { 347 responseType OBJECT IDENTIFIER, 348 response OCTET STRING } 350 For a basic OCSP responder, responseType will be id-pkix-ocsp-basic, 351 where: 353 id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } 354 id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } 356 OCSP responders SHALL be capable of recognizing and responding to the 357 id-pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL 358 be capable of receiving and processing the id-pkix-ocsp-basic response 359 type. 361 The value for response SHALL be the DER encoding of BasicOCSPResponse: 363 BasicOCSPResponse ::= SEQUENCE { 364 tbsResponseData ResponseData, 365 signatureAlgorithm AlgorithmIdentifier, 366 signature BIT STRING, 367 certs [1] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 369 The value for signature SHALL be computed on the hash of the DER 370 encoding ResponseData. 372 ResponseData ::= SEQUENCE { 373 version [0] EXPLICIT Version DEFAULT v1, 374 responderID ResponderID, 375 producedAt GeneralizedTime, 376 responses SEQUENCE OF SingleResponse, 377 responseExtensions [1] EXPLICIT Extensions OPTIONAL } 379 ResponderID ::= CHOICE { 380 byName [0] Name, 381 byKey [1] KeyHash } 383 KeyHash ::= OCTET STRING --SHA-1 hash of responder's public key 384 (excluding the tag and length fields) 386 SingleResponse ::= SEQUENCE { 387 certID certID, 388 certStatus CertStatus, 389 thisUpdate GeneralizedTime, 390 nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, 391 singleExtensions [1] EXPLICIT Extensions OPTIONAL } 393 CertStatus ::= CHOICE { 394 notRevoked [0] IMPLICIT NULL, 395 revoked [1] IMPLICIT RevokedInfo, 396 unknown [2] IMPLICIT UnknownInfo } 398 RevokedInfo ::= SEQUENCE { 399 revocationTime GeneralizedTime, 400 revocationReason [0] EXPLICIT CRLReason OPTIONAL } 402 UnknownInfo ::= NULL -- this can be replaced with an enumeration 404 4.2.2 Notes on OCSP Responses 406 4.2.2.1 Identification of the target certificate in a response 408 In responses, the certificate whose status is being returned, is always 409 identified by the certID, even if the query was specified using the full 410 certificate. 412 4.2.2.2 Time 414 The thisUpdate and nextUpdate fields define a recommended validity 415 interval. This interval corresponds to the {thisUpdate, nextUpdate} 416 interval in CRLs. Responses whose nextUpdate value is earlier than the 417 local system time value SHOULD be considered unreliable. Responses 418 whose thisUpdate time is earlier than the local system time SHOULD be 419 considered unreliable. Responses where the nextUpdate value is not 420 set are equivalent to a CRL with no time for nextUpdate (see section 421 2.3). 423 The producedAt time is the time at which this response was signed. 425 4.2.2.3 Authorized Responders 427 The key that signs a certificate's revocation information need not be 428 the same key that signed the certificate. A certificate's issuer MAY 429 explicitly delegate OCSP signing authority by issuing a certificate 430 including an extendedKeyUsage extension in the OCSP signer's 431 certificate containing the value id-kp-OCSPSigning. 433 id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp ?} 435 4.2.2.3.1 Revocation Checking of an Authorized Responder 437 [Note: The requirement of the following mechanism to actively inhibit a 438 revocation check of an Authorized Responder's certificate needs review 439 and 440 comment by the list.] 442 Since an Authorized OCSP responder provides revocation information for 443 a CA, OCSP clients need to know how to check that an authorized 444 responder's certificate has not been revoked. CAs may choose to deal 445 with this problem in one of three ways: 447 - A CA may specify that an OCSP client can trust a responder for the 448 lifetime of the responder's authorization certificate. The CA does so 449 by including the extension id-pkix-ocsp-nocheck. This SHOULD be a non- 450 critical extension. The value of the extension should be NULL. CAs 451 issuing such a certificate should realized that a compromise of the 452 responder's key, is as serious as the compromise of the CA's key, at 453 least for the validity period of this certificate. CA's may choose to 454 issue this type of certificate with a very short lifetime and renew it 455 frequently. 456 - A CA may specify how the responder's certificate be checked for 457 revocation. This can be done using CRL Distribution Points if the 458 check should be done using CRLs or CRL Distribution Points, or 459 Authority Information Access if the check should be done in some other 460 way. Details for specifying either of these two mechanisms are 461 available in PKIX Part 1. 462 - A CA may choose not to specify any method of revocation checking for 463 the responder's certificate, in which case, it would be up to the OCSP 464 client's local security policy to decide whether that certificate 465 should be checked for revocation or not. 467 4.3 Mandatory and Optional Cryptographic Algorithms 469 Clients that request OCSP services SHALL be capable of processing 470 responses signed used DSA keys identified by the DSA sig-alg-oid 471 specified in section 7.2.2 of PKIX Part 1. Clients SHOULD also be 472 capable of processing RSA signatures as specified in section 7.2.1 of 473 PKIX Part 1. OCSP responders SHALL support the SHA1 hashing 474 algorithm. 476 4.4 Extensions 478 This section defines some standard extensions. Support for all 479 extensions is OPTIONAL. For each extension, the definition indicates 480 its syntax, processing performed by the OCSP Responder, and any 481 extensions which are included in the corresponding response. 483 4.4.1 Nonce 485 The nonce cryptographically binds a request and a response to prevent 486 replay attacks. The nonce is included as one of the requestExtensions 487 in requests, while in responses it would be included as one of the 488 responseExtensions. In both the request and the response, the nonce 489 will be identified by the object identifier id-pkix-ocsp-nonce, while 490 the extnValue is the value of the nonce. 492 id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } 494 4.4.2 CRL References 496 It may be desirable for the OCSP responder to indicate the CRL on 497 which a revoked or onHold certificate is found. This can be useful 498 where OCSP is used between repositories, and also as an auditing 499 mechanism. The CRL may be specified by a URL (the URL at which the CRL 500 is available), a number (CRL number) or a time (the time at which the 501 relevant CRL was created). These extensions will be specified as 502 singleExtensions. The identifier for this extension will be 503 id-pkix-ocsp-crl, while the value will be CrlID. 505 id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } 507 CrlID ::= SEQUENCE { 508 crlUrl [0] EXPLICIT IA5String OPTIONAL, 509 crlNum [1] EXPLICIT INTEGER OPTIONAL, 510 crlTime [2] EXPLICIT GeneralizedTime OPTIONAL } 512 For the choice crlUrl, the IA5String will specify the URL at which the 513 CRL is available. For crlNum, the INTEGER will specify the value of 514 the CRL number extension of the relevant CRL. For crlTime, the 515 GeneralizedTime will indicate the time at which the relevant CRL was 516 issued. 518 4.4.3 Acceptable Response Types 520 An OCSP client MAY wish to specify the kinds of response types it 521 understands. To do so, it SHOULD use an extension with the OID 522 id-pkix-ocsp-response, and the value AcceptableResponses. The OIDs 523 included in AcceptableResponses are the OIDs of the various response 524 types this client can accept (e.g., id-pkix-ocsp-basic). 526 id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 } 528 AcceptableResponses ::= SEQUENCE OF { id OBJECT IDENTIFIER } 530 As noted in section 3.3, OCSP responders SHALL be capable of 531 recognizing and responding to the id-pkix-ocsp-basic response 532 type. Correspondingly, OCSP clients SHALL be capable of receiving and 533 processing the id-pkix- ocsp-basic response type. 535 4.4.4 Other Extensions 537 CRL Entry Extensions - specified in Section 5.3 of PKIX part I - are 538 also supported as singleExtensions. 540 5. Security Considerations 542 For this service to be effective, certificate using systems must 543 connect to the certificate status service provider. In the event such 544 a connection cannot be obtained, certificate-using systems could 545 implement CRL processing logic as a fall-back position. 547 A denial of service vulnerability is evident with respect to a flood 548 of queries. The production of a cryptographic signature significantly 549 affects response generation cycle time, thereby exacerbating the 550 situation. 552 Unsigned error responses open up the protocol to another denial of 553 service attack, where the attacker sends false error responses. 555 The use of precomputed responses allows replay attacks in which an old 556 (notRevoked) response is replayed prior to its expiration date but 557 after the certificate has been revoked. Deployments of OCSP should 558 carefully evaluate the benefit of precomputed responses against the 559 probability of a replay attack and the costs associated its successful 560 execution. 562 The reliance of HTTP caching in some deployment scenarios may result 563 in unexpected results if intermediate servers are incorrectly 564 configured or are known to possess cache management faults. 565 Implementors are advised to take the reliability of HTTP cache 566 mechanisms into account when deploying OCSP over HTTP. 568 6. References 570 [HTTP] Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, 571 J. Gettys, J. Mogul, H. Frystyk and T. Berners-Lee, RFC 2068, January 572 1997. 574 [MUSTSHOULD] Key words for use in RFCs to Indicate Requirement Levels, 575 S. Bradner, RFC 2119, March 1997. 577 [URL] Uniform Resource Locators (URL), T. Berners-Lee, L. Masinter, M. 578 McCahill, RFC 1738, December 1994. 580 7. Author's Address 582 Michael Myers 583 VeriSign, Inc. 584 1390 Shorebird Way 585 Mountain View, CA 94019 586 mmyers@verisign.com 588 Rich Ankney 589 CertCo, LLC 590 13506 King Charles Dr. 591 Chantilly, VA 20151 592 rankney@erols.com 594 Ambarish Malpani 595 ValiCert, Inc. 596 3160 W. Bayshore Drive 597 Palo Alto, CA 94303 598 ambarish@valicert.com 599 650.849.9880 601 Slava Galperin 602 Teknowledge Corporation 603 1810 Embarcadero Road 604 Palo Alto, CA 605 galperin@teknowledge.com 607 Carlisle Adams 608 Entrust Technologies 609 750 Heron Road, Suite E08 610 Ottawa, Ontario 611 K1V 1A7 612 Canada 613 cadams@entrust.com 615 Appendix A 617 A.1 OCSP over HTTP 619 This section describes the formatting that will be done to the request 620 and response to support HTTP. 622 A.1.1 Request 624 HTTP based OCSP requests can use either the GET or the POST method to 625 submit their requests. To enable HTTP caching, small requests (that 626 after encoding are less than 255 bytes), may be submitted using 627 GET. If HTTP caching is not important, or the request is greater than 628 255 bytes, the request should be submitted using POST. 630 A.1.1.1 Requests using GET 631 An OCSP request using the GET method, is constructed as follows: 633 GET {url}/{url-encoding of base-64 encoding of the DER encoding of the 634 OCSPRequest} 636 where {url} may be derived from the value of AuthorityInfoAccess or 637 other local configuration of the OCSP client. 639 A.1.1.2 Requests using POST 641 An OCSP request using the POST method, is constructed as follows: The 642 Content-Type header has the value "application/ocsp-request" while the 643 body of the message is the DER encoding of the OCSPRequest. 645 A.1.2 Response 647 An HTTP-based OCSP response is composed of the appropriate HTTP 648 headers, followed by the DER encoding of the OCSPResponse. The 649 Content-Type header has the value "application/ocsp-response". The 650 Content-Length header SHOULD specify the length of the response. Other 651 HTTP headers MAY be present and MAY be ignored if not understood by 652 the requestor. 654 Appendix B: OCSP in ASN.1 656 OCSP1 DEFINITIONS EXPLICIT TAGS::= 658 BEGIN 660 OCSPRequest ::= SEQUENCE { 661 tbsRequest TBSRequest 662 optionalSignature [0] Signature OPTIONAL } 664 TBSRequest ::= SEQUENCE { 665 version [0] EXPLICIT Version DEFAULT v1, 666 requestList SEQUENCE OF Request, 667 requestExtensions [1] EXPLICIT Extensions OPTIONAL } 669 Signature ::= SEQUENCE { 670 signatureAlgorithm AlgorithmIdentifier, 671 signature BIT STRING, 672 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL 673 } 675 Version ::= INTEGER { v1(0) } 677 Request ::= SEQUENCE { 678 reqCert RequestedCert, 679 singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } 681 RequestedCert ::= CHOICE { 682 certID [0] EXPLICIT CertID, 683 cert [1] EXPLICIT Certificate } 685 CertID ::= SEQUENCE { 686 hashAlgorithm AlgorithmIdentifier, 687 issuerNameHash OCTET STRING, -- Hash of Issuer's DN 688 issuerKeyHash OCTET STRING, -- Hash of Issuers public key 689 serialNumber CertificateSerialNumber } 691 OCSPResponse ::= SEQUENCE { 692 responseStatus OCSPResponseStatus, 693 responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } 695 OCSPResponseStatus ::= ENUMERATED { 696 successful (0), --Response has valid confirmations-- 697 malformedRequest (1), --Illegal confirmation request-- 698 internalError (2), --Internal error in issuer-- 699 tryLater (3), --Try again later-- 700 certRequired (4), --Must supply certificate 701 sigRequired (5) --Must sign the request-- } 703 ResponseBytes ::= SEQUENCE { 704 responseType OBJECT IDENTIFIER, 705 response OCTET STRING } 707 id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } 708 id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } 710 BasicOCSPResponse ::= SEQUENCE { 711 tbsResponseData ResponseData, 712 signatureAlgorithm AlgorithmIdentifier, 713 signature BIT STRING, 714 certs [1] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 716 ResponseData ::= SEQUENCE { 717 version [0] EXPLICIT Version DEFAULT v1, 718 responderID ResponderID, 719 producedAt GeneralizedTime, 720 responses SEQUENCE OF SingleResponse, 721 responseExtensions [1] EXPLICIT Extensions OPTIONAL } 723 ResponderID ::= CHOICE { 724 byName [0] Name, 725 byKey [1] KeyHash } 727 KeyHash ::= OCTET STRING --SHA-1 hash of responder's public key 728 --(excluding the tag and length fields) 730 SingleResponse ::= SEQUENCE { 731 certID certID, 732 certStatus CertStatus, 733 thisUpdate GeneralizedTime, 734 nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, 735 singleExtensions [1] EXPLICIT Extensions OPTIONAL } 737 CertStatus ::= CHOICE { 738 notRevoked [0] IMPLICIT NULL, 739 revoked [1] IMPLICIT RevokedInfo, 740 unknown [2] IMPLICIT UnknownInfo } 742 RevokedInfo ::= SEQUENCE { 743 revocationTime GeneralizedTime, 744 revocationReason [0] EXPLICIT CRLReason OPTIONAL } 746 UnknownInfo ::= NULL -- this can be replaced with an enumeration 748 END 750 Appendix C: MIME registrations 752 C.1 application/ocsp-request 754 To: ietf-types@iana.org 755 Subject: Registration of MIME media type application/ocsp-request 757 MIME media type name: application 759 MIME subtype name: ocsp-request 761 Required parameters: None 763 Optional parameters: None 765 Encoding considerations: will be none for 8-bit transports and most 766 likely 767 Base64 for SMTP or other 7-bit transports 769 Security considerations: Carries a cryptographically signed request 770 for 771 information 773 Interoperability considerations: None 775 Published specification: This document 777 Applications which use this media type: OCSP clients 779 Additional information: 781 Magic number(s): None 782 File extension(s): .ORQ 783 Macintosh File Type Code(s): none 785 Person & email address to contact for further information: 786 Ambarish Malpani 788 Intended usage: COMMON 790 Author/Change controller: 791 Ambarish Malpani 793 C.2 application/ocsp-response 795 To: ietf-types@iana.org 796 Subject: Registration of MIME media type application/ocsp-response 798 MIME media type name: application 800 MIME subtype name: ocsp-response 802 Required parameters: None 804 Optional parameters: None 806 Encoding considerations: will be none for 8-bit transports and most 807 likely 808 Base64 for SMTP or other 7-bit transports 810 Security considerations: Carries a cryptographically signed 811 response 813 Interoperability considerations: None 815 Published specification: This document 817 Applications which use this media type: OCSP servers 819 Additional information: 821 Magic number(s): None 822 File extension(s): .ORS 823 Macintosh File Type Code(s): none 825 Person & email address to contact for further information: 826 Ambarish Malpani 828 Intended usage: COMMON 830 Author/Change controller: 831 Ambarish Malpani 833 --------------B162CADEF92496D4360A91CC--