idnits 2.17.1 draft-ietf-pkix-rfc2560bis-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC6277, but the abstract doesn't seem to directly say this. It does mention RFC6277 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (April 15, 2013) is 4026 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 1621 -- Looks like a reference, but probably isn't: '1' on line 1622 -- Looks like a reference, but probably isn't: '2' on line 1623 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) ** Obsolete normative reference: RFC 6277 (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 2560 (Obsoleted by RFC 6960) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Santesson 3 Intended Status: Proposed Standard (3xA Security) 4 Obsoletes: 2560, 6277 (if approved) M. Myers 5 Updates: 5912 (if approved) (TraceRoute Security) 6 Expires: October 17, 2013 R. Ankney 7 A. Malpani 8 (CA Technologies) 9 S. Galperin 10 (A9) 11 C. Adams 12 (University of Ottawa) 13 April 15, 2013 15 X.509 Internet Public Key Infrastructure 16 Online Certificate Status Protocol - OCSP 17 draft-ietf-pkix-rfc2560bis-20 19 Abstract 21 This document specifies a protocol useful in determining the current 22 status of a digital certificate without requiring CRLs. Additional 23 mechanisms addressing PKIX operational requirements are specified in 24 separate documents. This document obsoletes RFC 2560 and RFC 6277, 25 and updates RFC 5912. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2013 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.1 Requirements Language . . . . . . . . . . . . . . . . . . . 5 67 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 68 2.1 Request . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 2.2 Response . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 2.3 Exception Cases . . . . . . . . . . . . . . . . . . . . . . 8 71 2.4 Semantics of thisUpdate, nextUpdate and producedAt . . . . 9 72 2.5 Response Pre-production . . . . . . . . . . . . . . . . . . 9 73 2.6 OCSP Signature Authority Delegation . . . . . . . . . . . . 10 74 2.7 CA Key Compromise . . . . . . . . . . . . . . . . . . . . . 10 75 3. Functional Requirements . . . . . . . . . . . . . . . . . . . 10 76 3.1 Certificate Content . . . . . . . . . . . . . . . . . . . . 10 77 3.2 Signed Response Acceptance Requirements . . . . . . . . . . 11 78 4. Detailed Protocol . . . . . . . . . . . . . . . . . . . . . . 11 79 4.1 Requests . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 4.1.1 Request Syntax . . . . . . . . . . . . . . . . . . . . 11 81 4.1.2 Notes on the Request Syntax . . . . . . . . . . . . . . 13 82 4.2 Response Syntax . . . . . . . . . . . . . . . . . . . . . . 14 83 4.2.1 ASN.1 Specification of the OCSP Response . . . . . . . 14 84 4.2.2 Notes on OCSP Responses . . . . . . . . . . . . . . . . 16 85 4.2.2.1 Time . . . . . . . . . . . . . . . . . . . . . . . 16 86 4.2.2.2 Authorized Responders . . . . . . . . . . . . . . . 16 87 4.2.2.2.1 Revocation Checking of an Authorized 88 Responder . . . . . . . . . . . . . . . . . . . 17 89 4.2.2.3 Basic Response . . . . . . . . . . . . . . . . . . . 18 90 4.3 Mandatory and Optional Cryptographic Algorithms . . . . . . 19 91 4.4 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 19 92 4.4.1 Nonce . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 4.4.2 CRL References . . . . . . . . . . . . . . . . . . . . 20 94 4.4.3 Acceptable Response Types . . . . . . . . . . . . . . . 20 95 4.4.4 Archive Cutoff . . . . . . . . . . . . . . . . . . . . 20 96 4.4.5 CRL Entry Extensions . . . . . . . . . . . . . . . . . 21 97 4.4.6 Service Locator . . . . . . . . . . . . . . . . . . . . 21 98 4.4.7 Preferred Signature Algorithms . . . . . . . . . . . . 21 99 4.4.7.1 Extension Syntax . . . . . . . . . . . . . . . . . . 22 100 4.4.7.2 Responder Signature Algorithm Selection . . . . . . 23 101 4.4.7.2.1 Dynamic Response . . . . . . . . . . . . . . . 23 102 4.4.7.2.2 Static Response . . . . . . . . . . . . . . . . 24 103 4.4.8 Extended Revoked Definition . . . . . . . . . . . . . . 24 104 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 105 5.1 Preferred Signature Algorithms . . . . . . . . . . . . . . . 26 106 5.1.1 Use of insecure algorithms . . . . . . . . . . . . . . 27 107 5.1.2 Man in the Middle Downgrade Attack . . . . . . . . . . 27 108 5.1.3. Denial of Service Attack . . . . . . . . . . . . . . . 27 109 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 29 110 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 111 7.1. Normative References . . . . . . . . . . . . . . . . . . . 29 112 7.2. Informative References . . . . . . . . . . . . . . . . . . 30 113 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 31 114 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 115 A.1 OCSP over HTTP . . . . . . . . . . . . . . . . . . . . . . . 31 116 A.1.1 Request . . . . . . . . . . . . . . . . . . . . . . . . 31 117 A.1.2 Response . . . . . . . . . . . . . . . . . . . . . . . . 31 118 Appendix B. ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 32 119 B.1. OCSP in ASN.1 - 1998 Syntax . . . . . . . . . . . . . . . 32 120 B.2. OCSP in ASN.1 - 2008 Syntax . . . . . . . . . . . . . . . 36 121 Appendix C. MIME registrations . . . . . . . . . . . . . . . . . . 40 122 C.1 application/ocsp-request . . . . . . . . . . . . . . . . . . 40 123 C.2 application/ocsp-response . . . . . . . . . . . . . . . . . 41 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 126 1. Introduction 128 This document specifies a protocol useful in determining the current 129 status of a digital certificate without requiring CRLs. Additional 130 mechanisms addressing PKIX operational requirements are specified in 131 separate documents. 133 This specification obsoletes [RFC2560] and [RFC6277]. The primary 134 reason for the publication of this document is to address ambiguities 135 that have been found since the publication of RFC 2560. This 136 document differs from RFC 2560 in only a few areas: 138 o Section 2.2 extends the use of the "revoked" response to allow 139 this response status for certificates that has never been 140 issued. 142 o Section 2.3 extends the use of the "unauthorized" error 143 response, as specified in [RFC5019]. 145 o Section 4.2.1 and 4.2.2.3 states that a response may include 146 revocation status information for certificates that were not 147 included in the request, as permitted in [RFC5019]. 149 o Section 4.2.2.2 has been updated to clarify when a responder is 150 considered an Authorized Responder. 152 o Section 4.2.2.3 clarify that the ResponderID field corresponds 153 to the OCSP Responder signer certificate. 155 o Section 4.3 changes set of cryptographic algorithms that 156 clients must support and the set of cryptographic algorithms 157 that clients should support as specified in [RFC6277]. 159 o Section 4.4.1 specifies the ASN.1 syntax for the nonce 160 extension, which was missing in RFC 2560. 162 o Section 4.4.7 specifies a new extension that may be included in 163 a request message to specify signature algorithms the client 164 would prefer the server use to sign the response as specified 165 in [RFC6277]. 167 o Section 4.4.8 specifies a new extension that indicates that the 168 responder supports the extended use of the "revoked" response 169 for non-issued certificates defined in section 2.2. 171 o Section B.2 provides an ASN.1 module using the 2008 syntax of 172 ASN.1 which updates [RFC5912] 174 An overview of the protocol is provided in section 2. Functional 175 requirements are specified in section 4. Details of the protocol are 176 in section 5. We cover security issues with the protocol in section 177 6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1 178 syntactic elements and appendix C specifies the mime types for the 179 messages. 181 1.1 Requirements Language 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in RFC 2119 [RFC2119]. 187 2. Protocol Overview 189 In lieu of or as a supplement to checking against a periodic CRL, it 190 may be necessary to obtain timely information regarding the 191 revocation status of certificates (cf. [RFC5280], Section 3.3). 192 Examples include high-value funds transfer or large stock trades. 194 The Online Certificate Status Protocol (OCSP) enables applications to 195 determine the (revocation) state of identified certificates. OCSP may 196 be used to satisfy some of the operational requirements of providing 197 more timely revocation information than is possible with CRLs and may 198 also be used to obtain additional status information. An OCSP client 199 issues a status request to an OCSP responder and suspends acceptance 200 of the certificates in question until the responder provides a 201 response. 203 This protocol specifies the data that needs to be exchanged between 204 an application checking the status of one or more certificates and 205 the server providing the corresponding status. 207 2.1 Request 209 An OCSP request contains the following data: 211 -- protocol version 212 -- service request 213 -- target certificate identifier 214 -- optional extensions which MAY be processed by the OCSP Responder 216 Upon receipt of a request, an OCSP Responder determines if; 218 1. the message is well formed, 220 2. the responder is configured to provide the requested service, and; 222 3. the request contains the information needed by the responder. 224 If any one of these conditions are not met, the OCSP responder 225 produces an error message; otherwise, it returns a definitive 226 response. 228 2.2 Response 230 OCSP responses can be of various types. An OCSP response consists of 231 a response type and the bytes of the actual response. There is one 232 basic type of OCSP response that MUST be supported by all OCSP 233 servers and clients. The rest of this section pertains only to this 234 basic response type. 236 All definitive response messages SHALL be digitally signed. The key 237 used to sign the response MUST belong to one of the following: 239 - the CA who issued the certificate in question 240 - a Trusted Responder whose public key is trusted by the requester 241 - a CA Designated Responder (Authorized Responder, defined in 242 section 4.2.2.2) who holds a specially marked certificate issued 243 directly by the CA, indicating that the responder may issue OCSP 244 responses for that CA 246 A definitive response message is composed of: 248 - version of the response syntax 249 - identifier of the responder 250 - time when the response was generated 251 - responses for each of the certificates in a request 252 - optional extensions 253 - signature algorithm OID 254 - signature computed across hash of the response 256 The response for each of the certificates in a request consists of 258 - target certificate identifier 259 - certificate status value 260 - response validity interval 261 - optional extensions 263 This specification defines the following definitive response 264 indicators for use in the certificate status value: 266 - good 267 - revoked 268 - unknown 270 The "good" state indicates a positive response to the status inquiry. 271 At a minimum, this positive response indicates that no certificate 272 with the requested certificate serial number, that currently is 273 within its validity interval, is revoked. This state does not 274 necessarily mean that the certificate was ever issued or that the 275 time at which the response was produced is within the certificate's 276 validity interval. Response extensions may be used to convey 277 additional information on assertions made by the responder regarding 278 the status of the certificate such as positive statement about 279 issuance, validity, etc. 281 The "revoked" state indicates that the certificate has been revoked, 282 either temporarily (the revocation reason is certificateHold) or 283 permanently. This state MAY also be returned if the associated CA has 284 no record of ever having issued a certificate with the certificate 285 serial number in the request, using any current or previous issuing 286 key (referred to as a "non-issued" certificate in this document). 288 The "unknown" state indicates that the responder doesn't know about 289 the certificate being requested, usually because the request 290 indicates an unrecognized issuer that is not served by this 291 responder. 293 NOTE: The "revoked" status indicates that a certificate with the 294 requested serial number should be rejected, while the "unknown" 295 status indicates that the status could not be determined by 296 this responder, thereby allowing the client to decide whether 297 it wants to try another source of status information (such as a 298 CRL). This makes the "revoked" response suitable for non-issued 299 certificates (as defined above) where the intention of the 300 responder is to cause the client to reject the certificate 301 rather than trying another source of status information. The 302 "revoked" status is still optional for non-issued certificates 303 in order to maintain backwards compatibility with deployments 304 of RFC 2560. For example, the responder may not have any 305 knowledge about whether a requested serial number has been 306 assigned to any issued certificate, or the responder may 307 provide pre produced responses in accordance with RFC 5019 and, 308 for that reason, is not capable of providing a signed response 309 for all non-issued certificate serial numbers. 311 When a responder responds "revoked" to a status request for a non- 312 issued certificate, the responder MUST include the extended revoked 313 definition response extension (section 4.4.8) in the response, 314 indicating that the OCSP responder supports the extended definition 315 of revoked state to also cover non-issued certificates. In addition, 316 the SingleResponse related to this non-issued certificate; 318 - MUST specify the revocation reason certificateHold (6), 320 - MUST specify the revocationTime January 1, 1970, and; 322 - MUST NOT include a CRL References extension (section 4.4.2) or any 323 CRL Entry Extensions (section 4.4.5). 325 2.3 Exception Cases 327 In case of errors, the OCSP Responder may return an error message. 328 These messages are not signed. Errors can be of the following types: 330 - malformedRequest 331 - internalError 332 - tryLater 333 - sigRequired 334 - unauthorized 336 A server produces the "malformedRequest" response if the request 337 received does not conform to the OCSP syntax. 339 The response "internalError" indicates that the OCSP responder 340 reached an inconsistent internal state. The query should be retried, 341 potentially with another responder. 343 In the event that the OCSP responder is operational, but unable to 344 return a status for the requested certificate, the "tryLater" 345 response can be used to indicate that the service exists, but is 346 temporarily unable to respond. 348 The response "sigRequired" is returned in cases where the server 349 requires the client sign the request in order to construct a 350 response. 352 The response "unauthorized" is returned in cases where the client is 353 not authorized to make this query to this server or the server is not 354 capable of responding authoritatively (cf. [RFC5019], Section 2.2.3). 356 2.4 Semantics of thisUpdate, nextUpdate and producedAt 358 Responses defined in this document can contain four times - 359 thisUpdate, nextUpdate, producedAt, and revocationTime. The semantics 360 of these fields are: 362 thisUpdate The most recent time at which the status being 363 indicated, is known by the responder to have been 364 correct. 365 nextUpdate The time at or before which newer information 366 will be available about the status of the 367 certificate. 368 producedAt The time at which the OCSP responder signed this 369 response. 370 revocationTime The time at which the certificate was revoked or 371 placed on hold. 373 2.5 Response Pre-production 375 OCSP responders MAY pre-produce signed responses specifying the 376 status of certificates at a specified time. The time at which the 377 status was known to be correct SHALL be reflected in the thisUpdate 378 field of the response. The time at or before which newer information 379 will be available is reflected in the nextUpdate field, while the 380 time at which the response was produced will appear in the producedAt 381 field of the response. 383 2.6 OCSP Signature Authority Delegation 385 The key that signs a certificate's status information need not be the 386 same key that signed the certificate. A certificate's issuer 387 explicitly delegates OCSP signing authority by issuing a certificate 388 containing a unique value for extendedKeyUsage in the OCSP signer's 389 certificate. This certificate MUST be issued directly to the 390 responder by the cognizant CA. See further section 4.2.2.2. 392 2.7 CA Key Compromise 394 If an OCSP responder knows that a particular CA's private key has 395 been compromised, it MAY return the revoked state for all 396 certificates issued by that CA. 398 3. Functional Requirements 400 3.1 Certificate Content 402 In order to convey to OCSP clients a well-known point of information 403 access, CAs SHALL provide the capability to include the 404 AuthorityInfoAccess extension (defined in [RFC5280], section 4.2.2.1) 405 in certificates that can be checked using OCSP. Alternatively, the 406 accessLocation for the OCSP provider may be configured locally at the 407 OCSP client. 409 CAs that support an OCSP service, either hosted locally or provided 410 by an Authorized Responder, MUST provide for the inclusion of a value 411 for a uniformResourceIndicator (URI) [RFC3986] accessLocation and the 412 OID value id-ad-ocsp for the accessMethod in the AccessDescription 413 SEQUENCE. 415 The value of the accessLocation field in the subject certificate 416 defines the transport (e.g. HTTP) used to access the OCSP responder 417 and may contain other transport dependent information (e.g. a URL). 419 3.2 Signed Response Acceptance Requirements 421 Prior to accepting a signed response for a particular certificate as 422 valid, OCSP clients SHALL confirm that: 424 1. The certificate identified in a received response corresponds to 425 that which was identified in the corresponding request; 427 2. The signature on the response is valid; 429 3. The identity of the signer matches the intended recipient of the 430 request. 432 4. The signer is currently authorized to provide a response for the 433 certificate in question. 435 5. The time at which the status being indicated is known to be 436 correct (thisUpdate) is sufficiently recent. 438 6. When available, the time at or before which newer information 439 will be available about the status of the certificate 440 (nextUpdate) is greater than the current time. 442 4. Detailed Protocol 444 The ASN.1 syntax imports terms defined in [RFC5280]. For signature 445 calculation, the data to be signed is encoded using the ASN.1 446 distinguished encoding rules (DER) [X.690]. 448 ASN.1 EXPLICIT tagging is used as a default unless specified 449 otherwise. 451 The terms imported from elsewhere are: Extensions, 452 CertificateSerialNumber, SubjectPublicKeyInfo, Name, 453 AlgorithmIdentifier, CRLReason 455 4.1 Requests 457 This section specifies the ASN.1 specification for a confirmation 458 request. The actual formatting of the message could vary depending on 459 the transport mechanism used (HTTP, SMTP, LDAP, etc.). 461 4.1.1 Request Syntax 463 The ASN.1 structure corresponding to the OCSPRequest is: 465 OCSPRequest ::= SEQUENCE { 466 tbsRequest TBSRequest, 467 optionalSignature [0] EXPLICIT Signature OPTIONAL } 469 TBSRequest ::= SEQUENCE { 470 version [0] EXPLICIT Version DEFAULT v1, 471 requestorName [1] EXPLICIT GeneralName OPTIONAL, 472 requestList SEQUENCE OF Request, 473 requestExtensions [2] EXPLICIT Extensions OPTIONAL } 475 Signature ::= SEQUENCE { 476 signatureAlgorithm AlgorithmIdentifier, 477 signature BIT STRING, 478 certs [0] EXPLICIT SEQUENCE OF Certificate 479 OPTIONAL} 481 Version ::= INTEGER { v1(0) } 483 Request ::= SEQUENCE { 484 reqCert CertID, 485 singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } 487 CertID ::= SEQUENCE { 488 hashAlgorithm AlgorithmIdentifier, 489 issuerNameHash OCTET STRING, -- Hash of Issuer's DN 490 issuerKeyHash OCTET STRING, -- Hash of Issuers public key 491 serialNumber CertificateSerialNumber } 493 The fields in OCSPRequest have the the following meanings: 495 o tbsRequest is the optionally signed OCSP request. 497 o optionalSignature contains the algorithm identifier and any 498 associated algoirthm parameters in signatureAlgorithm, the 499 signature value in signature, and optionally certificates the 500 server needs to verify the signed response (normally up to but 501 not including the client's root certificate). 503 The contents of TBSRequest include the following fields: 505 o version indicates the version of the protocol, which for this 506 document is v1(0). 507 o requestorName is OPTIONAL and indicates the name of the OCSP 508 requestor. 510 o requestList contains one or more single certificate status 511 requests. 513 o requestExtensions is OPTIONAL and includes extensions applicable 514 to the all requests found in reqCert. See Section 4.4. 516 The contents of Request include the following fields: 518 o reqCert contains the identifier of a target certificate. 520 o singleRequestExtensions is OPTIONAL and includes extensions 521 applicable to this single certificate status request. See 522 Section 4.4. 524 The contents of CertID include the following fields: 526 o hashAlgorithm is the hash algorithm used to generate the 527 issuerNameHash and issuerKeyHash values. 529 o issuerNameHash is the hash of the Issuer's distinguished name. 530 The hash shall be calculated over the DER encoding of the 531 issuer's name field in the certificate being checked. 533 o issuerKeyHash is the hash of the Issuer's public key. The hash 534 shall be calculated over the value (excluding tag and length) of 535 the subject public key field in the issuer's certificate. 537 o serialNumber is the serial number of the certificate for which 538 status is being requested. 540 4.1.2 Notes on the Request Syntax 542 The primary reason to use the hash of the CA's public key in addition 543 to the hash of the CA's name, to identify the issuer, is that it is 544 possible that two CAs may choose to use the same Name (uniqueness in 545 the Name is a recommendation that cannot be enforced). Two CAs will 546 never, however, have the same public key unless the CAs either 547 explicitly decided to share their private key, or the key of one of 548 the CAs was compromised. 550 Support for any specific extension is OPTIONAL. The critical flag 551 SHOULD NOT be set for any of them. Section 4.4 suggests several 552 useful extensions. Additional extensions MAY be defined in 553 additional RFCs. Unrecognized extensions MUST be ignored (unless they 554 have the critical flag set and are not understood). 556 The requestor MAY choose to sign the OCSP request. In that case, the 557 signature is computed over the tbsRequest structure. If the request 558 is signed, the requestor SHALL specify its name in the requestorName 559 field. Also, for signed requests, the requestor MAY include 560 certificates that help the OCSP responder verify the requestor's 561 signature in the certs field of Signature. 563 4.2 Response Syntax 565 This section specifies the ASN.1 specification for a confirmation 566 response. The actual formatting of the message could vary depending 567 on the transport mechanism used (HTTP, SMTP, LDAP, etc.). 569 4.2.1 ASN.1 Specification of the OCSP Response 571 An OCSP response at a minimum consists of a responseStatus field 572 indicating the processing status of the prior request. If the value 573 of responseStatus is one of the error conditions, responseBytes are 574 not set. 576 OCSPResponse ::= SEQUENCE { 577 responseStatus OCSPResponseStatus, 578 responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } 580 OCSPResponseStatus ::= ENUMERATED { 581 successful (0), --Response has valid confirmations 582 malformedRequest (1), --Illegal confirmation request 583 internalError (2), --Internal error in issuer 584 tryLater (3), --Try again later 585 --(4) is not used 586 sigRequired (5), --Must sign the request 587 unauthorized (6) --Request unauthorized 588 } 590 The value for responseBytes consists of an OBJECT IDENTIFIER and a 591 response syntax identified by that OID encoded as an OCTET STRING. 593 ResponseBytes ::= SEQUENCE { 594 responseType OBJECT IDENTIFIER, 595 response OCTET STRING } 597 For a basic OCSP responder, responseType will be id-pkix-ocsp-basic. 599 id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } 600 id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } 601 OCSP responders SHALL be capable of producing responses of the 602 id-pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL 603 be capable of receiving and processing responses of the id-pkix-ocsp- 604 basic response type. 606 The value for response SHALL be the DER encoding of 607 BasicOCSPResponse. 609 BasicOCSPResponse ::= SEQUENCE { 610 tbsResponseData ResponseData, 611 signatureAlgorithm AlgorithmIdentifier, 612 signature BIT STRING, 613 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 615 The value for signature SHALL be computed on the hash of the DER 616 encoding ResponseData. The responder MAY include certificates in the 617 certs field of BasicOCSPResponse that help the OCSP client verify the 618 responder's signature. If no certificates are included then certs 619 SHOULD be absent. 621 ResponseData ::= SEQUENCE { 622 version [0] EXPLICIT Version DEFAULT v1, 623 responderID ResponderID, 624 producedAt GeneralizedTime, 625 responses SEQUENCE OF SingleResponse, 626 responseExtensions [1] EXPLICIT Extensions OPTIONAL } 628 ResponderID ::= CHOICE { 629 byName [1] Name, 630 byKey [2] KeyHash } 632 KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key 633 (excluding the tag and length fields) 635 SingleResponse ::= SEQUENCE { 636 certID CertID, 637 certStatus CertStatus, 638 thisUpdate GeneralizedTime, 639 nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, 640 singleExtensions [1] EXPLICIT Extensions OPTIONAL } 642 CertStatus ::= CHOICE { 643 good [0] IMPLICIT NULL, 644 revoked [1] IMPLICIT RevokedInfo, 645 unknown [2] IMPLICIT UnknownInfo } 647 RevokedInfo ::= SEQUENCE { 648 revocationTime GeneralizedTime, 649 revocationReason [0] EXPLICIT CRLReason OPTIONAL } 651 UnknownInfo ::= NULL 653 4.2.2 Notes on OCSP Responses 655 4.2.2.1 Time 657 Responses can contain four times - thisUpdate, nextUpdate, 658 producedAt, and revocationTime. The semantics of these fields are 659 defined in section 2.4. The format for GeneralizedTime is as 660 specified in Section 4.1.2.5.2 of [RFC5280]. 662 The thisUpdate and nextUpdate fields define a recommended validity 663 interval. This interval corresponds to the {thisUpdate, nextUpdate} 664 interval in CRLs. Responses whose nextUpdate value is earlier than 665 the local system time value SHOULD be considered unreliable. 666 Responses whose thisUpdate time is later than the local system time 667 SHOULD be considered unreliable. 669 If nextUpdate is not set, the responder is indicating that newer 670 revocation information is available all the time. 672 4.2.2.2 Authorized Responders 674 The key that signs a certificate's status information need not be the 675 same key that signed the certificate. It is necessary however to 676 ensure that the entity signing this information is authorized to do 677 so. Therefore, a certificate's issuer MUST do one of the following: 679 - sign the OCSP responses itself, or 680 - explicitly designate this authority to another entity. 682 OCSP signing delegation SHALL be designated by the inclusion of id- 683 kp-OCSPSigning in an extendedKeyUsage certificate extension included 684 in the OCSP response signer's certificate. This certificate MUST be 685 issued directly by the CA that is identified in the request. 687 The CA SHOULD use the same issuing key to issue a delegation 688 certificate as was used to sign the certificate being checked for 689 revocation. Systems relying on OCSP responses MUST recognize a 690 delegation certificate as being issued by the CA that issued the 691 certificate in question only if the delegation certificate and the 692 certificate being checked for revocation was signed by the same key. 694 Note: For backwards compatibility with RFC 2560 [RFC2560], it is not 695 prohibited to issue a certificate for an authorized responder 696 using a different issuing key than the key used to issued the 697 certificate being checked for revocation. However, such 698 practice is strongly discouraged since clients are not required 699 to recognize a responder with such certificate as an authorized 700 responder. 702 id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9} 704 Systems or applications that rely on OCSP responses MUST be capable 705 of detecting and enforcing use of the id-kp-OCSPSigning value as 706 described above. They MAY provide a means of locally configuring one 707 or more OCSP signing authorities, and specifying the set of CAs for 708 which each signing authority is trusted. They MUST reject the 709 response if the certificate required to validate the signature on the 710 response fails to meet at least one of the following criteria: 712 1. Matches a local configuration of OCSP signing authority for the 713 certificate in question; or 715 2. Is the certificate of the CA that issued the certificate in 716 question; or 718 3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage 719 extension and is issued by the CA that issued the certificate in 720 question as stated above. 722 Additional acceptance or rejection criteria may apply to either the 723 response itself or to the certificate used to validate the signature 724 on the response. 726 4.2.2.2.1 Revocation Checking of an Authorized Responder 728 Since an Authorized OCSP responder provides status information for 729 one or more CAs, OCSP clients need to know how to check that an 730 authorized responder's certificate has not been revoked. CAs may 731 choose to deal with this problem in one of three ways: 733 - A CA may specify that an OCSP client can trust a responder for the 734 lifetime of the responder's certificate. The CA does so by including 735 the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical 736 extension. The value of the extension SHALL be NULL. CAs issuing such 737 a certificate should realize that a compromise of the responder's key 738 is as serious as the compromise of a CA key used to sign CRLs, at 739 least for the validity period of this certificate. CA's may choose to 740 issue this type of certificate with a very short lifetime and renew 741 it frequently. 743 id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } 744 - A CA may specify how the responder's certificate be checked for 745 revocation. This can be done using CRL Distribution Points if the 746 check should be done using CRLs or CRL Distribution Points, or 747 Authority Information Access if the check should be done in some 748 other way. Details for specifying either of these two mechanisms are 749 available in [RFC5280]. 751 - A CA may choose not to specify any method of revocation checking 752 for the responder's certificate, in which case, it would be up to the 753 OCSP client's local security policy to decide whether that 754 certificate should be checked for revocation or not. 756 4.2.2.3 Basic Response 758 The basic response type contains: 760 o the version of the response syntax, which MUST be v1 (value is 761 0) for this version of the basic response syntax; 763 o either the name of the responder or a hash of the responder's 764 public key as the ResponderID; 766 o the time at which the response was generated; 768 o responses for each of the certificates in a request; 770 o optional extensions; 772 o a signature computed across a hash of the response; and 774 o the signature algorithm OID. 776 The purpose of the ResponderID information is to allow clients to 777 find the certificate used to sign a signed OCSP response. Therefore, 778 the information MUST correspond to the certificate that was used to 779 sign the response. 781 The responder MAY include certificates in the certs field of 782 BasicOCSPResponse that help the OCSP client verify the responder's 783 signature. 785 The response for each of the certificates in a request consists of: 787 o an identifier of the certificate for which revocation status 788 information is being provided (i.e., the target certificate); 790 o the revocation status of the certificate (good, revoked, or 791 unknown); if revoked it indicates the time at which the 792 certificate was revoked and optionally the reason why it was 793 revoked. 795 o the validity interval of the response; and 797 o optional extensions. 799 The response MUST include a SingleResponse for each certificate in 800 the request. The response SHOULD NOT include any additional 801 SingleResponse elements, but, for example, OCSP responders that pre- 802 generate status responses might include additional SingleResponse 803 elements if necessary to improve response pre-generation performance 804 or cache efficiency (According to [RFC5019], section 2.2.1). 806 4.3 Mandatory and Optional Cryptographic Algorithms 808 Clients that request OCSP services SHALL be capable of processing 809 responses signed using RSA with SHA-256 (identified by 810 sha256WithRSAEncryption OID specified in [RFC4055]). Clients SHOULD 811 also be capable of processing responses signed using RSA with SHA-1 812 (identified by sha1WithRSAEncryption OID specified in [RFC3279]) and 813 DSA with SHA-1 (identified by the id-dsa-with-sha1 OID specified in 814 [RFC3279]). Clients MAY support other algorithms. 816 4.4 Extensions 818 This section defines some standard extensions, based on the extension 819 model employed in X.509 version 3 certificates see [RFC5280]. Support 820 for all extensions is optional for both clients and responders. For 821 each extension, the definition indicates its syntax, processing 822 performed by the OCSP Responder, and any extensions which are 823 included in the corresponding response. 825 4.4.1 Nonce 827 The nonce cryptographically binds a request and a response to prevent 828 replay attacks. The nonce is included as one of the requestExtensions 829 in requests, while in responses it would be included as one of the 830 responseExtensions. In both the request and the response, the nonce 831 will be identified by the object identifier id-pkix-ocsp-nonce, while 832 the extnValue is the value of the nonce. 834 id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } 835 id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } 837 Nonce ::= OCTET STRING 839 4.4.2 CRL References 841 It may be desirable for the OCSP responder to indicate the CRL on 842 which a revoked or onHold certificate is found. This can be useful 843 where OCSP is used between repositories, and also as an auditing 844 mechanism. The CRL may be specified by a URL (the URL at which the 845 CRL is available), a number (CRL number) or a time (the time at which 846 the relevant CRL was created). These extensions will be specified as 847 singleExtensions. The identifier for this extension will be 848 id-pkix-ocsp-crl, while the value will be CrlID. 850 id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } 852 CrlID ::= SEQUENCE { 853 crlUrl [0] EXPLICIT IA5String OPTIONAL, 854 crlNum [1] EXPLICIT INTEGER OPTIONAL, 855 crlTime [2] EXPLICIT GeneralizedTime OPTIONAL } 857 For the choice crlUrl, the IA5String will specify the URL at which 858 the CRL is available. For crlNum, the INTEGER will specify the value 859 of the CRL number extension of the relevant CRL. For crlTime, the 860 GeneralizedTime will indicate the time at which the relevant CRL was 861 issued. 863 4.4.3 Acceptable Response Types 865 An OCSP client MAY wish to specify the kinds of response types it 866 understands. To do so, it SHOULD use an extension with the OID id- 867 pkix-ocsp-response, and the value AcceptableResponses. This 868 extension is included as one of the requestExtensions in requests. 869 The OIDs included in AcceptableResponses are the OIDs of the various 870 response types this client can accept (e.g., id-pkix-ocsp-basic). 872 id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 } 874 AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER 876 As noted in section 4.2.1, OCSP responders SHALL be capable of 877 responding with responses of the id-pkix-ocsp-basic response type. 878 Correspondingly, OCSP clients SHALL be capable of receiving and 879 processing responses of the id-pkix-ocsp-basic response type. 881 4.4.4 Archive Cutoff 883 An OCSP responder MAY choose to retain revocation information beyond 884 a certificate's expiration. The date obtained by subtracting this 885 retention interval value from the producedAt time in a response is 886 defined as the certificate's "archive cutoff" date. 888 OCSP-enabled applications would use an OCSP archive cutoff date to 889 contribute to a proof that a digital signature was (or was not) 890 reliable on the date it was produced even if the certificate needed 891 to validate the signature has long since expired. 893 OCSP servers that provide support for such historical reference 894 SHOULD include an archive cutoff date extension in responses. If 895 included, this value SHALL be provided as an OCSP singleExtensions 896 extension identified by id-pkix-ocsp-archive-cutoff and of syntax 897 GeneralizedTime. 899 id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= {id-pkix-ocsp 6} 901 ArchiveCutoff ::= GeneralizedTime 903 To illustrate, if a server is operated with a 7-year retention 904 interval policy and status was produced at time t1 then the value for 905 ArchiveCutoff in the response would be (t1 - 7 years). 907 4.4.5 CRL Entry Extensions 909 All the extensions specified as CRL Entry Extensions - in Section 5.3 910 of [RFC5280] - are also supported as singleExtensions. 912 4.4.6 Service Locator 914 An OCSP server may be operated in a mode whereby the server receives 915 a request and routes it to the OCSP server which is known to be 916 authoritative for the identified certificate. The serviceLocator 917 request extension is defined for this purpose. This extension is 918 included as one of the singleRequestExtensions in requests. 920 id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= {id-pkix-ocsp 7} 922 ServiceLocator ::= SEQUENCE { 923 issuer Name, 924 locator AuthorityInfoAccessSyntax OPTIONAL } 926 Values for these fields are obtained from the corresponding fields in 927 the subject certificate. 929 4.4.7 Preferred Signature Algorithms 931 Since algorithms other than the mandatory to implement algorithms are 932 allowed, and since a client currently has no mechanism to indicate 933 it's algorithm preferences, there is always a risk that a server 934 choosing a non-mandatory algorithm, will generate a response that the 935 client may not support. 937 While an OCSP responder may apply rules for algorithm selection, 938 e.g., using the signature algorithm employed by the CA for signing 939 CRLs and certificates, such rules may fail in common situations: 941 o The algorithm used to sign the CRLs and certificates may not be 942 consistent with key pair being used by the OCSP responder to sign 943 responses. 945 o A request for an unknown certificate provides no basis for a 946 responder to select from among multiple algorithm options. 948 The last criterion cannot be resolved through the information 949 available from in-band signaling using the RFC 2560 [RFC2560] 950 protocol, without modifying the protocol. 952 In addition, an OCSP responder may wish to employ different signature 953 algorithms than the one used by the CA to sign certificates and CRLs 954 for several reasons: 956 o The responder may employ an algorithm for certificate status 957 response that is less computationally demanding than for signing 958 the certificate itself. 960 o An implementation may wish to guard against the possibility of a 961 compromise resulting from a signature algorithm compromise by 962 employing two separate signature algorithms. 964 This section describes: 966 o An extension that allows a client to indicate the set of preferred 967 signature algorithms. 969 o Rules for signature algorithm selection that maximizes the 970 probability of successful operation in the case that no supported 971 preferred algorithm(s) are specified. 973 4.4.7.1 Extension Syntax 975 A client MAY declare a preferred set of algorithms in a request by 976 including a preferred signature algorithms extension in 977 requestExtensions of the OCSPRequest. 979 id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 } 981 PreferredSignatureAlgorithms ::= SEQUENCE OF 982 PreferredSignatureAlgorithm 984 PreferredSignatureAlgorithm ::= SEQUENCE { 985 sigIdentifier AlgorithmIdentifier, 986 pubKeyAlgIdentifier SMIMECapability OPTIONAL 987 } 989 The syntax of AlgorithmIdentifier is defined in section 4.1.1.2 of 990 RFC 5280 [RFC5280] The syntax of SMIMECapability is defined in RFC 991 5751 [RFC5751] 993 sigIdentifier specifies the signature algorithm the client prefers, 994 e.g. algorithm=ecdsa-with-sha256. Parameters are absent for most 995 common signature algorithms. 997 pubKeyAlgIdentifier specifies the subject public key algorithm 998 identifier the client prefers in the server's certificate used to 999 validate the OCSP response. e.g. algorithm=id-ecPublicKey and 1000 parameters= secp256r1. 1002 pubKeyAlgIdentifier is OPTIONAL and provides means to specify 1003 parameters necessary to distinguish among different usages of a 1004 particular algorithm, e.g. it may be used by the client to specify 1005 what curve it supports for a given elliptic curve algorithm. 1007 The client MUST support each of the specified preferred signature 1008 algorithms and the client MUST specify the algorithms in the order of 1009 preference, from the most preferred to the least preferred. 1011 Section 4.4.7.2 of this document describes how a server selects an 1012 algorithm for signing OCSP responses to the requesting client. 1014 4.4.7.2 Responder Signature Algorithm Selection 1016 RFC 2560 [RFC2560] did not specify a mechanism for deciding the 1017 signature algorithm to be used in an OCSP response. This does not 1018 provide a sufficient degree of certainty as to the algorithm selected 1019 to facilitate interoperability. 1021 4.4.7.2.1 Dynamic Response 1023 A responder MAY maximize the potential for ensuring interoperability 1024 by selecting a supported signature algorithm using the following 1025 order of precedence, as long as the selected algorithm meets all 1026 security requirements of the OCSP responder, where the first 1027 selection mechanism has the highest precedence: 1029 1. Select an algorithm specified as a preferred signature algorithm 1030 in the client request 1032 2. Select the signature algorithm used to sign a certificate 1033 revocation list (CRL) issued by the certificate issuer providing 1034 status information for the certificate specified by CertID 1036 3. Select the signature algorithm used to sign the OCSPRequest 1038 4. Select a signature algorithm that has been advertised as being 1039 the default signature algorithm for the signing service using an 1040 out of band mechanism 1042 5. Select a mandatory or recommended signature algorithm specified 1043 for the version of the OCSP protocol in use 1045 A responder SHOULD always apply the lowest numbered selection 1046 mechanism that results in the selection of a known and supported 1047 algorithm that meets the responder's criteria for cryptographic 1048 algorithm strength. 1050 4.4.7.2.2 Static Response 1052 For purposes of efficiency, an OCSP responder is permitted to 1053 generate static responses in advance of a request. The case may not 1054 permit the responder to make use of the client request data during 1055 the response generation, however the responder SHOULD still use the 1056 client request data during the selection of the pre-generated 1057 response to be returned. Responders MAY use the historical client 1058 requests as part of the input to the decisions of what different 1059 algorithms should be used to sign the pre-generated responses. 1061 4.4.8 Extended Revoked Definition 1063 This extension indicates that the responder supports the extended 1064 definition of the "revoked" status to also include non-issued 1065 certificates according to section 2.2. One of its main purposes is 1066 to allow audits to determine the responder's type of operation. 1067 Clients do not have to parse this extension in order to determine the 1068 status of certificates in responses. 1070 This extension MUST be included in the OCSP response when that 1071 response contains a "revoked" status for a non-issued certificate. 1072 This extension MAY be present in other responses to signal that the 1073 responder implements the extended revoked definition. When included, 1074 this extension MUST be placed in responseExtensions, and it MUST NOT 1075 appear in singleExtensions. 1077 This extension is identified by the object identifier id-pkix-ocsp- 1078 extended-revoke. 1080 id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= {id-pkix-ocsp 9} 1082 The value of the extension SHALL be NULL. This extension MUST NOT be 1083 marked critical. 1085 5. Security Considerations 1087 For this service to be effective, certificate-using systems must 1088 connect to the certificate status service provider. In the event such 1089 a connection cannot be obtained, certificate-using systems could 1090 implement CRL processing logic as a fall-back position. 1092 A denial of service vulnerability is evident with respect to a flood 1093 of queries. The production of a cryptographic signature significantly 1094 affects response generation cycle time, thereby exacerbating the 1095 situation. Unsigned error responses open up the protocol to another 1096 denial of service attack, where the attacker sends false error 1097 responses. 1099 The use of precomputed responses allows replay attacks in which an 1100 old (good) response is replayed prior to its expiration date but 1101 after the certificate has been revoked. Deployments of OCSP should 1102 carefully evaluate the benefit of precomputed responses against the 1103 probability of a replay attack and the costs associated with its 1104 successful execution. 1106 Requests do not contain the responder they are directed to. This 1107 allows an attacker to replay a request to any number of OCSP 1108 responders. 1110 The reliance of HTTP caching in some deployment scenarios may result 1111 in unexpected results if intermediate servers are incorrectly 1112 configured or are known to possess cache management faults. 1113 Implementors are advised to take the reliability of HTTP cache 1114 mechanisms into account when deploying OCSP over HTTP. 1116 Responding with a "revoked" state to certificate that has never been 1117 issued may enable someone to obtain a revocation response for a 1118 certificate that is not yet issued, but soon will be issued, if the 1119 certificate serial number of the certificate that will be issued can 1120 be predicted or guessed by the requester. Such prediction is easy for 1121 a CA that issues using sequential certificate serial number 1122 assignment. This risk is handled in the spec by requiring compliant 1123 implementations to use the certificateHold reason code, which avoids 1124 permanently revoking the serial number. One way to completely avoid 1125 this issue, for CAs that supports "revoked" responses to status 1126 requests for non-issued certificates, is to assign random certificate 1127 serial number values with high entropy. 1129 5.1 Preferred Signature Algorithms 1131 The mechanism used to choose the response signing algorithm MUST be 1132 considered to be sufficiently secure against cryptanalytic attack for 1133 the intended application. 1135 In most applications it is sufficient for the signing algorithm to be 1136 at least as secure as the signing algorithm used to sign the original 1137 certificate whose status is being queried. This criterion may not 1138 hold in long term archival applications however in which the status 1139 of a certificate is being queried for a date in the distant past, 1140 long after the signing algorithm has ceased being considered 1141 trustworthy. 1143 5.1.1 Use of insecure algorithms 1145 It is not always possible for a responder to generate a response that 1146 the client is expected to understand and that meets contemporary 1147 standards for cryptographic security. In such cases an OCSP 1148 responder operator MUST balance the risk of employing a compromised 1149 security solution and the cost of mandating an upgrade, including the 1150 risk that the alternative chosen by end users will offer even less 1151 security or no security. 1153 In archival applications it is quite possible that an OCSP responder 1154 might be asked to report the validity of a certificate on a date in 1155 the distant past. Such a certificate might employ a signing method 1156 that is no longer considered acceptably secure. In such 1157 circumstances the responder MUST NOT generate a signature using a 1158 signing mechanism that is not considered acceptably secure. 1160 A client MUST accept any signing algorithm in a response that it 1161 specified as a preferred signing algorithm in the request. It 1162 follows therefore that a client MUST NOT specify as a preferred 1163 signing algorithm any algorithm that is either not supported or not 1164 considered acceptably secure. 1166 5.1.2 Man in the Middle Downgrade Attack 1168 The mechanism to support client indication of preferred signature 1169 algorithms is not protected against a man in the middle downgrade 1170 attack. This constraint is not considered to be a significant 1171 security concern since the OCSP responder MUST NOT sign OCSP 1172 Responses using weak algorithms even if requested by the client. In 1173 addition, the client can reject OCSP responses that do not meet its 1174 own criteria for acceptable cryptographic security no matter what 1175 mechanism is used to determine the signing algorithm of the response. 1177 5.1.3. Denial of Service Attack 1178 Algorithm agility mechanisms defined in this document introduces a 1179 slightly increased attack surface for Denial-of-Service attacks where 1180 the client request is altered to require algorithms that are not 1181 supported by the server. Denial-of-Service considerations from RFC 1182 4732 [RFC4732] are relevant for this document. 1184 6 IANA Considerations 1186 This document includes media type registrations (in Appendix C) for 1187 ocsp-request and ocsp-response that were registered when RFC 2560 was 1188 published. This document will obsolete that RFC so IANA is requested 1189 to update the references in the application media type registry for 1190 ocsp-request and ocsp-response to point to this document. 1192 7. References 1194 7.1. Normative References 1196 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1197 Requirement Levels", BCP 14, RFC 2119, March 1997. 1199 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1200 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1201 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1203 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 1204 Identifiers for the Internet X.509 Public Key 1205 Infrastructure Certificate and Certificate Revocation List 1206 (CRL) Profile", RFC 3279, April 2002. 1208 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1209 Resource Identifier (URI): Generic Syntax", STD 66, 1210 RFC 3986, January 2005. 1212 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 1213 Algorithms and Identifiers for RSA Cryptography for use in 1214 the Internet X.509 Public Key Infrastructure Certificate 1215 and Certificate Revocation List (CRL) Profile", RFC 4055, 1216 June 2005. 1218 [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online 1219 Certificate Status Protocol (OCSP) Profile for High-Volume 1220 Environments", RFC 5019, September 2007. 1222 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1223 Housley, R., and W. Polk, "Internet X.509 Public Key 1224 Infrastructure Certificate and Certificate Revocation List 1225 (CRL) Profile", RFC 5280, May 2008. 1227 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1228 Mail Extensions (S/MIME) Version 3.2 Message 1229 Specification", RFC 5751, January 2010. 1231 [RFC6277] Santesson, S. and P. Hallam-Baker, "Online Certificate 1232 Status Protocol Algorithm Agility", RFC 6277, June 2011. 1234 [X.690] ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995, 1235 Information Technology - ASN.1 encoding rules: 1236 Specification of Basic Encoding Rules (BER), Canonical 1237 Encoding Rules (CER) and Distinguished Encoding Rules 1238 (DER). 1240 7.2. Informative References 1242 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1243 Adams, "X.509 Internet Public Key Infrastructure Online 1244 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1246 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1247 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1248 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1250 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 1251 Denial-of-Service Considerations", RFC 4732, December 1252 2006. 1254 [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online 1255 Certificate Status Protocol (OCSP) Profile for High-Volume 1256 Environments", RFC 5019, September 2007. 1258 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 1259 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 1260 June 2010. 1262 8. Acknowledgement 1264 Development of this draft has been made possible thanks to extensive 1265 inputs from members of the PKIX group. 1267 Jim Schaad provided valuable support by compiling and checking the 1268 ASN.1 modules of this specification. 1270 Appendix A. 1272 A.1 OCSP over HTTP 1274 This section describes the formatting that will be done to the 1275 request and response to support HTTP [RFC2616]. 1277 A.1.1 Request 1279 HTTP based OCSP requests can use either the GET or the POST method to 1280 submit their requests. To enable HTTP caching, small requests (that 1281 after encoding are less than 255 bytes), MAY be submitted using GET. 1282 If HTTP caching is not important, or the request is greater than 255 1283 bytes, the request SHOULD be submitted using POST. Where privacy is 1284 a requirement, OCSP transactions exchanged using HTTP MAY be 1285 protected using either TLS/SSL or some other lower layer protocol. 1287 An OCSP request using the GET method is constructed as follows: 1289 GET {url}/{url-encoding of base-64 encoding of the DER encoding of 1290 the OCSPRequest} 1292 where {url} may be derived from the value of AuthorityInfoAccess or 1293 other local configuration of the OCSP client. 1295 An OCSP request using the POST method is constructed as follows: The 1296 Content-Type header has the value "application/ocsp-request" while 1297 the body of the message is the binary value of the DER encoding of 1298 the OCSPRequest. 1300 A.1.2 Response 1302 An HTTP-based OCSP response is composed of the appropriate HTTP 1303 headers, followed by the binary value of the DER encoding of the 1304 OCSPResponse. The Content-Type header has the value 1305 "application/ocsp-response". The Content-Length header SHOULD specify 1306 the length of the response. Other HTTP headers MAY be present and MAY 1307 be ignored if not understood by the requestor. 1309 Appendix B. ASN.1 Modules 1311 This appendix includes the ASN.1 modules for OCSP. Appendix B.1 1312 includes an ASN.1 module that conforms to the 1998 version of ASN.1 1313 for all syntax elements of OCSP including the preferred signature 1314 algorithms extension that was defined in [RFC6277]. This module 1315 replaces the modules in Appendix B of [RFC2560] and Appendix A.2 of 1316 [RFC6277]. Appendix B.2 includes an ASN.1 module, corresponding to 1317 the module present in B.1, that conforms to the 2008 version of 1318 ASN.1. This module replaces the modules in Section 12 or [RFC5912] 1319 and Appendix A.1 of [RFC6277]. Although a 2008 ASN.1 module is 1320 provided, the module in Appendix B.1 remains the normative module as 1321 per the policy of the PKIX working group. 1323 B.1. OCSP in ASN.1 - 1998 Syntax 1325 OCSP-2013-88 1326 {iso(1) identified-organization(3) dod(6) internet(1) 1327 security(5) mechanisms(5) pkix(7) id-mod(0) 1328 id-mod-ocsp-2013-88(81)} 1330 DEFINITIONS EXPLICIT TAGS ::= 1332 BEGIN 1334 IMPORTS 1336 -- PKIX Certificate Extensions 1337 AuthorityInfoAccessSyntax, CRLReason, GeneralName 1338 FROM PKIX1Implicit88 { iso(1) identified-organization(3) 1339 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1340 id-mod(0) id-pkix1-implicit(19) } 1342 Name, CertificateSerialNumber, Extensions, 1343 id-kp, id-ad-ocsp, Certificate, AlgorithmIdentifier 1344 FROM PKIX1Explicit88 { iso(1) identified-organization(3) 1345 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1346 id-mod(0) id-pkix1-explicit(18) }; 1348 OCSPRequest ::= SEQUENCE { 1349 tbsRequest TBSRequest, 1350 optionalSignature [0] EXPLICIT Signature OPTIONAL } 1352 TBSRequest ::= SEQUENCE { 1353 version [0] EXPLICIT Version DEFAULT v1, 1354 requestorName [1] EXPLICIT GeneralName OPTIONAL, 1355 requestList SEQUENCE OF Request, 1356 requestExtensions [2] EXPLICIT Extensions OPTIONAL } 1358 Signature ::= SEQUENCE { 1359 signatureAlgorithm AlgorithmIdentifier, 1360 signature BIT STRING, 1361 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 1363 Version ::= INTEGER { v1(0) } 1365 Request ::= SEQUENCE { 1366 reqCert CertID, 1367 singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } 1369 CertID ::= SEQUENCE { 1370 hashAlgorithm AlgorithmIdentifier, 1371 issuerNameHash OCTET STRING, -- Hash of Issuer's DN 1372 issuerKeyHash OCTET STRING, -- Hash of Issuers public key 1373 serialNumber CertificateSerialNumber } 1375 OCSPResponse ::= SEQUENCE { 1376 responseStatus OCSPResponseStatus, 1377 responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } 1379 OCSPResponseStatus ::= ENUMERATED { 1380 successful (0), -- Response has valid confirmations 1381 malformedRequest (1), -- Illegal confirmation request 1382 internalError (2), -- Internal error in issuer 1383 tryLater (3), -- Try again later 1384 -- (4) is not used 1385 sigRequired (5), -- Must sign the request 1386 unauthorized (6) -- Request unauthorized 1387 } 1389 ResponseBytes ::= SEQUENCE { 1390 responseType OBJECT IDENTIFIER, 1391 response OCTET STRING } 1393 BasicOCSPResponse ::= SEQUENCE { 1394 tbsResponseData ResponseData, 1395 signatureAlgorithm AlgorithmIdentifier, 1396 signature BIT STRING, 1397 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 1399 ResponseData ::= SEQUENCE { 1400 version [0] EXPLICIT Version DEFAULT v1, 1401 responderID ResponderID, 1402 producedAt GeneralizedTime, 1403 responses SEQUENCE OF SingleResponse, 1404 responseExtensions [1] EXPLICIT Extensions OPTIONAL } 1406 ResponderID ::= CHOICE { 1407 byName [1] Name, 1408 byKey [2] KeyHash } 1410 KeyHash ::= OCTET STRING --SHA-1 hash of responder's public key 1411 -- (i.e., the SHA-1 hash of the value of the 1412 -- BIT STRING subjectPublicKey [excluding 1413 -- the tag, length, and number of unused 1414 -- bits] in the responder's certificate) 1416 SingleResponse ::= SEQUENCE { 1417 certID CertID, 1418 certStatus CertStatus, 1419 thisUpdate GeneralizedTime, 1420 nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, 1421 singleExtensions [1] EXPLICIT Extensions OPTIONAL } 1423 CertStatus ::= CHOICE { 1424 good [0] IMPLICIT NULL, 1425 revoked [1] IMPLICIT RevokedInfo, 1426 unknown [2] IMPLICIT UnknownInfo } 1428 RevokedInfo ::= SEQUENCE { 1429 revocationTime GeneralizedTime, 1430 revocationReason [0] EXPLICIT CRLReason OPTIONAL } 1432 UnknownInfo ::= NULL 1434 ArchiveCutoff ::= GeneralizedTime 1436 AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER 1438 ServiceLocator ::= SEQUENCE { 1439 issuer Name, 1440 locator AuthorityInfoAccessSyntax } 1442 CrlID ::= SEQUENCE { 1443 crlUrl [0] EXPLICIT IA5String OPTIONAL, 1444 crlNum [1] EXPLICIT INTEGER OPTIONAL, 1445 crlTime [2] EXPLICIT GeneralizedTime OPTIONAL } 1447 PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm 1449 PreferredSignatureAlgorithm ::= SEQUENCE { 1450 sigIdentifier AlgorithmIdentifier, 1451 certIdentifier AlgorithmIdentifier OPTIONAL } 1453 -- Object Identifiers 1455 id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } 1456 id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } 1457 id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } 1458 id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } 1459 id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } 1460 id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 } 1461 id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } 1462 id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 } 1463 id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 } 1464 id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 } 1465 id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 } 1467 END 1468 B.2. OCSP in ASN.1 - 2008 Syntax 1470 OCSP-2013-08 1471 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1472 mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-2013-08(82)} 1474 DEFINITIONS EXPLICIT TAGS ::= 1475 BEGIN 1476 IMPORTS 1478 Extensions{}, EXTENSION, ATTRIBUTE 1479 FROM PKIX-CommonTypes-2009 -- From [RFC5912] 1480 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1481 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} 1483 AlgorithmIdentifier{}, DIGEST-ALGORITHM, SIGNATURE-ALGORITHM, PUBLIC-KEY 1484 FROM AlgorithmInformation-2009 -- From [RFC5912] 1485 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1486 mechanisms(5) pkix(7) id-mod(0) 1487 id-mod-algorithmInformation-02(58)} 1489 AuthorityInfoAccessSyntax, GeneralName, CrlEntryExtensions 1490 FROM PKIX1Implicit-2009 -- From [RFC5912] 1491 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1492 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} 1494 Name, CertificateSerialNumber, id-kp, id-ad-ocsp, Certificate 1495 FROM PKIX1Explicit-2009 -- From [RFC5912] 1497 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1498 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)} 1500 sa-dsaWithSHA1, sa-rsaWithMD2, sa-rsaWithMD5, sa-rsaWithSHA1 1501 FROM PKIXAlgs-2009 1502 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1503 mechanisms(5) pkix(7) id-mod(0) 1504 id-mod-pkix1-algorithms2008-02(56)}; 1506 OCSPRequest ::= SEQUENCE { 1507 tbsRequest TBSRequest, 1508 optionalSignature [0] EXPLICIT Signature OPTIONAL } 1510 TBSRequest ::= SEQUENCE { 1511 version [0] EXPLICIT Version DEFAULT v1, 1512 requestorName [1] EXPLICIT GeneralName OPTIONAL, 1513 requestList SEQUENCE OF Request, 1514 requestExtensions [2] EXPLICIT Extensions {{re-ocsp-nonce | 1515 re-ocsp-response, ..., 1516 re-ocsp-preferred-signature-algorithms}} OPTIONAL } 1518 Signature ::= SEQUENCE { 1519 signatureAlgorithm AlgorithmIdentifier 1520 { SIGNATURE-ALGORITHM, {...}}, 1521 signature BIT STRING, 1522 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 1524 Version ::= INTEGER { v1(0) } 1526 Request ::= SEQUENCE { 1527 reqCert CertID, 1528 singleRequestExtensions [0] EXPLICIT Extensions 1529 { {re-ocsp-service-locator, 1530 ...}} OPTIONAL } 1532 CertID ::= SEQUENCE { 1533 hashAlgorithm AlgorithmIdentifier 1534 {DIGEST-ALGORITHM, {...}}, 1535 issuerNameHash OCTET STRING, -- Hash of Issuer's DN 1536 issuerKeyHash OCTET STRING, -- Hash of Issuer's public key 1537 serialNumber CertificateSerialNumber } 1539 OCSPResponse ::= SEQUENCE { 1540 responseStatus OCSPResponseStatus, 1541 responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } 1543 OCSPResponseStatus ::= ENUMERATED { 1544 successful (0), --Response has valid confirmations 1545 malformedRequest (1), --Illegal confirmation request 1546 internalError (2), --Internal error in issuer 1547 tryLater (3), --Try again later 1548 -- (4) is not used 1549 sigRequired (5), --Must sign the request 1550 unauthorized (6) --Request unauthorized 1551 } 1553 RESPONSE ::= TYPE-IDENTIFIER 1555 ResponseSet RESPONSE ::= {basicResponse, ...} 1556 ResponseBytes ::= SEQUENCE { 1557 responseType RESPONSE. 1558 &id ({ResponseSet}), 1559 response OCTET STRING (CONTAINING RESPONSE. 1560 &Type({ResponseSet}{@responseType}))} 1562 basicResponse RESPONSE ::= 1563 { BasicOCSPResponse IDENTIFIED BY id-pkix-ocsp-basic } 1565 BasicOCSPResponse ::= SEQUENCE { 1566 tbsResponseData ResponseData, 1567 signatureAlgorithm AlgorithmIdentifier{SIGNATURE-ALGORITHM, 1568 {sa-dsaWithSHA1 | sa-rsaWithSHA1 | 1569 sa-rsaWithMD5 | sa-rsaWithMD2, ...}}, 1570 signature BIT STRING, 1571 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 1573 ResponseData ::= SEQUENCE { 1574 version [0] EXPLICIT Version DEFAULT v1, 1575 responderID ResponderID, 1576 producedAt GeneralizedTime, 1577 responses SEQUENCE OF SingleResponse, 1578 responseExtensions [1] EXPLICIT Extensions 1579 {{re-ocsp-nonce, ..., 1580 re-ocsp-extended-revoke}} OPTIONAL } 1582 ResponderID ::= CHOICE { 1583 byName [1] Name, 1584 byKey [2] KeyHash } 1586 KeyHash ::= OCTET STRING --SHA-1 hash of responder's public key 1587 -- (excluding the tag and length fields) 1589 SingleResponse ::= SEQUENCE { 1590 certID CertID, 1591 certStatus CertStatus, 1592 thisUpdate GeneralizedTime, 1593 nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, 1594 singleExtensions [1] EXPLICIT Extensions{{re-ocsp-crl | 1595 re-ocsp-archive-cutoff | 1596 CrlEntryExtensions, ...} 1597 } OPTIONAL } 1599 CertStatus ::= CHOICE { 1600 good [0] IMPLICIT NULL, 1601 revoked [1] IMPLICIT RevokedInfo, 1602 unknown [2] IMPLICIT UnknownInfo } 1604 RevokedInfo ::= SEQUENCE { 1605 revocationTime GeneralizedTime, 1606 revocationReason [0] EXPLICIT CRLReason OPTIONAL } 1608 UnknownInfo ::= NULL 1610 CRLReason ::= INTEGER 1612 ArchiveCutoff ::= GeneralizedTime 1614 AcceptableResponses ::= SEQUENCE OF RESPONSE.&id({ResponseSet}) 1616 ServiceLocator ::= SEQUENCE { 1617 issuer Name, 1618 locator AuthorityInfoAccessSyntax } 1620 CrlID ::= SEQUENCE { 1621 crlUrl [0] EXPLICIT IA5String OPTIONAL, 1622 crlNum [1] EXPLICIT INTEGER OPTIONAL, 1623 crlTime [2] EXPLICIT GeneralizedTime OPTIONAL } 1625 PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm 1627 PreferredSignatureAlgorithm ::= SEQUENCE { 1628 sigIdentifier AlgorithmIdentifier{SIGNATURE-ALGORITHM, {...}}, 1629 certIdentifier AlgorithmIdentifier{PUBLIC-KEY, {...}} OPTIONAL 1630 } 1632 -- Certificate Extensions 1634 ext-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED 1635 BY id-pkix-ocsp-nocheck } 1637 -- Request Extensions 1639 re-ocsp-nonce EXTENSION ::= { SYNTAX OCTET STRING IDENTIFIED 1640 BY id-pkix-ocsp-nonce } 1642 re-ocsp-response EXTENSION ::= { SYNTAX AcceptableResponses IDENTIFIED 1643 BY id-pkix-ocsp-response } 1645 re-ocsp-service-locator EXTENSION ::= { SYNTAX ServiceLocator 1646 IDENTIFIED BY 1647 id-pkix-ocsp-service-locator } 1649 re-ocsp-preferred-signature-algorithms EXTENSION ::= { 1650 SYNTAX PreferredSignatureAlgorithms 1651 IDENTIFIED BY id-pkix-ocsp-pref-sig-algs } 1653 -- Response Extensions 1655 re-ocsp-crl EXTENSION ::= { SYNTAX CrlID IDENTIFIED BY 1656 id-pkix-ocsp-crl } 1658 re-ocsp-archive-cutoff EXTENSION ::= { SYNTAX ArchiveCutoff 1659 IDENTIFIED BY 1660 id-pkix-ocsp-archive-cutoff } 1662 re-ocsp-extended-revoke EXTENSION ::= { SYNTAX NULL IDENTIFIED BY 1663 id-pkix-ocsp-extended-revoke } 1665 -- Object Identifiers 1667 id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } 1668 id-pkix-ocsp OBJECT IDENTIFIER ::= id-ad-ocsp 1669 id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } 1670 id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } 1671 id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } 1672 id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 } 1673 id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } 1674 id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 } 1675 id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 } 1676 id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 } 1677 id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 } 1679 END 1681 Appendix C. MIME registrations 1683 C.1 application/ocsp-request 1685 To: ietf-types@iana.org Subject: Registration of MIME media type 1686 application/ocsp-request 1688 MIME media type name: application 1690 MIME subtype name: ocsp-request 1692 Required parameters: None 1694 Optional parameters: None 1696 Encoding considerations: binary 1697 Security considerations: Carries a request for information. This 1698 request may optionally be cryptographically signed. 1700 Interoperability considerations: None 1702 Published specification: IETF PKIX Working Group Draft on Online 1703 Certificate Status Protocol - OCSP 1705 Applications which use this media type: OCSP clients 1707 Additional information: 1709 Magic number(s): None 1710 File extension(s): .ORQ 1711 Macintosh File Type Code(s): none 1713 Person & email address to contact for further information: 1714 Stefan Santesson 1716 Intended usage: COMMON 1718 Author/Change controller: IETF 1720 C.2 application/ocsp-response 1722 To: ietf-types@iana.org 1723 Subject: Registration of MIME media type application/ocsp-response 1725 MIME media type name: application 1727 MIME subtype name: ocsp-response 1729 Required parameters: None 1731 Optional parameters: None 1732 Encoding considerations: binary 1734 Security considerations: Carries a cryptographically signed response 1736 Interoperability considerations: None 1738 Published specification: IETF PKIX Working Group Draft on Online 1739 Certificate Status Protocol - OCSP 1741 Applications which use this media type: OCSP servers 1743 Additional information: 1745 Magic number(s): None 1746 File extension(s): .ORS 1747 Macintosh File Type Code(s): none 1749 Person & email address to contact for further information: 1750 Stefan Santesson 1752 Intended usage: COMMON 1754 Author/Change controller: IETF 1756 Authors' Addresses 1758 Stefan Santesson 1759 3xA Security AB 1760 Scheelev. 17 1761 223 70 Lund 1762 Sweden 1763 EMail: sts@aaa-sec.com 1765 Michael Myers 1766 TraceRoute Security 1767 EMail: mmyers@fastq.com 1769 Rich Ankney 1770 EMail: no e-mail 1772 Ambarish Malpani 1773 CA Technologies 1774 455 West Maude Ave, Suite 210 1775 Sunnyvale, CA 94085 1776 EMail: ambarish@gmail.com 1778 Slava Galperin 1779 A9.com inc 1780 130 Lytton Ave Suite 300 1781 Palo Alto, California 94301 1782 United States 1783 EMail: slava.galperin@gmail.com 1785 Carlisle Adams 1786 University of Ottawa 1787 800 King Edward Avenue 1788 Ottawa ON K1N 6N5 1789 Canada 1790 EMail: cadams@eecs.uottawa.ca