idnits 2.17.1 draft-ietf-pkix-ocsp-06.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-03-29) 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 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 13 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (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 (September 1998) is 9327 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 812 -- Looks like a reference, but probably isn't: '1' on line 807 -- Looks like a reference, but probably isn't: '2' on line 808 == Unused Reference: 'HTTP' is defined on line 625, but no explicit reference was found in the text == Unused Reference: 'URL' is defined on line 632, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'PKIX1' ** 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 (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group Michael Myers(VeriSign) 3 draft-ietf-pkix-ocsp-06.txt Rich Ankney (CertCo) 4 Ambarish Malpani (ValiCert) 5 Slava Galperin (Teknowledge) 6 Carlisle Adams (Entrust Technologies) 8 Expires in 6 months September 1998 10 X.509 Internet Public Key Infrastructure 11 Online Certificate Status Protocol - OCSP 12 14 1. Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 2. Abstract 34 This document specifies a protocol useful in determining the current 35 status of a digital certificate without requiring CRLs. Additional 36 mechanisms addressing PKIX operational requirements are specified in 37 separate documents. 39 An overview of the protocol is provided in section 3. Functional 40 requirements are specified in section 4. Details of the protocol are 41 in section 5. We cover security issues with the protocol in section 42 6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1 43 syntactic elements and appendix C specifies the mime types for the 44 messages. 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document (in uppercase, as shown) are to be interpreted as described 49 in [RFC2119]. 51 3. Protocol Overview 53 In lieu of or as a supplement to checking against a periodic CRL, it 54 may be necessary to obtain timely status regarding a certificate's 55 state (cf. [PKIX1], Section 3.3). Examples include high-value funds 56 transfer or large stock trades. 58 The Online Certificate Status Protocol (OCSP) enables applications to 59 determine the state of an identified certificate. OCSP may be used to 60 satisfy some of the operational requirements of providing more timely 61 revocation information than is possible with CRLs and may also be 62 used to obtain additional status information. An OCSP client issues a 63 status request to an OCSP responder and suspends acceptance of the 64 certificate in question until the responder provides a response. 66 This protocol specifies the data that needs to be exchanged between 67 an application checking the status of a certificate and the server 68 providing that status. 70 3.1 Request 72 An OCSP request contains the following data: 74 -- protocol version 75 -- service request 76 -- target certificate identifier 77 -- optional extensions which MAY be processed by the OCSP Responder 79 Upon receipt of a request, an OCSP Responder determines if: 81 1. the message is well formed 83 2. the responder is configured to provide the requested service and 85 3. the request contains the information needed by the responder 86 If any one of the prior conditions are not met, the OCSP responder 87 produces an error message; otherwise, it returns a definitive 88 response. 90 3.2 Response 92 OCSP responses can be of various types. An OCSP response consists of 93 a response type and the bytes of the actual response. There is one 94 basic type of OCSP response that MUST be supported by all OCSP 95 servers and clients. The rest of this section pertains only to this 96 basic response type. 98 All definitive response messages SHALL be digitally signed. The key 99 used to sign the response MUST belong to one of the following: 101 -- the CA who issued the certificate in question 102 -- a Trusted Responder whose public key is trusted by the requester 103 -- a CA Designated Responder (Authorized Responder) who holds a 104 special certificate issued by the CA indicating that it may issue 105 OCSP responses for that CA 107 A definitive response message is composed of: 109 -- version of the response syntax 110 -- name of the responder 111 -- responses for each of the certificates in a request 112 -- optional extensions 113 -- signature algorithm OID 114 -- signature computed across hash of the response 116 The response for each of the certificates in a request consists of 118 -- target certificate identifier 119 -- certificate status value 120 -- response validity interval 121 -- optional extensions 123 This specification defines the following definitive response 124 indicators for use in the certificate status value: 126 -- good 127 -- revoked 128 -- unknown 130 The "good" state indicates a positive response to the status inquiry. 131 At a minimum, this positive response indicates that the certificate 132 is not revoked, but does not necessarily mean that the certificate 133 was ever issued or that the producedAt time is within the 134 certificate's validity interval. Response extensions may be used to 135 convey additional information on assertions made by the responder 136 regarding the status of the certificate such as positive statement 137 about issuance, validity, etc. 139 The "revoked" state indicates that the certificate has been revoked. 141 The "unknown" state indicates that the responder doesn't know about 142 the certificate being requested. 144 3.3 Exception Cases 146 In case of errors, the OCSP Responder may return an error message. 147 These messages are not signed. Errors can be of the following types: 149 -- malformedRequest 150 -- internalError 151 -- tryLater 152 -- certRequired 153 -- sigRequired 154 -- unauthorized 156 A server produces the "malformedRequest" response if the request 157 received does not conform to the OCSP syntax. 159 The response "internalError" indicates that the OCSP responder 160 reached an inconsistent internal state. The query should be retried, 161 potentially with another responder. 163 In the event that the OCSP responder is operational, but unable to 164 return a status for the requested certificate, the "tryLater" 165 response can be used to indicate that the service exists, but is 166 temporarily unable to respond. 168 The response "certRequired" is returned in cases where the server 169 requires the client to supply the certificate data itself in order to 170 construct a response. 172 The response "sigRequired" is returned in cases where the server 173 requires the client sign the request in order to construct a 174 response. 176 The response "unauthorized" is returned in cases where the client is 177 not authorized to make this query to this server. 179 3.4 Semantics of thisUpdate, nextUpdate and producedAt 181 Responses can contain three times in them - thisUpdate, nextUpdate 182 and producedAt. The semantics of these fields are: 184 - thisUpdate: The time at which the status being indicated is 185 known to be correct 186 - nextUpdate: The time at or before which newer information will 187 be available about the status of the certificate 188 - producedAt: The time at which the OCSP responder signed this 189 response. 191 If nextUpdate is not set, the responder is indicating that newer 192 revocation information is available all the time. 194 3.5 Response Pre-production 196 OCSP responders MAY pre-produce signed responses specifying the 197 status of certificates at a specified time. The time at which the 198 status was known to be correct SHALL be reflected in the thisUpdate 199 field of the response. The time at or before which newer information 200 will be available is reflected in the nextUpdate field, while the 201 time at which the response was produced will appear in the producedAt 202 field of the response. 204 3.6 OCSP Signature Authority Delegation 206 The key that signs a certificate's status information need not be the 207 same key that signed the certificate. A certificate's issuer 208 explicitly delegates OCSP signing authority by issuing a certificate 209 containing a unique value for extendedKeyUsage in the OCSP signer's 210 certificate. 212 3.7 CA Key Compromise 214 If an OCSP responder knows that a particular CA's private key has 215 been compromised, it MAY return the revoked state for all 216 certificates issued by that CA. 218 4. Functional Requirements 220 4.1 Certificate Content 222 In order to convey to OCSP clients a well-known point of information 223 access, CAs SHALL provide the capability to include the 224 AuthorityInfoAccess extension (defined in [PKIX1], section 4.2.2.1) 225 in certificates that can be checked using OCSP. Alternatively, the 226 accessLocation for the OCSP provider may be configured locally at the 227 OCSP client. 229 CAs that support an OCSP service, either hosted locally or provided 230 by an Authorized Responder, MAY provide a value for a 231 uniformResourceIndicator (URI) accessLocation and the OID value id- 232 ad-ocsp for the accessMethod in the AccessDescription SEQUENCE. 234 The value of the accessLocation field in the subject certificate 235 defines the transport (e.g. HTTP) used to access the OCSP responder 236 and may contain other transport dependent information (e.g. a URL). 238 4.2 Signed Response Acceptance Requirements 240 Prior to accepting a signed response as valid, OCSP clients SHALL 241 confirm that: 243 1. The certificate identified in a received response corresponds to 244 that which was identified in the corresponding request; 246 2. The signature on the response is valid; 248 3. The identity of the signer matches the intended recipient of the 249 request. 251 4. The signer is currently authorized to sign the response. 253 5. The response is in its validity period. 255 6. The response was produced sufficiently recently. 257 5. Detailed Protocol 259 The ASN.1 syntax imports terms defined in [PKIX1]. For signature 260 calculation, the data to be signed is encoded using the ASN.1 261 distinguished encoding rules (DER) [X.690]. 263 ASN.1 EXPLICIT tagging is used as a default unless specified 264 otherwise. 266 The terms imported from elsewhere are: Extensions, 267 CertificateSerialNumber, SubjectPublicKeyInfo, Name, 268 AlgorithmIdentifier, CRLReason 270 5.1 Requests 272 This section specifies the ASN.1 specification for a confirmation 273 request. The actual formatting of the message could vary depending on 274 the transport mechanism used (HTTP, SMTP, LDAP, etc.). 276 5.1.1 Request Syntax 278 OCSPRequest ::= SEQUENCE { 279 tbsRequest TBSRequest, 280 optionalSignature [0] EXPLICIT Signature OPTIONAL } 282 TBSRequest ::= SEQUENCE { 283 version [0] EXPLICIT Version DEFAULT v1, 284 requestorName [1] EXPLICIT GeneralName OPTIONAL, 285 requestList SEQUENCE OF Request, 286 requestExtensions [2] EXPLICIT Extensions OPTIONAL } 288 Signature ::= SEQUENCE { 289 signatureAlgorithm AlgorithmIdentifier, 290 signature BIT STRING, 291 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL} 293 Version ::= INTEGER { v1(0) } 295 Request ::= SEQUENCE { 296 reqCert CertID, 297 singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } 299 CertID ::= SEQUENCE { 300 hashAlgorithm AlgorithmIdentifier, 301 issuerNameHash OCTET STRING, -- Hash of Issuer's DN 302 issuerKeyHash OCTET STRING, -- Hash of Issuers public key 303 serialNumber CertificateSerialNumber } 305 issuerNameHash is the hash of the Issuer's distinguished name. The 306 hash shall be calculated over the DER encoding of the issuer's name 307 field in the certificate being checked. issuerKeyHash is the hash of 308 the Issuer's public key. The hash shall be calculated over the value 309 (excluding tag and length) of the subject public key field in the 310 issuer's certificate. The hash algorithm used for both these hashes, 311 is identified in hashAlgorithm. 313 5.1.2 Notes on the Request Syntax 315 The primary reason to use both the name and the public key to 316 identify the issuer is that it is possible that two CAs may choose to 317 use the same Name (uniqueness in the Name is a recommendation that 318 cannot be enforced). Two CAs will never, however, have the same 319 public key unless the CAs either explicitly decided to share their 320 private key, or the key of one of the CAs was compromised. 322 Support for any specific extension is OPTIONAL. The critical flag 323 SHOULD NOT be set for any of them. Section 5.4 suggests several 324 useful extensions. Additional extensions MAY be defined in 325 additional RFCs. Unrecognized extensions MUST be ignored (unless they 326 have the critical flag set and are not understood). 328 The requestor MAY choose to sign the OCSP request. In that case, the 329 signature is computed over the tbsRequest structure. If the request 330 is signed, the requestor SHALL specify its name in the requestorName 331 field. Also, for signed requests, the requestor MAY include 332 certificates that help the OCSP responder verify the requestor's 333 signature in the certs field of Signature. 335 5.2 Response Syntax 337 This section specifies the ASN.1 specification for a confirmation 338 response. The actual formatting of the message could vary depending 339 on the transport mechanism used (HTTP, SMTP, LDAP, etc.). 341 5.2.1 ASN.1 Specification of the OCSP Response 343 An OCSP response at a minimum consists of a responseStatus field 344 indicating the processing status of the prior request. If the value 345 of responseStatus is one of the error conditions, responseBytes are 346 not set. 348 OCSPResponse ::= SEQUENCE { 349 responseStatus OCSPResponseStatus, 350 responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } 352 OCSPResponseStatus ::= ENUMERATED { 353 successful (0), --Response has valid confirmations 354 malformedRequest (1), --Illegal confirmation request 355 internalError (2), --Internal error in issuer 356 tryLater (3), --Try again later 357 certRequired (4), --Must supply certificate 358 sigRequired (5), --Must sign the request 359 unauthorized (6) --Request unauthorized } 361 The value for responseBytes consists of an OBJECT IDENTIFIER and a 362 response syntax identified by that OID encoded as an OCTET STRING: 364 ResponseBytes ::= SEQUENCE { 365 responseType OBJECT IDENTIFIER, 366 response OCTET STRING } 368 For a basic OCSP responder, responseType will be id-pkix-ocsp-basic: 370 id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } 371 id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } 373 OCSP responders SHALL be capable of responding with responses of the 374 id-pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL 375 be capable of receiving and processing responses of the id-pkix-ocsp- 376 basic response type. 378 The value for response SHALL be the DER encoding of 379 BasicOCSPResponse: 381 BasicOCSPResponse ::= SEQUENCE { 382 tbsResponseData ResponseData, 383 signatureAlgorithm AlgorithmIdentifier, 384 signature BIT STRING, 385 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 387 The value for signature SHALL be computed on the hash of the DER 388 encoding ResponseData. 390 ResponseData ::= SEQUENCE { 391 version [0] EXPLICIT Version DEFAULT v1, 392 responderID ResponderID, 393 producedAt GeneralizedTime, 394 responses SEQUENCE OF SingleResponse, 395 responseExtensions [1] EXPLICIT Extensions OPTIONAL } 397 ResponderID ::= CHOICE { 398 byName [1] Name, 399 byKey [2] KeyHash } 401 KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key 402 (excluding the tag and length fields) 404 SingleResponse ::= SEQUENCE { 405 certID CertID, 406 certStatus CertStatus, 407 thisUpdate GeneralizedTime, 408 nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, 409 singleExtensions [1] EXPLICIT Extensions OPTIONAL } 411 CertStatus ::= CHOICE { 412 good [0] IMPLICIT NULL, 413 revoked [1] IMPLICIT RevokedInfo, 414 unknown [2] IMPLICIT UnknownInfo } 416 RevokedInfo ::= SEQUENCE { 417 revocationTime GeneralizedTime, 418 revocationReason [0] EXPLICIT CRLReason OPTIONAL } 420 UnknownInfo ::= NULL -- this can be replaced with an enumeration 422 5.2.2 Notes on OCSP Responses 424 5.2.2.1 Time 426 The thisUpdate and nextUpdate fields define a recommended validity 427 interval. This interval corresponds to the {thisUpdate, nextUpdate} 428 interval in CRLs. Responses whose nextUpdate value is earlier than 429 the local system time value SHOULD be considered unreliable. 430 Responses whose thisUpdate time is later than the local system time 431 SHOULD be considered unreliable. Responses where the nextUpdate value 432 is not set are equivalent to a CRL with no time for nextUpdate (see 433 Section 3.4). 435 The producedAt time is the time at which this response was signed. 437 5.2.2.2 Authorized Responders 439 The key that signs a certificate's status information need not be the 440 same key that signed the certificate. A certificate's issuer MAY 441 explicitly delegate OCSP signing authority by issuing a certificate 442 including an extendedKeyUsage extension in the OCSP signer's 443 certificate containing the value id-kp-OCSPSigning. 445 id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9} 447 5.2.2.2.1 Revocation Checking of an Authorized Responder 449 Since an Authorized OCSP responder provides status information for a 450 CA, OCSP clients need to know how to check that an authorized 451 responder's certificate has not been revoked. CAs may choose to deal 452 with this problem in one of three ways: 454 - A CA may specify that an OCSP client can trust a responder for the 455 lifetime of the responder's certificate. The CA does so by including 456 the extension id-pkix-ocsp-nocheck. This SHOULD be a non- critical 457 extension. The value of the extension should be NULL. CAs issuing 458 such a certificate should realized that a compromise of the 459 responder's key, is as serious as the compromise of the CA's key, at 460 least for the validity period of this certificate. CA's may choose to 461 issue this type of certificate with a very short lifetime and renew 462 it frequently. 464 id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } 466 - A CA may specify how the responder's certificate be checked for 467 revocation. This can be done using CRL Distribution Points if the 468 check should be done using CRLs or CRL Distribution Points, or 469 Authority Information Access if the check should be done in some 470 other way. Details for specifying either of these two mechanisms are 471 available in PKIX Part 1. 473 - A CA may choose not to specify any method of revocation checking 474 for the responder's certificate, in which case, it would be up to the 475 OCSP client's local security policy to decide whether that 476 certificate should be checked for revocation or not. 478 5.3 Mandatory and Optional Cryptographic Algorithms 480 Clients that request OCSP services SHALL be capable of processing 481 responses signed used DSA keys identified by the DSA sig-alg-oid 482 specified in section 7.2.2 of [PKIX1]. Clients SHOULD also be capable 483 of processing RSA signatures as specified in section 7.2.1 of 484 [PKIX1]. OCSP responders SHALL support the SHA1 hashing algorithm. 486 5.4 Extensions 488 This section defines some standard extensions. Support for all 489 extensions is optional. For each extension, the definition indicates 490 its syntax, processing performed by the OCSP Responder, and any 491 extensions which are included in the corresponding response. 493 5.4.1 Nonce 495 The nonce cryptographically binds a request and a response to prevent 496 replay attacks. The nonce is included as one of the requestExtensions 497 in requests, while in responses it would be included as one of the 498 responseExtensions. In both the request and the response, the nonce 499 will be identified by the object identifier id-pkix-ocsp-nonce, while 500 the extnValue is the value of the nonce. 502 id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } 504 5.4.2 CRL References 506 It may be desirable for the OCSP responder to indicate the CRL on 507 which a revoked or onHold certificate is found. This can be useful 508 where OCSP is used between repositories, and also as an auditing 509 mechanism. The CRL may be specified by a URL (the URL at which the 510 CRL is available), a number (CRL number) or a time (the time at which 511 the relevant CRL was created). These extensions will be specified as 512 singleExtensions. The identifier for this extension will be id-pkix- 513 ocsp-crl, while the value will be CrlID. 515 id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } 517 CrlID ::= SEQUENCE { 518 crlUrl [0] EXPLICIT IA5String OPTIONAL, 519 crlNum [1] EXPLICIT INTEGER OPTIONAL, 520 crlTime [2] EXPLICIT GeneralizedTime OPTIONAL } 522 For the choice crlUrl, the IA5String will specify the URL at which 523 the CRL is available. For crlNum, the INTEGER will specify the value 524 of the CRL number extension of the relevant CRL. For crlTime, the 525 GeneralizedTime will indicate the time at which the relevant CRL was 526 issued. 528 5.4.3 Acceptable Response Types 530 An OCSP client MAY wish to specify the kinds of response types it 531 understands. To do so, it SHOULD use an extension with the OID id- 532 pkix-ocsp-response, and the value AcceptableResponses. The OIDs 533 included in AcceptableResponses are the OIDs of the various response 534 types this client can accept (e.g., id-pkix-ocsp-basic). 536 id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 } 538 AcceptableResponses ::= SEQUENCE OF { id OBJECT IDENTIFIER } 540 As noted in section 5.2.1, OCSP responders SHALL be capable of 541 responding with responses of the id-pkix-ocsp-basic response type. 542 Correspondingly, OCSP clients SHALL be capable of receiving and 543 processing responses of the id-pkix-ocsp-basic response type. 545 5.4.4 Archive Cutoff 547 An OCSP responder MAY choose to retain revocation information beyond 548 a certificate's expiration. The date obtained by subtracting this 549 retention interval value from the producedAt time in a response is 550 defined as the certificate's "archive cutoff" date. 552 OCSP-enabled applications would use an OCSP archive cutoff date to 553 contribute to a proof that a digital signature was (or was not) 554 reliable on the date it was produced even if the certificate needed 555 to validate the signature has long since expired. 557 OCSP servers that provide support for such historical reference 558 SHOULD include an archive cutoff date extension in responses. If 559 included, this value SHALL be provided as an OCSP singleResponse 560 extension identified by id-pkix-ocsp-archive-cutoff and of syntax 561 GeneralizedTime: 563 id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 } 565 archiveCutoff ::= GeneralizedTime 567 To illustrate, if a server is operated with a 7-year retention 568 interval policy and status was produced at time t1 then the value for 569 archiveCutoff in the response would be (t1 - 7 years). 571 5.4.5 CRL Entry Extensions 573 CRL Entry Extensions - specified in Section 5.3 of PKIX part I - are 574 also supported as singleExtensions. 576 5.4.6 Service Locator 578 An OCSP server may be operated in a mode whereby the server receives 579 a request and routes it to the OCSP server which is known to be 580 authoritative for the identified certificate. The serviceLocator 581 request extension is defined for this purpose. 583 id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 } 585 ServiceLocator :: = SEQUENCE { 586 issuer Name, 587 locator AuthorityInfoAccessSyntax OPTIONAL } 589 Values for these fields are obtained from the corresponding fields in 590 the subject certificate. 592 6. Security Considerations 594 For this service to be effective, certificate using systems must 595 connect to the certificate status service provider. In the event such 596 a connection cannot be obtained, certificate-using systems could 597 implement CRL processing logic as a fall-back position. 599 A denial of service vulnerability is evident with respect to a flood 600 of queries. The production of a cryptographic signature significantly 601 affects response generation cycle time, thereby exacerbating the 602 situation. Unsigned error responses open up the protocol to another 603 denial of service attack, where the attacker sends false error 604 responses. 606 The use of precomputed responses allows replay attacks in which an 607 old (good) response is replayed prior to its expiration date but 608 after the certificate has been revoked. Deployments of OCSP should 609 carefully evaluate the benefit of precomputed responses against the 610 probability of a replay attack and the costs associated with its 611 successful execution. 613 The reliance of HTTP caching in some deployment scenarios may result 614 in unexpected results if intermediate servers are incorrectly 615 configured or are known to possess cache management faults. 616 Implementors are advised to take the reliability of HTTP cache 617 mechanisms into account when deploying OCSP over HTTP. 619 7. References 621 [PKIX1] Internet X.509 Public Key Infrastructure Certificate and 622 CRL Profile, R. Housley, W. Ford, W. Polk, D. Solo, 623 Internet Draft, September 1, 1998. 625 [HTTP] Hypertext Transfer Protocol -- HTTP/1.1, R. Fielding, J. 626 Gettys, J. Mogul, H. Frystyk and T. Berners-Lee, RFC 2068, 627 January 1997. 629 [RFC2119] Key words for use in RFCs to Indicate Requirement Levels, 630 S. Bradner, RFC 2119, March 1997. 632 [URL] Uniform Resource Locators (URL), T. Berners-Lee, L. 633 Masinter, M. McCahill, RFC 1738, December 1994. 635 [X.690] ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995, 636 Information Technology - ASN.1 encoding rules: 637 Specification of Basic Encoding Rules (BER), Canonical 638 Encoding Rules (CER) and Distinguished Encoding Rules 639 (DER). 641 8. Author's Address 643 Michael Myers 644 VeriSign, Inc. 645 1390 Shorebird Way 646 Mountain View, CA 94019 647 mmyers@verisign.com 649 Rich Ankney 650 CertCo, LLC 651 13506 King Charles Dr. 652 Chantilly, VA 20151 653 rankney@erols.com 655 Ambarish Malpani 656 ValiCert, Inc. 657 3160 W. Bayshore Drive 658 Palo Alto, CA 94303 659 ambarish@valicert.com 660 650.567.5457 662 Slava Galperin 663 Teknowledge Corporation 664 1810 Embarcadero Road 665 Palo Alto, CA 666 galperin@teknowledge.com 667 Carlisle Adams 668 Entrust Technologies 669 750 Heron Road, Suite E08 670 Ottawa, Ontario 671 K1V 1A7 672 Canada 673 cadams@entrust.com 675 Appendix A 677 A.1 OCSP over HTTP 679 This section describes the formatting that will be done to the request 680 and response to support HTTP. 682 A.1.1 Request 684 HTTP based OCSP requests can use either the GET or the POST method to 685 submit their requests. To enable HTTP caching, small requests (that 686 after encoding are less than 255 bytes), MAY be submitted using GET. If 687 HTTP caching is not important, or the request is greater than 255 bytes, 688 the request SHOULD be submitted using POST. Where privacy is a 689 requirement, OCSP transactions exchanged using HTTP SHOULD be protected 690 using either TLS or SSL. 692 An OCSP request using the GET method is constructed as follows: 694 GET {url}/{url-encoding of base-64 encoding of the DER encoding of the 695 OCSPRequest} 697 where {url} may be derived from the value of AuthorityInfoAccess or 698 other local configuration of the OCSP client. 700 An OCSP request using the POST method is constructed as follows: The 701 Content-Type header has the value "application/ocsp-request" while the 702 body of the message is the DER encoding of the OCSPRequest. 704 A.1.2 Response 706 An HTTP-based OCSP response is composed of the appropriate HTTP 707 headers, followed by the DER encoding of the OCSPResponse. The 708 Content-Type header has the value "application/ocsp-response". The 709 Content-Length header SHOULD specify the length of the response. Other 710 HTTP headers MAY be present and MAY be ignored if not understood by 711 the requestor. 713 Appendix B: OCSP in ASN.1 715 OCSP1 DEFINITIONS EXPLICIT TAGS::= 717 BEGIN 719 IMPORTS 721 -- Directory Authentication Framework (X.509) 722 Certificate, AlgorithmIdentifier, GeneralizedTime, 723 CRLReason, 724 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 725 module(1) authenticationFramework(7) 3 } 727 -- PKIX Certificate Extensions 728 AuthorityInfoAccessSyntax, Name, GeneralName, 729 CertificateSerialNumber, Extensions 730 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 731 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 732 id-mod(0) id-pkix1-explicit-88(1)}; 734 OCSPRequest ::= SEQUENCE { 735 tbsRequest TBSRequest, 736 optionalSignature [0] EXPLICIT Signature OPTIONAL } 738 TBSRequest ::= SEQUENCE { 739 version [0] EXPLICIT Version DEFAULT v1, 740 requestorName [1] EXPLICIT GeneralName OPTIONAL, 741 requestList SEQUENCE OF Request, 742 requestExtensions [2] EXPLICIT Extensions OPTIONAL } 744 Signature ::= SEQUENCE { 745 signatureAlgorithm AlgorithmIdentifier, 746 signature BIT STRING, 747 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 749 Version ::= INTEGER { v1(0) } 751 Request ::= SEQUENCE { 752 reqCert CertID, 753 singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } 755 CertID ::= SEQUENCE { 756 hashAlgorithm AlgorithmIdentifier, 757 issuerNameHash OCTET STRING, -- Hash of Issuer's DN 758 issuerKeyHash OCTET STRING, -- Hash of Issuers public key 759 serialNumber CertificateSerialNumber } 761 OCSPResponse ::= SEQUENCE { 762 responseStatus OCSPResponseStatus, 763 responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } 765 OCSPResponseStatus ::= ENUMERATED { 766 successful (0), --Response has valid confirmations 767 malformedRequest (1), --Illegal confirmation request 768 internalError (2), --Internal error in issuer 769 tryLater (3), --Try again later 770 certRequired (4), --Must supply certificate 771 sigRequired (5), --Must sign the request 772 unauthorized (6) --Request unauthorized } 774 ResponseBytes ::= SEQUENCE { 775 responseType OBJECT IDENTIFIER, 776 response OCTET STRING } 778 BasicOCSPResponse ::= SEQUENCE { 779 tbsResponseData ResponseData, 780 signatureAlgorithm AlgorithmIdentifier, 781 signature BIT STRING, 782 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 784 ResponseData ::= SEQUENCE { 785 version [0] EXPLICIT Version DEFAULT v1, 786 responderID ResponderID, 787 producedAt GeneralizedTime, 788 responses SEQUENCE OF SingleResponse, 789 responseExtensions [1] EXPLICIT Extensions OPTIONAL } 791 ResponderID ::= CHOICE { 792 byName [1] Name, 793 byKey [2] KeyHash } 795 KeyHash ::= OCTET STRING --SHA-1 hash of responder's public key 796 --(excluding the tag and length fields) 798 SingleResponse ::= SEQUENCE { 799 certID CertID, 800 certStatus CertStatus, 801 thisUpdate GeneralizedTime, 802 nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, 803 singleExtensions [1] EXPLICIT Extensions OPTIONAL } 805 CertStatus ::= CHOICE { 806 good [0] IMPLICIT NULL, 807 revoked [1] IMPLICIT RevokedInfo, 808 unknown [2] IMPLICIT UnknownInfo } 810 RevokedInfo ::= SEQUENCE { 811 revocationTime GeneralizedTime, 812 revocationReason [0] EXPLICIT CRLReason OPTIONAL } 814 UnknownInfo ::= NULL -- this can be replaced with an enumeration 816 archiveCutoff ::= GeneralizedTime 818 AcceptableResponses ::= SEQUENCE OF { id OBJECT IDENTIFIER } 820 ServiceLocator :: = SEQUENCE { 821 issuer Name, 822 locator AuthorityInfoAccessSyntax } 824 -- Object Identifiers 826 id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } 827 id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } 828 id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } 829 id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } 830 id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } 831 id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 } 832 id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } 833 id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 } 834 id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 } 836 END 838 Appendix C: MIME registrations 840 C.1 application/ocsp-request 842 To: ietf-types@iana.org 843 Subject: Registration of MIME media type application/ocsp-request 845 MIME media type name: application 847 MIME subtype name: ocsp-request 849 Required parameters: None 851 Optional parameters: None 853 Encoding considerations: binary or Base64 855 Security considerations: Carries a request for information. This 856 request may optionally be cryptographically signed. 858 Interoperability considerations: None 860 Published specification: IETF PKIX Working Group Draft on Online 861 Certificate Status Protocol - OCSP 863 Applications which use this media type: OCSP clients 865 Additional information: 867 Magic number(s): None 868 File extension(s): .ORQ 869 Macintosh File Type Code(s): none 871 Person & email address to contact for further information: 872 Ambarish Malpani 874 Intended usage: COMMON 876 Author/Change controller: 877 Ambarish Malpani 879 C.2 application/ocsp-response 881 To: ietf-types@iana.org 882 Subject: Registration of MIME media type application/ocsp-response 884 MIME media type name: application 886 MIME subtype name: ocsp-response 888 Required parameters: None 890 Optional parameters: None 891 Encoding considerations: binary or Base64 893 Security considerations: Carries a cryptographically signed 894 response 896 Interoperability considerations: None 898 Published specification: IETF PKIX Working Group Draft on Online 899 Certificate Status Protocol - OCSP 901 Applications which use this media type: OCSP servers 903 Additional information: 905 Magic number(s): None 906 File extension(s): .ORS 907 Macintosh File Type Code(s): none 909 Person & email address to contact for further information: 910 Ambarish Malpani 912 Intended usage: COMMON 914 Author/Change controller: 915 Ambarish Malpani