idnits 2.17.1 draft-ietf-pkix-ocsp-08.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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 10 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 (March 1999) is 9167 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 859 -- Looks like a reference, but probably isn't: '1' on line 854 -- Looks like a reference, but probably isn't: '2' on line 855 == Unused Reference: 'HTTP' is defined on line 667, but no explicit reference was found in the text == Unused Reference: 'URL' is defined on line 674, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) ** 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 (~~), 4 warnings (==), 5 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-08.txt Rich Ankney (CertCo) 4 Ambarish Malpani (ValiCert) 5 Slava Galperin (Teknowledge) 6 Carlisle Adams (Entrust Technologies) 8 Expires in 6 months March 1999 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 and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 2. Abstract 37 This document specifies a protocol useful in determining the current 38 status of a digital certificate without requiring CRLs. Additional 39 mechanisms addressing PKIX operational requirements are specified in 40 separate documents. 42 An overview of the protocol is provided in section 3. Functional 43 requirements are specified in section 4. Details of the protocol are 44 in section 5. We cover security issues with the protocol in section 45 6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1 46 syntactic elements and appendix C specifies the mime types for the 47 messages. 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document (in uppercase, as shown) are to be interpreted as described 52 in [RFC2119]. 54 3. Protocol Overview 56 In lieu of or as a supplement to checking against a periodic CRL, it 57 may be necessary to obtain timely information regarding the 58 revocation status of a certificate (cf. [RFC2459], Section 3.3). 59 Examples include high-value funds transfer or large stock trades. 61 The Online Certificate Status Protocol (OCSP) enables applications to 62 determine the (revocation) state of an identified certificate. OCSP 63 may be used to satisfy some of the operational requirements of 64 providing more timely revocation information than is possible with 65 CRLs and may also be used to obtain additional status information. An 66 OCSP client issues a status request to an OCSP responder and suspends 67 acceptance of the certificate in question until the responder 68 provides a response. 70 This protocol specifies the data that needs to be exchanged between 71 an application checking the status of a certificate and the server 72 providing that status. 74 3.1 Request 76 An OCSP request contains the following data: 78 -- protocol version 79 -- service request 80 -- target certificate identifier 81 -- optional extensions which MAY be processed by the OCSP Responder 83 Upon receipt of a request, an OCSP Responder determines if: 85 1. the message is well formed 87 2. the responder is configured to provide the requested service and 89 3. the request contains the information needed by the responder 90 If any one of the prior conditions are not met, the OCSP responder 91 produces an error message; otherwise, it returns a definitive 92 response. 94 3.2 Response 96 OCSP responses can be of various types. An OCSP response consists of 97 a response type and the bytes of the actual response. There is one 98 basic type of OCSP response that MUST be supported by all OCSP 99 servers and clients. The rest of this section pertains only to this 100 basic response type. 102 All definitive response messages SHALL be digitally signed. The key 103 used to sign the response MUST belong to one of the following: 105 -- the CA who issued the certificate in question 106 -- a Trusted Responder whose public key is trusted by the requester 107 -- a CA Designated Responder (Authorized Responder) who holds a 108 specially marked certificate issued directly by the CA, indicating 109 that the responder may issue OCSP responses for that CA 111 A definitive response message is composed of: 113 -- version of the response syntax 114 -- name of the responder 115 -- responses for each of the certificates in a request 116 -- optional extensions 117 -- signature algorithm OID 118 -- signature computed across hash of the response 120 The response for each of the certificates in a request consists of 122 -- target certificate identifier 123 -- certificate status value 124 -- response validity interval 125 -- optional extensions 127 This specification defines the following definitive response 128 indicators for use in the certificate status value: 130 -- good 131 -- revoked 132 -- unknown 134 The "good" state indicates a positive response to the status inquiry. 135 At a minimum, this positive response indicates that the certificate 136 is not revoked, but does not necessarily mean that the certificate 137 was ever issued or that the time at which the response was produced 138 is within the certificate's validity interval. Response extensions 139 may be used to convey additional information on assertions made by 140 the responder regarding the status of the certificate such as 141 positive statement about issuance, validity, etc. 143 The "revoked" state indicates that the certificate has been revoked 144 (either permanantly or temporarily (on hold)). 146 The "unknown" state indicates that the responder doesn't know about 147 the certificate being requested. 149 3.3 Exception Cases 151 In case of errors, the OCSP Responder may return an error message. 152 These messages are not signed. Errors can be of the following types: 154 -- malformedRequest 155 -- internalError 156 -- tryLater 157 -- sigRequired 158 -- unauthorized 160 A server produces the "malformedRequest" response if the request 161 received does not conform to the OCSP syntax. 163 The response "internalError" indicates that the OCSP responder 164 reached an inconsistent internal state. The query should be retried, 165 potentially with another responder. 167 In the event that the OCSP responder is operational, but unable to 168 return a status for the requested certificate, the "tryLater" 169 response can be used to indicate that the service exists, but is 170 temporarily unable to respond. 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. This certificate MUST be issued directly to the 211 responder by the cognizant CA. 213 3.7 CA Key Compromise 215 If an OCSP responder knows that a particular CA's private key has 216 been compromised, it MAY return the revoked state for all 217 certificates issued by that CA. 219 4. Functional Requirements 221 4.1 Certificate Content 223 In order to convey to OCSP clients a well-known point of information 224 access, CAs SHALL provide the capability to include the 225 AuthorityInfoAccess extension (defined in [RFC2459], section 4.2.2.1) 226 in certificates that can be checked using OCSP. Alternatively, the 227 accessLocation for the OCSP provider may be configured locally at the 228 OCSP client. 230 CAs that support an OCSP service, either hosted locally or provided 231 by an Authorized Responder, MUST provide for the inclusion of a value 232 for a uniformResourceIndicator (URI) accessLocation and the OID value 233 id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE. 235 The value of the accessLocation field in the subject certificate 236 defines the transport (e.g. HTTP) used to access the OCSP responder 237 and may contain other transport dependent information (e.g. a URL). 239 4.2 Signed Response Acceptance Requirements 241 Prior to accepting a signed response as valid, OCSP clients SHALL 242 confirm that: 244 1. The certificate identified in a received response corresponds to 245 that which was identified in the corresponding request; 247 2. The signature on the response is valid; 249 3. The identity of the signer matches the intended recipient of the 250 request. 252 4. The signer is currently authorized to sign the response. 254 5. The time at which the status being indicated is known to be 255 correct (thisUpdate) is sufficiently recent. 257 6. When available, the time at or before which newer information will 258 be available about the status of the certificate (nextUpdate) is 259 greater than the current time. 261 5. Detailed Protocol 263 The ASN.1 syntax imports terms defined in [RFC2459]. For signature 264 calculation, the data to be signed is encoded using the ASN.1 265 distinguished encoding rules (DER) [X.690]. 267 ASN.1 EXPLICIT tagging is used as a default unless specified 268 otherwise. 270 The terms imported from elsewhere are: Extensions, 271 CertificateSerialNumber, SubjectPublicKeyInfo, Name, 272 AlgorithmIdentifier, CRLReason 274 5.1 Requests 276 This section specifies the ASN.1 specification for a confirmation 277 request. The actual formatting of the message could vary depending on 278 the transport mechanism used (HTTP, SMTP, LDAP, etc.). 280 5.1.1 Request Syntax 282 OCSPRequest ::= SEQUENCE { 283 tbsRequest TBSRequest, 284 optionalSignature [0] EXPLICIT Signature OPTIONAL } 286 TBSRequest ::= SEQUENCE { 287 version [0] EXPLICIT Version DEFAULT v1, 288 requestorName [1] EXPLICIT GeneralName OPTIONAL, 289 requestList SEQUENCE OF Request, 290 requestExtensions [2] EXPLICIT Extensions OPTIONAL } 292 Signature ::= SEQUENCE { 293 signatureAlgorithm AlgorithmIdentifier, 294 signature BIT STRING, 295 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL} 297 Version ::= INTEGER { v1(0) } 299 Request ::= SEQUENCE { 300 reqCert CertID, 301 singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } 303 CertID ::= SEQUENCE { 304 hashAlgorithm AlgorithmIdentifier, 305 issuerNameHash OCTET STRING, -- Hash of Issuer's DN 306 issuerKeyHash OCTET STRING, -- Hash of Issuers public key 307 serialNumber CertificateSerialNumber } 309 issuerNameHash is the hash of the Issuer's distinguished name. The 310 hash shall be calculated over the DER encoding of the issuer's name 311 field in the certificate being checked. issuerKeyHash is the hash of 312 the Issuer's public key. The hash shall be calculated over the value 313 (excluding tag and length) of the subject public key field in the 314 issuer's certificate. The hash algorithm used for both these hashes, 315 is identified in hashAlgorithm. serialNumber is the serial number of 316 the certificate for which status is being requested. 318 5.1.2 Notes on the Request Syntax 320 The primary reason to use the hash of the CA's public key in addition 321 to the hash of the CA's name, to identify the issuer, is that it is 322 possible that two CAs may choose to use the same Name (uniqueness in 323 the Name is a recommendation that cannot be enforced). Two CAs will 324 never, however, have the same public key unless the CAs either 325 explicitly decided to share their private key, or the key of one of 326 the CAs was compromised. 328 Support for any specific extension is OPTIONAL. The critical flag 329 SHOULD NOT be set for any of them. Section 5.4 suggests several 330 useful extensions. Additional extensions MAY be defined in 331 additional RFCs. Unrecognized extensions MUST be ignored (unless they 332 have the critical flag set and are not understood). 334 The requestor MAY choose to sign the OCSP request. In that case, the 335 signature is computed over the tbsRequest structure. If the request 336 is signed, the requestor SHALL specify its name in the requestorName 337 field. Also, for signed requests, the requestor MAY include 338 certificates that help the OCSP responder verify the requestor's 339 signature in the certs field of Signature. 341 5.2 Response Syntax 343 This section specifies the ASN.1 specification for a confirmation 344 response. The actual formatting of the message could vary depending 345 on the transport mechanism used (HTTP, SMTP, LDAP, etc.). 347 5.2.1 ASN.1 Specification of the OCSP Response 349 An OCSP response at a minimum consists of a responseStatus field 350 indicating the processing status of the prior request. If the value 351 of responseStatus is one of the error conditions, responseBytes are 352 not set. 354 OCSPResponse ::= SEQUENCE { 355 responseStatus OCSPResponseStatus, 356 responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } 358 OCSPResponseStatus ::= ENUMERATED { 359 successful (0), --Response has valid confirmations 360 malformedRequest (1), --Illegal confirmation request 361 internalError (2), --Internal error in issuer 362 tryLater (3), --Try again later 363 --(4) is not used 364 sigRequired (5), --Must sign the request 365 unauthorized (6) --Request unauthorized 366 } 368 The value for responseBytes consists of an OBJECT IDENTIFIER and a 369 response syntax identified by that OID encoded as an OCTET STRING: 371 ResponseBytes ::= SEQUENCE { 372 responseType OBJECT IDENTIFIER, 373 response OCTET STRING } 375 For a basic OCSP responder, responseType will be id-pkix-ocsp-basic: 377 id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } 378 id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } 380 OCSP responders SHALL be capable of producing responses of the id- 381 pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL be 382 capable of receiving and processing responses of the id-pkix-ocsp- 383 basic response type. 385 The value for response SHALL be the DER encoding of 386 BasicOCSPResponse: 388 BasicOCSPResponse ::= SEQUENCE { 389 tbsResponseData ResponseData, 390 signatureAlgorithm AlgorithmIdentifier, 391 signature BIT STRING, 392 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 394 The value for signature SHALL be computed on the hash of the DER 395 encoding ResponseData. 397 ResponseData ::= SEQUENCE { 398 version [0] EXPLICIT Version DEFAULT v1, 399 responderID ResponderID, 400 producedAt GeneralizedTime, 401 responses SEQUENCE OF SingleResponse, 402 responseExtensions [1] EXPLICIT Extensions OPTIONAL } 404 ResponderID ::= CHOICE { 405 byName [1] Name, 406 byKey [2] KeyHash } 408 KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key 409 (excluding the tag and length fields) 411 SingleResponse ::= SEQUENCE { 412 certID CertID, 413 certStatus CertStatus, 414 thisUpdate GeneralizedTime, 415 nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, 416 singleExtensions [1] EXPLICIT Extensions OPTIONAL } 418 CertStatus ::= CHOICE { 419 good [0] IMPLICIT NULL, 420 revoked [1] IMPLICIT RevokedInfo, 421 unknown [2] IMPLICIT UnknownInfo } 423 RevokedInfo ::= SEQUENCE { 424 revocationTime GeneralizedTime, 425 revocationReason [0] EXPLICIT CRLReason OPTIONAL } 427 UnknownInfo ::= NULL -- this can be replaced with an enumeration 429 5.2.2 Notes on OCSP Responses 431 5.2.2.1 Time 433 The thisUpdate and nextUpdate fields define a recommended validity 434 interval. This interval corresponds to the {thisUpdate, nextUpdate} 435 interval in CRLs. Responses whose nextUpdate value is earlier than 436 the local system time value SHOULD be considered unreliable. 437 Responses whose thisUpdate time is later than the local system time 438 SHOULD be considered unreliable. Responses where the nextUpdate value 439 is not set are equivalent to a CRL with no time for nextUpdate (see 440 Section 3.4). 442 The producedAt time is the time at which this response was signed. 444 5.2.2.2 Authorized Responders 446 The key that signs a certificate's status information need not be the 447 same key that signed the certificate. It is necessary however to 448 ensure that the entity signing this information is authorized to do 449 so. Therefore, a certificate's issuer MUST either sign the OCSP 450 responses itself or it MUST explicitly designate this authority to 451 another entity. OCSP signing delegation SHALL be designated by the 452 inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate 453 extension included in the OCSP response signer's certificate. This 454 certificate MUST be issued directly by the CA that issued the 455 certificate in question. 457 id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9} 459 Systems or applications that rely on OCSP responses MUST be capable 460 of detecting and enforcing use of the id-ad-ocspSigning value as 461 described above. They MAY provide a means of locally configuring one 462 or more OCSP signing authorities, and specifying the set of CAs for 463 which each signing authority is trusted. They MUST reject the 464 response if the certificate required to validate the signature on the 465 response fails to meet at least one of the following criteria: 467 1. Matches a local configuration of OCSP signing authority for the 468 certificate in question; or 470 2. Is the certificate of the CA that issued the certificate in 471 question; or 473 3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage 474 extension and is issued by the CA that issued the certificate in 475 question." 477 Additional acceptance or rejection criteria may apply to either the 478 response itself or to the certificate used to validate the signature 479 on the response. 481 5.2.2.2.1 Revocation Checking of an Authorized Responder 483 Since an Authorized OCSP responder provides status information for 484 one or more CAs, OCSP clients need to know how to check that an 485 authorized responder's certificate has not been revoked. CAs may 486 choose to deal with this problem in one of three ways: 488 - A CA may specify that an OCSP client can trust a responder for the 489 lifetime of the responder's certificate. The CA does so by including 490 the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical 491 extension. The value of the extension should be NULL. CAs issuing 492 such a certificate should realized that a compromise of the 493 responder's key, is as serious as the compromise of a CA key used to 494 sign CRLs, at least for the validity period of this certificate. CA's 495 may choose to issue this type of certificate with a very short 496 lifetime and renew it frequently. 498 id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } 500 - A CA may specify how the responder's certificate be checked for 501 revocation. This can be done using CRL Distribution Points if the 502 check should be done using CRLs or CRL Distribution Points, or 503 Authority Information Access if the check should be done in some 504 other way. Details for specifying either of these two mechanisms are 505 available in [RFC2459]. 507 - A CA may choose not to specify any method of revocation checking 508 for the responder's certificate, in which case, it would be up to the 509 OCSP client's local security policy to decide whether that 510 certificate should be checked for revocation or not. 512 5.3 Mandatory and Optional Cryptographic Algorithms 514 Clients that request OCSP services SHALL be capable of processing 515 responses signed used DSA keys identified by the DSA sig-alg-oid 516 specified in section 7.2.2 of [RFC2459]. Clients SHOULD also be 517 capable of processing RSA signatures as specified in section 7.2.1 of 518 [RFC2459]. OCSP responders SHALL support the SHA1 hashing algorithm. 520 5.4 Extensions 522 This section defines some standard extensions, based on the extension 523 model employed in X.509 version 3 certificates see [RFC2459]. Support 524 for all extensions is optional for both clients and responders. For 525 each extension, the definition indicates its syntax, processing 526 performed by the OCSP Responder, and any extensions which are 527 included in the corresponding response. 529 5.4.1 Nonce 531 The nonce cryptographically binds a request and a response to prevent 532 replay attacks. The nonce is included as one of the requestExtensions 533 in requests, while in responses it would be included as one of the 534 responseExtensions. In both the request and the response, the nonce 535 will be identified by the object identifier id-pkix-ocsp-nonce, while 536 the extnValue is the value of the nonce. 538 id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } 540 5.4.2 CRL References 542 It may be desirable for the OCSP responder to indicate the CRL on 543 which a revoked or onHold certificate is found. This can be useful 544 where OCSP is used between repositories, and also as an auditing 545 mechanism. The CRL may be specified by a URL (the URL at which the 546 CRL is available), a number (CRL number) or a time (the time at which 547 the relevant CRL was created). These extensions will be specified as 548 singleExtensions. The identifier for this extension will be id-pkix- 549 ocsp-crl, while the value will be CrlID. 551 id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } 553 CrlID ::= SEQUENCE { 554 crlUrl [0] EXPLICIT IA5String OPTIONAL, 555 crlNum [1] EXPLICIT INTEGER OPTIONAL, 556 crlTime [2] EXPLICIT GeneralizedTime OPTIONAL } 558 For the choice crlUrl, the IA5String will specify the URL at which 559 the CRL is available. For crlNum, the INTEGER will specify the value 560 of the CRL number extension of the relevant CRL. For crlTime, the 561 GeneralizedTime will indicate the time at which the relevant CRL was 562 issued. 564 5.4.3 Acceptable Response Types 566 An OCSP client MAY wish to specify the kinds of response types it 567 understands. To do so, it SHOULD use an extension with the OID id- 568 pkix-ocsp-response, and the value AcceptableResponses. This 569 extension is included as one of the requestExtensions in requests. 570 The OIDs included in AcceptableResponses are the OIDs of the various 571 response types this client can accept (e.g., id-pkix-ocsp-basic). 573 id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 } 575 AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER 577 As noted in section 5.2.1, OCSP responders SHALL be capable of 578 responding with responses of the id-pkix-ocsp-basic response type. 579 Correspondingly, OCSP clients SHALL be capable of receiving and 580 processing responses of the id-pkix-ocsp-basic response type. 582 5.4.4 Archive Cutoff 584 An OCSP responder MAY choose to retain revocation information beyond 585 a certificate's expiration. The date obtained by subtracting this 586 retention interval value from the producedAt time in a response is 587 defined as the certificate's "archive cutoff" date. 589 OCSP-enabled applications would use an OCSP archive cutoff date to 590 contribute to a proof that a digital signature was (or was not) 591 reliable on the date it was produced even if the certificate needed 592 to validate the signature has long since expired. 594 OCSP servers that provide support for such historical reference 595 SHOULD include an archive cutoff date extension in responses. If 596 included, this value SHALL be provided as an OCSP singleExtensions 597 extension identified by id-pkix-ocsp-archive-cutoff and of syntax 598 GeneralizedTime: 600 id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 } 602 ArchiveCutoff ::= GeneralizedTime 604 To illustrate, if a server is operated with a 7-year retention 605 interval policy and status was produced at time t1 then the value for 606 ArchiveCutoff in the response would be (t1 - 7 years). 608 5.4.5 CRL Entry Extensions 610 All the extensions specified as CRL Entry Extensions - in Section 5.3 611 of [RFC2459] - are also supported as singleExtensions. 613 5.4.6 Service Locator 615 An OCSP server may be operated in a mode whereby the server receives 616 a request and routes it to the OCSP server which is known to be 617 authoritative for the identified certificate. The serviceLocator 618 request extension is defined for this purpose. This extension is 619 included as one of the singleRequestExtensions in requests. 621 id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 } 623 ServiceLocator ::= SEQUENCE { 624 issuer Name, 625 locator AuthorityInfoAccessSyntax OPTIONAL } 627 Values for these fields are obtained from the corresponding fields in 628 the subject certificate. 630 6. Security Considerations 632 For this service to be effective, certificate using systems must 633 connect to the certificate status service provider. In the event such 634 a connection cannot be obtained, certificate-using systems could 635 implement CRL processing logic as a fall-back position. 637 A denial of service vulnerability is evident with respect to a flood 638 of queries. The production of a cryptographic signature significantly 639 affects response generation cycle time, thereby exacerbating the 640 situation. Unsigned error responses open up the protocol to another 641 denial of service attack, where the attacker sends false error 642 responses. 644 The use of precomputed responses allows replay attacks in which an 645 old (good) response is replayed prior to its expiration date but 646 after the certificate has been revoked. Deployments of OCSP should 647 carefully evaluate the benefit of precomputed responses against the 648 probability of a replay attack and the costs associated with its 649 successful execution. 651 Requests do not contain the responder they are directed to. This 652 allows an attacker to replay a request to any number of OCSP 653 responders. 655 The reliance of HTTP caching in some deployment scenarios may result 656 in unexpected results if intermediate servers are incorrectly 657 configured or are known to possess cache management faults. 658 Implementors are advised to take the reliability of HTTP cache 659 mechanisms into account when deploying OCSP over HTTP. 661 7. References 663 [RFC2459] Internet X.509 Public Key Infrastructure Certificate and 664 CRL Profile, R. Housley, W. Ford, W. Polk, D. Solo, RFC 665 2459, January, 1999. 667 [HTTP] Hypertext Transfer Protocol -- HTTP/1.1, R. Fielding, J. 668 Gettys, J. Mogul, H. Frystyk and T. Berners-Lee, RFC 2068, 669 January 1997. 671 [RFC2119] Key words for use in RFCs to Indicate Requirement Levels, 672 S. Bradner, RFC 2119, March 1997. 674 [URL] Uniform Resource Locators (URL), T. Berners-Lee, L. 675 Masinter, M. McCahill, RFC 1738, December 1994. 677 [X.690] ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995, 678 Information Technology - ASN.1 encoding rules: 679 Specification of Basic Encoding Rules (BER), Canonical 680 Encoding Rules (CER) and Distinguished Encoding Rules 681 (DER). 683 8. Author's Address 685 Michael Myers 686 VeriSign, Inc. 687 1390 Shorebird Way 688 Mountain View, CA 94019 689 mmyers@verisign.com 691 Rich Ankney 692 CertCo, LLC 693 13506 King Charles Dr. 694 Chantilly, VA 20151 695 rankney@erols.com 697 Ambarish Malpani 698 ValiCert, Inc. 699 3160 W. Bayshore Drive 700 Palo Alto, CA 94303 701 ambarish@valicert.com 702 650.567.5457 704 Slava Galperin 705 Teknowledge Corporation 706 1810 Embarcadero Road 707 Palo Alto, CA 708 galperin@teknowledge.com 710 Carlisle Adams 711 Entrust Technologies 712 750 Heron Road, Suite E08 713 Ottawa, Ontario 714 K1V 1A7 715 Canada 716 cadams@entrust.com 718 Appendix A 720 A.1 OCSP over HTTP 722 This section describes the formatting that will be done to the request 723 and response to support HTTP. 725 A.1.1 Request 727 HTTP based OCSP requests can use either the GET or the POST method to 728 submit their requests. To enable HTTP caching, small requests (that 729 after encoding are less than 255 bytes), MAY be submitted using GET. If 730 HTTP caching is not important, or the request is greater than 255 bytes, 731 the request SHOULD be submitted using POST. Where privacy is a 732 requirement, OCSP transactions exchanged using HTTP MAY be protected 733 using either TLS/SSL or some other lower layer protocol. 735 An OCSP request using the GET method is constructed as follows: 737 GET {url}/{url-encoding of base-64 encoding of the DER encoding of the 738 OCSPRequest} 740 where {url} may be derived from the value of AuthorityInfoAccess or 741 other local configuration of the OCSP client. 743 An OCSP request using the POST method is constructed as follows: The 744 Content-Type header has the value "application/ocsp-request" while the 745 body of the message is the binary value of the DER encoding of the OCSPRequest. 747 A.1.2 Response 749 An HTTP-based OCSP response is composed of the appropriate HTTP 750 headers, followed by the binary value of the DER encoding of the 751 OCSPResponse. The Content-Type header has the value 752 "application/ocsp-response". The Content-Length header SHOULD specify 753 the length of the response. Other HTTP headers MAY be present and MAY 754 be ignored if not understood by the requestor. 756 Appendix B: OCSP in ASN.1 758 OCSP DEFINITIONS EXPLICIT TAGS::= 760 BEGIN 761 IMPORTS 763 -- Directory Authentication Framework (X.509) 764 Certificate, AlgorithmIdentifier, CRLReason 765 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 766 module(1) authenticationFramework(7) 3 } 768 -- PKIX Certificate Extensions 769 AuthorityInfoAccessSyntax 770 FROM PKIX1Implicit88 {iso(1) identified-organization(3) 771 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 772 id-mod(0) id-pkix1-implicit-88(2)} 774 Name, GeneralName, CertificateSerialNumber, Extensions, 775 id-kp, id-ad-ocsp 776 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 777 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 778 id-mod(0) id-pkix1-explicit-88(1)}; 780 OCSPRequest ::= SEQUENCE { 781 tbsRequest TBSRequest, 782 optionalSignature [0] EXPLICIT Signature OPTIONAL } 784 TBSRequest ::= SEQUENCE { 785 version [0] EXPLICIT Version DEFAULT v1, 786 requestorName [1] EXPLICIT GeneralName OPTIONAL, 787 requestList SEQUENCE OF Request, 788 requestExtensions [2] EXPLICIT Extensions OPTIONAL } 790 Signature ::= SEQUENCE { 791 signatureAlgorithm AlgorithmIdentifier, 792 signature BIT STRING, 793 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 795 Version ::= INTEGER { v1(0) } 797 Request ::= SEQUENCE { 798 reqCert CertID, 799 singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } 801 CertID ::= SEQUENCE { 802 hashAlgorithm AlgorithmIdentifier, 803 issuerNameHash OCTET STRING, -- Hash of Issuer's DN 804 issuerKeyHash OCTET STRING, -- Hash of Issuers public key 805 serialNumber CertificateSerialNumber } 807 OCSPResponse ::= SEQUENCE { 808 responseStatus OCSPResponseStatus, 809 responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } 811 OCSPResponseStatus ::= ENUMERATED { 812 successful (0), --Response has valid confirmations 813 malformedRequest (1), --Illegal confirmation request 814 internalError (2), --Internal error in issuer 815 tryLater (3), --Try again later 816 --(4) is not used 817 sigRequired (5), --Must sign the request 818 unauthorized (6) --Request unauthorized 819 } 821 ResponseBytes ::= SEQUENCE { 822 responseType OBJECT IDENTIFIER, 823 response OCTET STRING } 825 BasicOCSPResponse ::= SEQUENCE { 826 tbsResponseData ResponseData, 827 signatureAlgorithm AlgorithmIdentifier, 828 signature BIT STRING, 829 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 831 ResponseData ::= SEQUENCE { 832 version [0] EXPLICIT Version DEFAULT v1, 833 responderID ResponderID, 834 producedAt GeneralizedTime, 835 responses SEQUENCE OF SingleResponse, 836 responseExtensions [1] EXPLICIT Extensions OPTIONAL } 838 ResponderID ::= CHOICE { 839 byName [1] Name, 840 byKey [2] KeyHash } 842 KeyHash ::= OCTET STRING --SHA-1 hash of responder's public key 843 --(excluding the tag and length fields) 845 SingleResponse ::= SEQUENCE { 846 certID CertID, 847 certStatus CertStatus, 848 thisUpdate GeneralizedTime, 849 nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, 850 singleExtensions [1] EXPLICIT Extensions OPTIONAL } 852 CertStatus ::= CHOICE { 853 good [0] IMPLICIT NULL, 854 revoked [1] IMPLICIT RevokedInfo, 855 unknown [2] IMPLICIT UnknownInfo } 857 RevokedInfo ::= SEQUENCE { 858 revocationTime GeneralizedTime, 859 revocationReason [0] EXPLICIT CRLReason OPTIONAL } 861 UnknownInfo ::= NULL -- this can be replaced with an enumeration 863 ArchiveCutoff ::= GeneralizedTime 865 AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER 867 ServiceLocator ::= SEQUENCE { 868 issuer Name, 869 locator AuthorityInfoAccessSyntax } 871 -- Object Identifiers 873 id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } 874 id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } 875 id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } 876 id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } 877 id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } 878 id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 } 879 id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } 880 id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 } 881 id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 } 883 END 885 Appendix C: MIME registrations 887 C.1 application/ocsp-request 889 To: ietf-types@iana.org 890 Subject: Registration of MIME media type application/ocsp-request 892 MIME media type name: application 894 MIME subtype name: ocsp-request 896 Required parameters: None 898 Optional parameters: None 900 Encoding considerations: binary 901 Security considerations: Carries a request for information. This 902 request may optionally be cryptographically signed. 904 Interoperability considerations: None 906 Published specification: IETF PKIX Working Group Draft on Online 907 Certificate Status Protocol - OCSP 909 Applications which use this media type: OCSP clients 911 Additional information: 913 Magic number(s): None 914 File extension(s): .ORQ 915 Macintosh File Type Code(s): none 917 Person & email address to contact for further information: 918 Ambarish Malpani 920 Intended usage: COMMON 922 Author/Change controller: 923 Ambarish Malpani 925 C.2 application/ocsp-response 927 To: ietf-types@iana.org 928 Subject: Registration of MIME media type application/ocsp-response 930 MIME media type name: application 932 MIME subtype name: ocsp-response 934 Required parameters: None 936 Optional parameters: None 937 Encoding considerations: binary 939 Security considerations: Carries a cryptographically signed 940 response 942 Interoperability considerations: None 944 Published specification: IETF PKIX Working Group Draft on Online 945 Certificate Status Protocol - OCSP 947 Applications which use this media type: OCSP servers 948 Additional information: 950 Magic number(s): None 951 File extension(s): .ORS 952 Macintosh File Type Code(s): none 954 Person & email address to contact for further information: 955 Ambarish Malpani 957 Intended usage: COMMON 959 Author/Change controller: 960 Ambarish Malpani