idnits 2.17.1 draft-ietf-pkix-ocsp-05.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-27) 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. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages 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 is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 42 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 (August 1998) is 9387 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 775 -- Looks like a reference, but probably isn't: '1' on line 770 -- Looks like a reference, but probably isn't: '2' on line 771 == Unused Reference: 'HTTP' is defined on line 596, but no explicit reference was found in the text == Unused Reference: 'MUSTSHOULD' is defined on line 599, but no explicit reference was found in the text == Unused Reference: 'URL' is defined on line 602, 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: 15 errors (**), 0 flaws (~~), 8 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-05.txt Rich Ankney (CertCo) 3 Ambarish Malpani (ValiCert) 4 Slava Galperin (Teknowledge) 5 Carlisle Adams (Entrust Technologies) 7 Expires in 6 months August 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 protocol. 41 Appendix A demonstrates OCSP over HTTP and appendix B accumulates ASN.1 42 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 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 95 responses for that CA 97 A definitive response message is composed of: 99 - version of the response syntax 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 107 - target certificate identifier 108 - certificate status value 109 - response validity interval 110 - optional extensions 112 This specification defines the following definitive response indicators 113 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). (Please see 4.4.4 for an 128 elaboration of this rule, where the responder can indicate that the 129 notRevoked state applies to all certificates that have not expired 130 before a specified time.) 132 The revoked state indicates that the certificate has been revoked. 134 The unknown state indicates that the responder doesn't know about the 135 certificate being requested. 137 2.3 Exception Cases 139 In case of errors, the OCSP Responder may return an error message. 140 These messages are not signed. Errors can be of the following types: 142 - malformedRequest 143 - internalError 144 - tryLater 145 - certRequired 146 - sigRequired 148 A server produces the malformedRequest response if the request 149 received does not conform to the OCSP syntax. 151 The response internalError indicates that the OCSP responder reached 152 an inconsistent internal state. The query should be retried, 153 potentially with another responder. 155 In the event that the OCSP responder is operational, but unable to 156 return a status for the requested certificate, the tryLater response 157 can be used to indicate that the service exists, but is temporarily 158 unable to respond. 160 The response certRequired is returned in cases where the server 161 requires the client to supply the certificate data itself in order to 162 construct a response. 164 The response sigRequired is returned in cases where the server 165 requires the client sign the request in order to construct a response. 167 2.4 Semantics of thisUpdate, nextUpdate and producedAt 169 Responses can contain three times in them - thisUpdate, nextUpdate and 170 producedAt. The semantics of these fields are: 172 - thisUpdate: The time at which the status being indicated is 173 known to be correct 174 - nextUpdate: The time at or before which newer information will 175 be available about the status of the certificate 176 - producedAt: The time at which the OCSP responder signed this 177 response. 179 If nextUpdate is not set, the responder is indicating that newer 180 revocation information is available all the time. 182 2.5 Response Pre-production 184 OCSP responders MAY pre-produce signed responses specifying the status 185 of certificates at a specified time. The time at which the status was 186 known to be correct SHALL be reflected in the thisUpdate field of the 187 response. The time at or before which newer information will be 188 available is reflected in the nextUpdate field, while the time at 189 which the response was produced will appear in the producedAt field of 190 the response. 192 2.6 OCSP Signature Authority Delegation 194 The key that signs a certificate's revocation information need not be 195 the same key that signed the certificate. A certificate's issuer 196 explicitly delegates OCSP signing authority by issuing a certificate 197 containing a unique value for extendedKeyUsage in the OCSP signer's 198 certificate. 200 3. Functional Requirements 202 3.1 Certificate Content 204 In order to convey to OCSP clients a well-known point of information 205 access, CAs SHALL provide the capability to include the 206 AuthorityInfoAccess extension (defined in PKIX Part 1, section 207 4.2.2.1) in certificates that can be checked using OCSP. 208 Alternatively, the accessLocation for the OCSP provider may be 209 configured locally at the OCSP client. 211 CAs that support an OCSP service, either hosted locally or provided by 212 an Authorized Responder, MAY provide a value for a 213 uniformResourceIndicator (URI) accessLocation and the OID value 214 id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE. 216 The value of the accessLocation field in the subject certificate 217 defines the transport (e.g. HTTP) used to access the OCSP responder 218 and may contain other transport dependent information (e.g. a URL). 220 3.2 Signed Response Acceptance Requirements 222 Prior to accepting a signed response as valid, OCSP clients SHALL 223 confirm that: 225 a. The certificate identified in a received response corresponds to 226 that which was identified in the corresponding request; 227 b. The signature on the response is valid; 228 c. The identity of the signer matches the intended recipient of the 229 request. 230 d. The signer is currently authorized to sign the response. 231 e. The response is in its validity period. 233 4. Detailed Protocol 235 The ASN.1 syntax imports terms defined in the X.509 Certificate and 236 CRL Profile Internet Draft. For signature calculation, the data to be 237 signed is encoded using the ASN.1 distinguished encoding rules (DER) 238 [X.690]. 240 ASN.1 EXPLICIT tagging is used as a default unless specified otherwise. 242 The terms imported from elsewhere are: Extensions, 243 CertificateSerialNumber, SubjectPublicKeyInfo, Name, 244 AlgorithmIdentifier, CRLReason 246 4.1 Requests 248 This section specifies the ASN.1 specification for a confirmation 249 request. The actual formatting of the message could vary depending on 250 the transport mechanism used (HTTP, SMTP, LDAP, etc.). 252 4.1.1 Request Syntax 254 OCSPRequest ::= SEQUENCE { 255 tbsRequest TBSRequest 256 optionalSignature [0] Signature OPTIONAL } 258 TBSRequest ::= SEQUENCE { 259 version [0] EXPLICIT Version DEFAULT v1, 260 requestorName [1] EXPLICIT GeneralName OPTIONAL, 261 requestList SEQUENCE OF Request, 262 requestExtensions [2] EXPLICIT Extensions OPTIONAL } 264 Signature ::= SEQUENCE { 265 signatureAlgorithm AlgorithmIdentifier, 266 signature BIT STRING, 267 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL} 269 Version ::= INTEGER { v1(0) } 271 Request ::= SEQUENCE { 272 reqCert CertID, 273 singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } 275 CertID ::= SEQUENCE { 276 hashAlgorithm AlgorithmIdentifier, 277 issuerNameHash OCTET STRING, -- Hash of Issuer's DN 278 issuerKeyHash OCTET STRING, -- Hash of Issuers public key 279 serialNumber CertificateSerialNumber } 281 issuerNameHash is the hash of the Issuer's distinguished name. The 282 hash shall be calculated over the DER encoding of the issuer's name 283 field in the certificate being checked. issuerKeyHash is the hash of 284 the Issuer's public key. The hash shall be calculated over the value 285 (excluding tag and length) of the subject public key field in 286 the issuer's certificate. 288 4.1.2 Notes on the Request Syntax 290 The primary reason to use both the name and the public key to identify 291 the issuer is that it is possible that two CAs may choose to use the 292 same Name (uniqueness in the Name is a recommendation that cannot be 293 enforced). Two CAs will never, however, have the same public key 294 unless the CAs either explicitly decided to share their private key, 295 or the key of one of the CAs was compromised. 297 While it is possible to identify a certificate by sending over either 298 the entire certificate or just a CertID, it is recommended that 299 clients use just the CertID to reduce the size of the request. 300 However, certain OCSP responders MAY require the entire certificate 301 whose status is to be determined. 303 Support for extensions is OPTIONAL. The critical flag SHOULD NOT be 304 set for any of them. This standard suggests several useful extensions 305 in Section 4.5. Additional extensions MAY be defined in additional 306 RFCs. Unrecognized extensions SHOULD be ignored. 308 Requests may be signed or unsigned. For signed requests, the 309 optionalSignature field is present, while it is absent for unsigned 310 requests. 312 4.2 Response Syntax 314 This section specifies the ASN.1 specification for a confirmation 315 response. The actual formatting of the message could vary depending on 316 the transport mechanism used (HTTP, SMTP, LDAP, etc.). 318 4.2.1 ASN.1 Specification of the OCSP Response 320 An OCSP response at a minimum consists of a responseStatus field 321 indicating the processing status of the prior request. If the value 322 of responseStatus is one of the error conditions, responseBytes are 323 not set. 325 OCSPResponse ::= SEQUENCE { 326 responseStatus OCSPResponseStatus, 327 responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } 329 OCSPResponseStatus ::= ENUMERATED { 330 successful (0), --Response has valid confirmations 331 malformedRequest (1), --Illegal confirmation request 332 internalError (2), --Internal error in issuer 333 tryLater (3), --Try again later 334 certRequired (4), --Must supply certificate 335 sigRequired (5) --Must sign the request 336 } 338 The value for responseBytes consists of an OBJECT IDENTIFIER and a 339 response syntax identified by that OID encoded as an OCTET STRING: 341 ResponseBytes ::= SEQUENCE { 342 responseType OBJECT IDENTIFIER, 343 response OCTET STRING } 345 For a basic OCSP responder, responseType will be id-pkix-ocsp-basic: 347 id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } 348 id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } 350 OCSP responders SHALL be capable of responding with responses of the 351 id-pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL 352 be capable of receiving and processing responses of the 353 id-pkix-ocsp-basic response type. 355 The value for response SHALL be the DER encoding of BasicOCSPResponse: 357 BasicOCSPResponse ::= SEQUENCE { 358 tbsResponseData ResponseData, 359 signatureAlgorithm AlgorithmIdentifier, 360 signature BIT STRING, 361 certs [1] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 363 The value for signature SHALL be computed on the hash of the DER 364 encoding ResponseData. 366 ResponseData ::= SEQUENCE { 367 version [0] EXPLICIT Version DEFAULT v1, 368 responderID ResponderID, 369 producedAt GeneralizedTime, 370 responses SEQUENCE OF SingleResponse, 371 responseExtensions [1] EXPLICIT Extensions OPTIONAL } 373 ResponderID ::= CHOICE { 374 byName [0] Name, 375 byKey [1] KeyHash } 377 KeyHash ::= OCTET STRING --SHA-1 hash of responder's public key 378 (excluding the tag and length fields) 380 SingleResponse ::= SEQUENCE { 381 certID CertID, 382 certStatus CertStatus, 383 thisUpdate GeneralizedTime, 384 nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, 385 singleExtensions [1] EXPLICIT Extensions OPTIONAL } 387 CertStatus ::= CHOICE { 388 notRevoked [0] IMPLICIT NULL, 389 revoked [1] IMPLICIT RevokedInfo, 390 unknown [2] IMPLICIT UnknownInfo } 392 RevokedInfo ::= SEQUENCE { 393 revocationTime GeneralizedTime, 394 revocationReason [0] EXPLICIT CRLReason OPTIONAL } 396 UnknownInfo ::= NULL -- this can be replaced with an enumeration 398 4.2.2 Notes on OCSP Responses 400 4.2.2.1 Time 402 The thisUpdate and nextUpdate fields define a recommended validity 403 interval. This interval corresponds to the {thisUpdate, nextUpdate} 404 interval in CRLs. Responses whose nextUpdate value is earlier than the 405 local system time value SHOULD be considered unreliable. Responses 406 whose thisUpdate time is later than the local system time SHOULD be 407 considered unreliable. Responses where the nextUpdate value is not 408 set are equivalent to a CRL with no time for nextUpdate (see section 409 2.3). 411 The producedAt time is the time at which this response was signed. 413 4.2.2.2 Authorized Responders 415 The key that signs a certificate's revocation information need not be 416 the same key that signed the certificate. A certificate's issuer MAY 417 explicitly delegate OCSP signing authority by issuing a certificate 418 including an extendedKeyUsage extension in the OCSP signer's 419 certificate containing the value id-kp-OCSPSigning. 421 id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9} 423 4.2.2.3.1 Revocation Checking of an Authorized Responder 425 Since an Authorized OCSP responder provides revocation information for 426 a CA, OCSP clients need to know how to check that an authorized 427 responder's certificate has not been revoked. CAs may choose to deal 428 with this problem in one of three ways: 430 - A CA may specify that an OCSP client can trust a responder for the 431 lifetime of the responder's authorization certificate. The CA does so 432 by including the extension id-pkix-ocsp-nocheck. This SHOULD be a non- 433 critical extension. The value of the extension should be NULL. CAs 434 issuing such a certificate should realized that a compromise of the 435 responder's key, is as serious as the compromise of the CA's key, at 436 least for the validity period of this certificate. CA's may choose to 437 issue this type of certificate with a very short lifetime and renew it 438 frequently. 440 - A CA may specify how the responder's certificate be checked for 441 revocation. This can be done using CRL Distribution Points if the 442 check should be done using CRLs or CRL Distribution Points, or 443 Authority Information Access if the check should be done in some other 444 way. Details for specifying either of these two mechanisms are 445 available in PKIX Part 1. 447 - A CA may choose not to specify any method of revocation checking for 448 the responder's certificate, in which case, it would be up to the OCSP 449 client's local security policy to decide whether that certificate 450 should be checked for revocation or not. 452 id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } 454 4.3 Mandatory and Optional Cryptographic Algorithms 456 Clients that request OCSP services SHALL be capable of processing 457 responses signed used DSA keys identified by the DSA sig-alg-oid 458 specified in section 7.2.2 of PKIX Part 1. Clients SHOULD also be 459 capable of processing RSA signatures as specified in section 7.2.1 of 460 PKIX Part 1. OCSP responders SHALL support the SHA1 hashing 461 algorithm. 463 4.4 Extensions 465 This section defines some standard extensions. Support for all 466 extensions is OPTIONAL. For each extension, the definition indicates 467 its syntax, processing performed by the OCSP Responder, and any 468 extensions which are included in the corresponding response. 470 4.4.1 Nonce 472 The nonce cryptographically binds a request and a response to prevent 473 replay attacks. The nonce is included as one of the requestExtensions 474 in requests, while in responses it would be included as one of the 475 responseExtensions. In both the request and the response, the nonce 476 will be identified by the object identifier id-pkix-ocsp-nonce, while 477 the extnValue is the value of the nonce. 479 id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } 480 4.4.2 CRL References 482 It may be desirable for the OCSP responder to indicate the CRL on 483 which a revoked or onHold certificate is found. This can be useful 484 where OCSP is used between repositories, and also as an auditing 485 mechanism. The CRL may be specified by a URL (the URL at which the CRL 486 is available), a number (CRL number) or a time (the time at which the 487 relevant CRL was created). These extensions will be specified as 488 singleExtensions. The identifier for this extension will be 489 id-pkix-ocsp-crl, while the value will be CrlID. 491 id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } 493 CrlID ::= SEQUENCE { 494 crlUrl [0] EXPLICIT IA5String OPTIONAL, 495 crlNum [1] EXPLICIT INTEGER OPTIONAL, 496 crlTime [2] EXPLICIT GeneralizedTime OPTIONAL } 498 For the choice crlUrl, the IA5String will specify the URL at which the 499 CRL is available. For crlNum, the INTEGER will specify the value of 500 the CRL number extension of the relevant CRL. For crlTime, the 501 GeneralizedTime will indicate the time at which the relevant CRL was 502 issued. 504 4.4.3 Acceptable Response Types 506 An OCSP client MAY wish to specify the kinds of response types it 507 understands. To do so, it SHOULD use an extension with the OID 508 id-pkix-ocsp-response, and the value AcceptableResponses. The OIDs 509 included in AcceptableResponses are the OIDs of the various response 510 types this client can accept (e.g., id-pkix-ocsp-basic). 512 id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 } 514 AcceptableResponses ::= SEQUENCE OF { id OBJECT IDENTIFIER } 516 As noted in section 3.3, OCSP responders SHALL be capable of 517 responding with responses of the id-pkix-ocsp-basic response 518 type. Correspondingly, OCSP clients SHALL be capable of receiving and 519 processing responses of the id-pkix-ocsp-basic response type. 521 4.4.4 Archive Cutoff 523 An OCSP responder MAY choose to retain revocation information beyond a 524 certificate�s expiration. The date obtained by subtracting this 525 retention interval value from the producedAt time in a response is 526 defined as the certificate�s �archive cutoff� date. 528 OCSP-enabled applications would use an OCSP archive cutoff date to 529 contribute to a proof that a digital signature was (or was not) reliable 530 on the date it was produced even if the certificate needed to validate 531 the signature has long since expired. 533 OCSP servers that provide support for such historical reference SHOULD 534 include an archive cutoff date extension in responses. If included, 535 this value SHALL be provided as an OCSP singleResponse extension 536 identified by id-pkix-ocsp-archive-cutoff and of syntax GeneralizedTime: 538 id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 } 540 archiveCutoff ::= GeneralizedTime 542 To illustrate, if a server is operated with a 7-year retention interval 543 policy and status was produced at time t1 then the value for 544 archiveCutoff in the response would be (t1 - 7 years). 546 4.4.5 CRL Entry Extensions 548 CRL Entry Extensions - specified in Section 5.3 of PKIX part I - are 549 also supported as singleExtensions. 551 4.4.6 Service Locator 553 An OCSP server may be operated in a mode whereby the server receives a 554 request and routes it to the OCSP server which is known to be 555 authoritative for the identified certificate. The serviceLocator 556 request extension is defined for this purpose. 558 id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 } 560 ServiceLocator :: = SEQUENCE { 561 issuer Name, 562 locator AuthorityInfoAccessSyntax OPTIONAL } 564 Values for these fields are obtained from the corresponding fields in 565 the subject certificate. 567 5. Security Considerations 569 For this service to be effective, certificate using systems must 570 connect to the certificate status service provider. In the event such 571 a connection cannot be obtained, certificate-using systems could 572 implement CRL processing logic as a fall-back position. 574 A denial of service vulnerability is evident with respect to a flood 575 of queries. The production of a cryptographic signature significantly 576 affects response generation cycle time, thereby exacerbating the 577 situation. Unsigned error responses open up the protocol to another 578 denial of service attack, where the attacker sends false error 579 responses. 581 The use of precomputed responses allows replay attacks in which an old 582 (notRevoked) response is replayed prior to its expiration date but 583 after the certificate has been revoked. Deployments of OCSP should 584 carefully evaluate the benefit of precomputed responses against the 585 probability of a replay attack and the costs associated with its 586 successful execution. 588 The reliance of HTTP caching in some deployment scenarios may result 589 in unexpected results if intermediate servers are incorrectly configured 590 or are known to possess cache management faults. Implementors are 591 advised to take the reliability of HTTP cache mechanisms into account 592 when deploying OCSP over HTTP. 594 6. References 596 [HTTP] Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys, 597 J. Mogul, H. Frystyk and T. Berners-Lee, RFC 2068, January 1997. 599 [MUSTSHOULD] Key words for use in RFCs to Indicate Requirement Levels, 600 S. Bradner, RFC 2119, March 1997. 602 [URL] Uniform Resource Locators (URL), T. Berners-Lee, L. Masinter, M. 603 McCahill, RFC 1738, December 1994. 605 7. Author's Address 607 Michael Myers 608 VeriSign, Inc. 609 1390 Shorebird Way 610 Mountain View, CA 94019 611 mmyers@verisign.com 613 Rich Ankney 614 CertCo, LLC 615 13506 King Charles Dr. 616 Chantilly, VA 20151 617 rankney@erols.com 619 Ambarish Malpani 620 ValiCert, Inc. 621 3160 W. Bayshore Drive 622 Palo Alto, CA 94303 623 ambarish@valicert.com 624 650.849.9880 626 Slava Galperin 627 Teknowledge Corporation 628 1810 Embarcadero Road 629 Palo Alto, CA 630 galperin@teknowledge.com 632 Carlisle Adams 633 Entrust Technologies 634 750 Heron Road, Suite E08 635 Ottawa, Ontario 636 K1V 1A7 637 Canada 638 cadams@entrust.com 639 Appendix A 641 A.1 OCSP over HTTP 643 This section describes the formatting that will be done to the request 644 and response to support HTTP. 646 A.1.1 648 HTTP based OCSP requests can use either the GET or the POST method to 649 submit their requests. To enable HTTP caching, small requests (that 650 after encoding are less than 255 bytes), MAY be submitted using GET. If 651 HTTP caching is not important, or the request is greater than 255 bytes, 652 the request SHOULD be submitted using POST. Where privacy is a 653 requirement, OCSP transactions exchanged using HTTP SHOULD be protected 654 using either TLS or SSL. 656 An OCSP request using the GET method is constructed as follows: 658 GET {url}/{url-encoding of base-64 encoding of the DER encoding of the 659 OCSPRequest} 661 where {url} may be derived from the value of AuthorityInfoAccess or 662 other local configuration of the OCSP client. 664 An OCSP request using the POST method is constructed as follows: The 665 Content-Type header has the value "application/ocsp-request" while the 666 body of the message is the DER encoding of the OCSPRequest. 668 A.1.2 Response 670 An HTTP-based OCSP response is composed of the appropriate HTTP 671 headers, followed by the DER encoding of the OCSPResponse. The 672 Content-Type header has the value "application/ocsp-response". The 673 Content-Length header SHOULD specify the length of the response. Other 674 HTTP headers MAY be present and MAY be ignored if not understood by 675 the requestor. 677 Appendix B: OCSP in ASN.1 679 OCSP1 DEFINITIONS EXPLICIT TAGS::= 681 BEGIN 683 IMPORTS 685 -- Directory Authentication Framework (X.509) 686 Certificate, AlgorithmIdentifier, GeneralizedTime, 687 CRLReason, 688 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 689 module(1) authenticationFramework(7) 3 } 691 -- PKIX Certificate Extensions 692 AuthorityInfoAcessSyntax 693 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 694 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 695 id-mod(0) id-pkix1-explicit-88(1)}; 697 OCSPRequest ::= SEQUENCE { 698 tbsRequest TBSRequest 699 optionalSignature [0] Signature OPTIONAL } 701 TBSRequest ::= SEQUENCE { 702 version [0] EXPLICIT Version DEFAULT v1, 703 requestorName [1] EXPLICIT GeneralName OPTIONAL, 704 requestList SEQUENCE OF Request, 705 requestExtensions [2] EXPLICIT Extensions OPTIONAL } 707 Signature ::= SEQUENCE { 708 signatureAlgorithm AlgorithmIdentifier, 709 signature BIT STRING, 710 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 712 Version ::= INTEGER { v1(0) } 714 Request ::= SEQUENCE { 715 reqCert CertID, 716 singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } 718 CertID ::= SEQUENCE { 719 hashAlgorithm AlgorithmIdentifier, 720 issuerNameHash OCTET STRING, -- Hash of Issuer's DN 721 issuerKeyHash OCTET STRING, -- Hash of Issuers public key 722 serialNumber CertificateSerialNumber } 724 OCSPResponse ::= SEQUENCE { 725 responseStatus OCSPResponseStatus, 726 responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } 728 OCSPResponseStatus ::= ENUMERATED { 729 successful (0), --Response has valid confirmations 730 malformedRequest (1), --Illegal confirmation request 731 internalError (2), --Internal error in issuer 732 tryLater (3), --Try again later 733 certRequired (4), --Must supply certificate 734 sigRequired (5) --Must sign the request 735 } 737 ResponseBytes ::= SEQUENCE { 738 responseType OBJECT IDENTIFIER, 739 response OCTET STRING } 741 BasicOCSPResponse ::= SEQUENCE { 742 tbsResponseData ResponseData, 743 signatureAlgorithm AlgorithmIdentifier, 744 signature BIT STRING, 745 certs [1] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 747 ResponseData ::= SEQUENCE { 748 version [0] EXPLICIT Version DEFAULT v1, 749 responderID ResponderID, 750 producedAt GeneralizedTime, 751 responses SEQUENCE OF SingleResponse, 752 responseExtensions [1] EXPLICIT Extensions OPTIONAL } 754 ResponderID ::= CHOICE { 755 byName [0] Name, 756 byKey [1] KeyHash } 758 KeyHash ::= OCTET STRING --SHA-1 hash of responder's public key 759 --(excluding the tag and length fields) 761 SingleResponse ::= SEQUENCE { 762 certID CertID, 763 certStatus CertStatus, 764 thisUpdate GeneralizedTime, 765 nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, 766 singleExtensions [1] EXPLICIT Extensions OPTIONAL } 768 CertStatus ::= CHOICE { 769 notRevoked [0] IMPLICIT NULL, 770 revoked [1] IMPLICIT RevokedInfo, 771 unknown [2] IMPLICIT UnknownInfo } 773 RevokedInfo ::= SEQUENCE { 774 revocationTime GeneralizedTime, 775 revocationReason [0] EXPLICIT CRLReason OPTIONAL } 777 UnknownInfo ::= NULL -- this can be replaced with an enumeration 779 archiveCutoff ::= GeneralizedTime 781 AcceptableResponses ::= SEQUENCE OF { id OBJECT IDENTIFIER } 783 ServiceLocator :: = SEQUENCE { 784 issuer Name, 785 locator AuthorityInfoAccessSyntax } 787 -- Object Identifiers 789 id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } 790 id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } 791 id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } 792 id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } 793 id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } 794 id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 } 795 id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } 796 id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 } 797 id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 } 799 END 800 Appendix C: MIME registrations 802 C.1 application/ocsp-request 804 To: ietf-types@iana.org 805 Subject: Registration of MIME media type application/ocsp-request 807 MIME media type name: application 809 MIME subtype name: ocsp-request 811 Required parameters: None 813 Optional parameters: None 815 Encoding considerations: binary or Base64 817 Security considerations: Carries a request for information. This 818 request may optionally be cryptographically signed. 820 Interoperability considerations: None 822 Published specification: IETF PKIX Working Group Draft on Online 823 Certificate Status Protocol - OCSP 825 Applications which use this media type: OCSP clients 827 Additional information: 829 Magic number(s): None 830 File extension(s): .ORQ 831 Macintosh File Type Code(s): none 833 Person & email address to contact for further information: 834 Ambarish Malpani 836 Intended usage: COMMON 838 Author/Change controller: 839 Ambarish Malpani 841 C.2 application/ocsp-response 843 To: ietf-types@iana.org 844 Subject: Registration of MIME media type application/ocsp-response 846 MIME media type name: application 848 MIME subtype name: ocsp-response 850 Required parameters: None 852 Optional parameters: None 853 Encoding considerations: binary or Base64 854 Security considerations: Carries a cryptographically signed 855 response 857 Interoperability considerations: None 859 Published specification: IETF PKIX Working Group Draft on Online 860 Certificate Status Protocol - OCSP 862 Applications which use this media type: OCSP servers 864 Additional information: 866 Magic number(s): None 867 File extension(s): .ORS 868 Macintosh File Type Code(s): none 870 Person & email address to contact for further information: 871 Ambarish Malpani 873 Intended usage: COMMON 875 Author/Change controller: 876 Ambarish Malpani