idnits 2.17.1 draft-cooper-pkix-rfc2560bis-00.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC2560, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 28, 2010) is 5049 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 1325 -- Looks like a reference, but probably isn't: '1' on line 1320 -- Looks like a reference, but probably isn't: '2' on line 1321 -- Obsolete informational reference (is this intentional?): RFC 2560 (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT D. Cooper 3 Intended Status: Proposed Standard NIST 4 Obsoletes: 2560 (once approved) June 28, 2010 5 Expires: December 30, 2010 7 X.509 Internet Public Key Infrastructure 8 Online Certificate Status Protocol - OCSP 9 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Copyright and License Notice 34 Copyright (c) 2010 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 This document may contain material from IETF Documents or IETF 48 Contributions published or made publicly available before November 49 10, 2008. The person(s) controlling the copyright in some of this 50 material may not have granted the IETF Trust the right to allow 51 modifications of such material outside the IETF Standards Process. 52 Without obtaining an adequate license from the person(s) controlling 53 the copyright in such materials, this document may not be modified 54 outside the IETF Standards Process, and derivative works of it may 55 not be created outside the IETF Standards Process, except to format 56 it for publication as an RFC or to translate it into languages other 57 than English. 59 Abstract 61 This document specifies a protocol useful in determining the current 62 status of a digital certificate without requiring CRLs. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 68 1.2. OCSP Responder Architectures . . . . . . . . . . . . . . . 5 69 1.2.1. Integrated OCSP Responders . . . . . . . . . . . . . 5 70 1.2.2. Designated OCSP Responders . . . . . . . . . . . . . 5 71 1.2.3. Locally Trusted OCSP Responders . . . . . . . . . . . 6 72 1.3. Dynamic Versus Static Responses . . . . . . . . . . . . . 6 73 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 6 74 2.1. OCSP Requests . . . . . . . . . . . . . . . . . . . . . . 7 75 2.1.1. Request Extensions . . . . . . . . . . . . . . . . . 8 76 2.1.1.1. Nonce . . . . . . . . . . . . . . . . . . . . . 8 77 2.1.1.2. Acceptable Response Types . . . . . . . . . . . 9 78 2.1.1.3. Preferred Signature Algorithms . . . . . . . . . 9 79 2.1.2. Service Locator Single Request Extension . . . . . 10 80 2.2. OCSP Responses . . . . . . . . . . . . . . . . . . . . . 11 81 2.2.1. Error Responses . . . . . . . . . . . . . . . . . . 11 82 2.3. Basic Response Type . . . . . . . . . . . . . . . . . . 12 83 2.3.1. Certificate Revocation Status . . . . . . . . . . . 14 84 2.3.2. thisUpdate, nextUpdate, and producedAt . . . . . . 14 85 2.3.3. Nonce Response Extension . . . . . . . . . . . . . 15 86 2.3.4. Single Response Extensions . . . . . . . . . . . . 16 87 2.3.4.1. CRL References . . . . . . . . . . . . . . . . 16 88 2.3.4.2. Archive Cutoff . . . . . . . . . . . . . . . . 16 89 2.3.4.3. Invalidity Date . . . . . . . . . . . . . . . 17 90 2.3.5. Response Signatures . . . . . . . . . . . . . . . . 17 91 2.3.5.1. Authorized Responders . . . . . . . . . . . . 17 92 2.3.5.2. Revocation Information for OCSP Responder's 93 Certificate . . . . . . . . . . . . . . . . . 18 95 2.3.5.3. Responder Signature Algorithm Selection . . . 19 96 2.3.5.3.1. Dynamic Response . . . . . . . . . . . . 19 97 2.3.5.3.2. Static Response . . . . . . . . . . . . . 20 98 2.3.6. Response Verification . . . . . . . . . . . . . . . 20 99 2.3.6.1. Mandatory and Optional Cryptographic 100 Algorithms . . . . . . . . . . . . . . . . . 21 101 2.3.6.2. Verifying Responder's Authorization . . . . . 21 102 3. OCSP Responder Discovery . . . . . . . . . . . . . . . . . . 22 103 4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 104 4.1. Use of Insecure Algorithms . . . . . . . . . . . . . . . 23 105 4.2. Man in the Middle Downgrade Attack . . . . . . . . . . . 24 106 4.3. Denial of Service Attack . . . . . . . . . . . . . . . . 24 107 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 108 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 109 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 110 7.1. Normative References . . . . . . . . . . . . . . . . . . 24 111 7.2. Informative References . . . . . . . . . . . . . . . . . 25 112 Appendix A. OCSP over HTTP . . . . . . . . . . . . . . . . . . . 25 113 A.1. Request . . . . . . . . . . . . . . . . . . . . . . . . 25 114 A.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 26 115 Appendix B. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 26 116 B.1. OCSP in ASN.1 . . . . . . . . . . . . . . . . . . . . . 27 117 B.2. Preferred Signature Algorithms ASN.1 . . . . . . . . . . 30 118 B.2.1. ASN.1 Module . . . . . . . . . . . . . . . . . . . 30 119 B.2.2. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . 31 120 Appendix C. Media Types . . . . . . . . . . . . . . . . . . . . 32 121 C.1. application/ocsp-request . . . . . . . . . . . . . . . . 32 122 C.2. application/ocsp-response . . . . . . . . . . . . . . . 33 123 Appendix D. Example PKIs With OCSP Responders . . . . . . . . . 34 124 D.1. Integrated OCSP Responders . . . . . . . . . . . . . . . 34 125 D.2. Designated OCSP Responders . . . . . . . . . . . . . . . 36 126 D.3. Locally Trusted OCSP Responder . . . . . . . . . . . . . 41 127 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42 129 1. Introduction 131 In lieu of or as a supplement to checking against a periodic CRL, it 132 may be necessary to obtain timely information regarding the 133 revocation status of a certificate (cf. [RFC5280], Section 3.3). 134 Examples include high-value funds transfer or large stock trades. 136 The Online Certificate Status Protocol (OCSP) enables applications to 137 determine the (revocation) state of an identified certificate. OCSP 138 may be used to satisfy some of the operational requirements of 139 providing more timely revocation information than is possible with 140 CRLs and may also be used to obtain additional status information. 141 An OCSP client issues a status request to an OCSP responder and 142 suspends acceptance of the certificate in question until the 143 responder provides a response. 145 This protocol specifies the data that needs to be exchanged between 146 an application checking the status of a certificate and the server 147 providing that status. 149 An overview of the protocol is provided in this section. Details of 150 the protocol are in Section 2. Section 3 specifies how information 151 about the access location of an OCSP responder needs to be 152 distributed. Security issues with the protocol are covered in 153 Section 4. Appendix A defines OCSP over HTTP, Appendix B accumulates 154 ASN.1 syntactic elements, Appendix C specifies the media types for 155 the messages, and Appendix D provides some examples of architectures 156 of public key infrastructures (PKI) that include OCSP responders. 158 This specification obsoletes [RFC2560]. The primary reason for the 159 publication of this document is to address ambiguities that have been 160 found since the publication of RFC 2560. This document differs from 161 RFC 2560 in only a few areas: 163 o Section 2.1.1.3 specifies a new request extension that allows 164 the client to specify preferred signature algorithms for the 165 server to use to sign the response. 167 o Section 2.2.1 extends the use of the "unauthorized" error 168 response, as specified in [RFC5019]. 170 o Section 2.3 states that a response may include revocation 171 status information for certificates that were not included in 172 the request, as permitted in [RFC5019]. 174 o Section 2.3.6.1 changes set of cryptographic algorithms that 175 clients must support and the set of cryptographic algorithms 176 that clients should support. 178 1.1. Terminology 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in RFC 2119 [RFC2119]. 184 1.2. OCSP Responder Architectures 186 In order for an OCSP client to accept a response from a responder, 187 the responder MUST be authorized to provide the response. The 188 responder may either be authorized by the certification authority 189 (CA) that issued the certificate for which status information is 190 being requested (the target certificate) or by the OCSP client 191 itself. Authorized OCSP responders fall into one of three 192 categories: integrated, designated, or locally trusted. The category 193 into which an OCSP responder falls is based on the perspective of the 194 OCSP client and depends upon the issuer of the target certificate. 196 1.2.1. Integrated OCSP Responders 198 A responder is an integrated OCSP responder if the subject 199 distinguished name (DN) in the certificate containing the public key 200 required to verify the signature on the OCSP response is the same as 201 the issuer DN in the target certificate(s). In other words, an 202 integrated OCSP responder is a responder that provides revocation 203 status information for its own certificates. An integrated OCSP 204 responder may sign certificates and OCSP responses using the same 205 private key or may use different keys to sign certificates and OCSP 206 responses. 208 1.2.2. Designated OCSP Responders 210 Most CAs do not act as OCSP responders themselves, but provide OCSP 211 services by designating a separate OCSP responder as being authorized 212 to provide revocation status information for the certificates that 213 they issue. A responder is a designated OCSP responder if subject 214 distinguished name (DN) in the certificate containing the public key 215 required to verify the signature on the OCSP response is not the same 216 as the issuer DN in the target certificate(s), but the certificate 217 was issued by the issuer of the target certificate(s) and includes a 218 unique value in the extended key usage extension that indicates that 219 the issuing CA has authorized the OCSP responder to provide 220 revocation status information for the certificates that it has 221 issued. Designated OCSP responders are frequently operated by the 222 same organization as the CA(s) for which they provide revocation 223 status information. 225 1.2.3. Locally Trusted OCSP Responders 227 Systems or applications that rely on OCSP responses MAY provide a 228 means of locally configuring one or more OCSP signing authorities, 229 and specifying the set of CAs for which each signing authority is 230 trusted. Just as a relying party may choose which CAs to use as 231 trust anchors for certification path validation, an OCSP client may 232 choose to accept responses from an OCSP responder even if no CA has 233 designated that responder as authorized to sign OCSP responses. 234 Systems and applications may also be designed to only accept OCSP 235 responses from integrated and designated OCSP responders. 237 Locally trusted OCSP responders are usually set up by an organization 238 (or on behalf of an organization) for use by OCSP clients within that 239 organization. The OCSP responder collects revocation information 240 (e.g., certificate revocation lists (CRL)) from all CAs within a PKI 241 and uses this information to generate OCSP responses for its clients. 243 1.3. Dynamic Versus Static Responses 245 OCSP responders may generate fresh OCSP responses for each OCSP 246 request they receive, but they are also permitted to generate static 247 responses in advance of a request. Pre-generating OCSP responses can 248 improve efficiency, which may be necessary in high-volume 249 environments [RFC5019]. Pre-generated responses will generally be 250 the same as freshly generated responses, but can be identified since 251 non-error response messages specify the time at which the response 252 was generated. In addition, an OCSP responder that can only provide 253 pre-generated responses may send an error response when it does not 254 have a pre-generated response that corresponds to the request. 256 2. Protocol Overview 258 This section presents the OCSP protocol. Section 2.1 presents the 259 format for OCSP requests, Section 2.2 presents the generic syntax for 260 OCSP responses, and Section 2.3 presents the syntax for the basic 261 response type. The ASN.1 syntax in this section imports terms 262 defined in [RFC5280]. The terms imported from RFC 5280 are: 263 AlgorithmIdentifier, Certificate, CertificateSerialNumber, CRLReason, 264 Extensions, GeneralName, id-ad-ocsp, id-kp, Name, and 265 SubjectPublicKeyInfo. 267 OCSP requests and responses MAY include extensions. Extensions in 268 OCSP requests and responses are based on the extension model employed 269 in X.509 version 3 certificates [RFC5280]. This document specifies 270 some standard extensions that MAY appear in requests and/or 271 responses. Additional extensions MAY be defined in additional RFCs. 272 Support for any specific extension is OPTIONAL for both clients and 273 responders. The critical flag SHOULD NOT be set for any of the 274 extensions defined in this document. Unrecognized extensions MUST be 275 ignored (unless they have the critical flag set). 277 For signature calculation, the data to be signed is encoded using the 278 ASN.1 distinguished encoding rules (DER) [X.690]. The actual 279 formatting of the request and response messages could vary depending 280 on the transport mechanism used (HTTP, SMTP, LDAP, etc.). 282 ASN.1 EXPLICIT tagging is used as a default unless specified 283 otherwise. 285 2.1. OCSP Requests 287 The ASN.1 for an OCSP request message is as follows: 289 OCSPRequest ::= SEQUENCE { 290 tbsRequest TBSRequest, 291 optionalSignature [0] EXPLICIT Signature OPTIONAL } 293 TBSRequest ::= SEQUENCE { 294 version [0] EXPLICIT Version DEFAULT v1, 295 requestorName [1] EXPLICIT GeneralName OPTIONAL, 296 requestList SEQUENCE OF Request, 297 requestExtensions [2] EXPLICIT Extensions OPTIONAL } 299 Signature ::= SEQUENCE { 300 signatureAlgorithm AlgorithmIdentifier, 301 signature BIT STRING, 302 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 304 Version ::= INTEGER { v1(0) } 306 Request ::= SEQUENCE { 307 reqCert CertID, 308 singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } 310 CertID ::= SEQUENCE { 311 hashAlgorithm AlgorithmIdentifier, 312 issuerNameHash OCTET STRING, -- Hash of Issuer's DN 313 issuerKeyHash OCTET STRING, -- Hash of Issuer's public key 314 serialNumber CertificateSerialNumber } 316 An OCSP request contains the following data: 318 o the protocol version, which MUST be v1 (value is 0) for this 319 version of the protocol; 321 o a list of the certificates for which status information is 322 being requested; and 324 o optional extensions, which MAY be processed by the OCSP 325 responder. 327 Each certificate for which status information is being requested is 328 identified by: 330 o issuerNameHash - the hash of the issuer's distinguished name. 331 The hash SHALL be calculated over the DER encoding of the 332 issuer's name field in the certificate being checked. 334 o issuerKeyHash - the hash of the issuer's public key. The hash 335 SHALL be calculated over the value (excluding tag and length) 336 of the subject public key field in the issuer's certificate. 338 o serialNumber - the serial number of the certificate for which 339 status is being requested. 341 The hash algorithm used for both issuerNameHash and issuerKeyHash is 342 identified in hashAlgorithm. 344 The requestor MAY choose to sign the OCSP request. In that case, the 345 signature is computed over the tbsRequest structure. If the request 346 is signed, the requestor SHALL specify its name in the requestorName 347 field. Also, for signed requests, the requestor MAY include 348 certificates in the certs field of Signature that help the OCSP 349 responder verify the requestor's signature. 351 2.1.1. Request Extensions 353 This section defines some standard extensions that may appear in the 354 requestExtensions field of an OCSP request message. For each 355 extension, the definition indicates its syntax, processing performed 356 by the OCSP responder, and any extensions that are included in the 357 corresponding response. 359 2.1.1.1. Nonce 361 The nonce cryptographically binds a request and a response to prevent 362 replay attacks. The nonce is included as one of the 363 requestExtensions in requests, while in responses it would be 364 included as one of the responseExtensions. In both the request and 365 the response, the nonce will be identified by the object identifier 366 id-pkix-ocsp-nonce, while the extnValue is the value of the nonce. 368 id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } 369 id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } 371 [Editor's note: What is the syntax for the nonce extension? Section 372 4.1 of RFC 5280 states that extnValue "contains the DER encoding of 373 an ASN.1 value corresponding to the extension type identified by 374 extnID". Does that apply for the nonce extension? Is so, what is the 375 ASN.1? OCTET STRING? INTEGER? ANY?] 377 2.1.1.2. Acceptable Response Types 379 An OCSP client MAY wish to specify the kinds of response types it 380 understands. To do so, it SHOULD use an extension with the OID 381 id-pkix-ocsp-response, and the value AcceptableResponses. The OIDs 382 included in AcceptableResponses are the OIDs of the various response 383 types this client can accept (e.g., id-pkix-ocsp-basic). 385 id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 } 387 AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER 389 As noted in Section 2.3, OCSP clients MUST be capable of receiving 390 and processing responses of the id-pkix-ocsp-basic response type. 391 Thus, when the id-pkix-ocsp-response extension is included in an OCSP 392 request, the id-pkix-ocsp-basic OID MUST be included as one of the 393 AcceptableResponses. 395 2.1.1.3. Preferred Signature Algorithms 397 A client MAY declare a preferred set of algorithms in a request by 398 including a preferred signature algorithms extension. 400 id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 } 402 PreferredSignatureAlgorithms ::= SEQUENCE OF 403 PreferredSignatureAlgorithm 405 PreferredSignatureAlgorithm ::= SEQUENCE { 406 sigIdentifier AlgorithmIdentifier, 407 certIdentifier AlgorithmIdentifier OPTIONAL } 409 The syntax of AlgorithmIdentifier is defined in section 4.1.1.2 of 410 [RFC5280]. 412 sigIdentifier specifies the signature algorithm the client prefers, 413 e.g., algorithm=ecdsa-with-sha256. Parameters are absent for most 414 common signature algorithms. [Editor's note: This should be 415 clarified with respect to RSA (both PKCS #1 v1.5 and PSS) where 416 parameters are required.] 417 certIdentifier specifies the subject public key algorithm identifier 418 the client prefers in the server's certificate used to validate the 419 OCSP response, e.g., algorithm=id-ecPublicKey and 420 parameters=secp256r1. 422 certIdentifier is OPTIONAL and provides a means to specify parameters 423 necessary to distinguish among different usages of a particular 424 algorithm, e.g., it may be used by the client to specify what curve 425 it supports for a given elliptic curve algorithm. 427 The client MUST support each of the specified preferred signature 428 algorithms and the client MUST specify the algorithms in the order of 429 preference. 431 The server SHOULD use one of the preferred signature algorithms for 432 signing OCSP responses to the requesting client. 434 2.1.2. Service Locator Single Request Extension 436 This document specifies one standard extension that may appear in the 437 singleRequestExtensions field of an OCSP request message, the service 438 locator extension. 440 An OCSP server may be operated in a mode whereby the server receives 441 a request and routes it to the OCSP server that is known to be 442 authoritative for the identified certificate. The serviceLocator 443 request extension is defined for this purpose. 445 id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 } 447 ServiceLocator ::= SEQUENCE { 448 issuer Name, 449 locator AuthorityInfoAccessSyntax OPTIONAL } 451 Values for these fields are obtained from the corresponding fields in 452 the subject certificate. 454 [Editor's note: I don't understand how this extension works. Is the 455 client telling the OCSP server where to route the request? Can a 456 single request include multiple certificates, each with a different 457 value for the service locator field? If so, which responder signs 458 the response? Is the response always signed by the server that 459 directly received the request from the client, even though that 460 server is just routing the request to the authoritative server(s)? 461 Can anyone provide text for this section that provides more clarity 462 on the semantics of this extension?] 464 2.2. OCSP Responses 466 The ASN.1 for a response message is as follows: 468 OCSPResponse ::= SEQUENCE { 469 responseStatus OCSPResponseStatus, 470 responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } 472 OCSPResponseStatus ::= ENUMERATED { 473 successful (0), -- Response has valid confirmations 474 malformedRequest (1), -- Illegal confirmation request 475 internalError (2), -- Internal error in issuer 476 tryLater (3), -- Try again later 477 -- (4) is not used 478 sigRequired (5), -- Must sign the request 479 unauthorized (6) -- Request unauthorized 480 } 482 ResponseBytes ::= SEQUENCE { 483 responseType OBJECT IDENTIFIER, 484 response OCTET STRING } 486 Upon receipt of a request, an OCSP responder determines if: 488 1. the message is well formed; 490 2. the responder is configured to provide the requested service; 491 and 493 3. the request contains the information needed by the responder. 495 If any one of the prior conditions are not met, the OCSP responder 496 produces an error message consisting of a responseStatus of 497 "malformedRequest", "internalError", "tryLater", "sigRequired", or 498 "unauthorized", and with responseBytes absent. If all of the prior 499 conditions are met, the OCSP responder produces a response with a 500 responseStatus of "successful" and with the responseBytes field 501 present. The value for responseBytes consists of an OBJECT 502 IDENTIFIER and a response syntax identified by that OID, encoded as 503 an OCTET STRING. 505 2.2.1. Error Responses 507 An error response message consists of an OCSPResponse in which only 508 the responseStatus field is present. These messages are not signed. 509 For error responses, responseStatus MUST be one of the following: 511 o malformedRequest: the request received does not conform to the 512 OCSP syntax. 514 o internalError: the OCSP responder reached an inconsistent 515 internal state. The query should be retried, potentially with 516 another responder. 518 o tryLater: the OCSP responder is operational, but is temporarily 519 unable to return a status for one or more of the requested 520 certificates. 522 o sigRequired: the request is unsigned, but the server requires 523 the client sign the request in order to construct a response. 525 o unauthorized: the client is not authorized to make this query 526 to this server or the server is not capable of responding 527 authoritatively (cf. [RFC5019], Section 2.2.3). 529 2.3. Basic Response Type 531 While OCSP responses may be of various types, this document specifies 532 only one response type, the basic response type, which MUST be 533 supported by all OCSP servers and clients. This section describes 534 the basic response type. 536 The basic response type is identified by the id-pkix-ocsp-basic OID: 538 id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } 540 When the responseType is id-pkix-ocsp-basic the response field SHALL 541 contain the DER encoding of BasicOCSPResponse: 543 BasicOCSPResponse ::= SEQUENCE { 544 tbsResponseData ResponseData, 545 signatureAlgorithm AlgorithmIdentifier, 546 signature BIT STRING, 547 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 549 The value for signature SHALL be computed on the hash of the DER 550 encoding of ResponseData. 552 ResponseData ::= SEQUENCE { 553 version [0] EXPLICIT Version DEFAULT v1, 554 responderID ResponderID, 555 producedAt GeneralizedTime, 556 responses SEQUENCE OF SingleResponse, 557 responseExtensions [1] EXPLICIT Extensions OPTIONAL } 559 ResponderID ::= CHOICE { 560 byName [1] Name, 561 byKey [2] KeyHash } 563 KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key 564 -- (excluding the tag and length fields) 566 SingleResponse ::= SEQUENCE { 567 certID CertID, 568 certStatus CertStatus, 569 thisUpdate GeneralizedTime, 570 nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, 571 singleExtensions [1] EXPLICIT Extensions OPTIONAL } 573 CertStatus ::= CHOICE { 574 good [0] IMPLICIT NULL, 575 revoked [1] IMPLICIT RevokedInfo, 576 unknown [2] IMPLICIT UnknownInfo } 578 RevokedInfo ::= SEQUENCE { 579 revocationTime GeneralizedTime, 580 revocationReason [0] EXPLICIT CRLReason OPTIONAL } 582 UnknownInfo ::= NULL 584 The basic response type contains: 586 o the version of the response syntax, which MUST be v1 (value is 587 0) for this version of the basic response syntax; 589 o either the name of the responder or a hash of the responder's 590 public key; 592 o the time at which the response was generated; 594 o responses for each of the certificates in a request; 596 o optional extensions; 598 o a signature computed across a hash of the response; and 600 o the signature algorithm OID. 602 The responder MAY include certificates in the certs field of 603 BasicOCSPResponse that help the OCSP client verify the responder's 604 signature. 606 The response for each of the certificates in a request consists of: 608 o an identifier of the certificate for which revocation status 609 information is being provided (i.e., the target certificate); 611 o the revocation status of the certificate (good, revoked, or 612 unknown); 614 o the validity interval of the response; and 616 o optional extensions. 618 The response MUST include a SingleResponse for each certificate in 619 the request and SHOULD NOT include any additional SingleResponse 620 elements. OCSP responders that pre-generate status responses MAY 621 return responses that include additional SingleResponse elements if 622 necessary to improve response pre-generation performance or cache 623 efficiency. [Editor's note: From Section 2.2.1 of RFC 5019.] 625 2.3.1. Certificate Revocation Status 627 For each of the certificates identified, the response message MUST 628 indicate a status of "good", "revoked", or "unknown". 630 A status of "good" indicates a positive response to the status 631 inquiry. At a minimum, this positive response indicates that the 632 certificate is not revoked, but does not necessarily mean that the 633 certificate was ever issued or that the time at which the response 634 was produced is within the certificate's validity interval. Response 635 extensions may be used to convey additional information on assertions 636 made by the responder regarding the status of the certificate such as 637 a positive statement about issuance, validity, etc. 639 The "revoked" status indicates that the certificate has been revoked 640 (either permanently or temporarily (on hold)). When the "revoked" 641 status is returned the response MUST indicate the time at which 642 revocation occurred and MAY indicate the reason for the revocation. 644 If an OCSP responder knows that a particular CA's private key has 645 been compromised, it MAY return the "revoked" status for all 646 certificates issued by that CA. 648 The "unknown" status indicates that the responder doesn't know about 649 the certificate being requested. 651 2.3.2. thisUpdate, nextUpdate, and producedAt 653 Responses can contain three times in them - thisUpdate, nextUpdate, 654 and producedAt. The semantics of these fields are: 656 o thisUpdate: The time at which the status being indicated is 657 known to be correct. 659 o nextUpdate: The time at or before which newer information will 660 be available about the status of the certificate. 662 o producedAt: The time at which the OCSP responder signed this 663 response. 665 The thisUpdate and nextUpdate fields define a recommended validity 666 interval. This interval corresponds to the {thisUpdate, nextUpdate} 667 interval in CRLs. Responses whose thisUpdate time is later than the 668 local system time SHOULD be considered unreliable. Responses whose 669 nextUpdate value is earlier than the local system time value SHOULD 670 be considered unreliable. If nextUpdate is not set, the responder is 671 indicating that newer revocation information is available all the 672 time. 674 OCSP responders MAY pre-produce signed responses specifying the 675 status of certificates at a specified time. The time at which the 676 status was known to be correct SHALL be reflected in the thisUpdate 677 field of the response. The time at or before which newer information 678 will be available is reflected in the nextUpdate field, while the 679 time at which the response was produced will appear in the producedAt 680 field of the response. 682 2.3.3. Nonce Response Extension 684 This document defines one standard extension that may appear in the 685 responseExtensions field of OCSP response messages. The nonce 686 cryptographically binds a request and a response to prevent replay 687 attacks. The nonce may be included as a response extension when it 688 appears as one of the requestExtensions in the corresponding request 689 (see Section 2.1.1.1). 691 When present, the nonce MUST have the same value as the nonce in the 692 corresponding request. If the request did not include a nonce then a 693 nonce MUST NOT be included in the response. The nonce extension in 694 the response is identified using the same object identifier as is 695 used in the request, id-pkix-ocsp-nonce. 697 [Editor's note: RFC 5019 says that "Clients that do not include a 698 nonce in the request MUST ignore any nonce that may be present in the 699 response." Is it permissible for a server to include a nonce in the 700 response if there was no nonce in the request? If the request 701 included a nonce, may the server send a response that includes a 702 different nonce?] 704 2.3.4. Single Response Extensions 706 This section defines some standard extensions that may appear in the 707 singleExtensions field of OCSP response messages. Each extension in 708 this section provides additional information about a single 709 certificate in the response. 711 2.3.4.1. CRL References 713 It may be desirable for the OCSP responder to indicate the CRL on 714 which a revoked or on hold certificate is found. This can be useful 715 where OCSP is used between repositories, and also as an auditing 716 mechanism. The CRL may be specified by a URL (the URL at which the 717 CRL is available), a number (CRL number), or a time (the time at 718 which the relevant CRL was created). The identifier for this 719 extension will be id-pkix-ocsp-crl, while the value will be CrlID. 721 id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } 723 CrlID ::= SEQUENCE { 724 crlUrl [0] EXPLICIT IA5String OPTIONAL, 725 crlNum [1] EXPLICIT INTEGER OPTIONAL, 726 crlTime [2] EXPLICIT GeneralizedTime OPTIONAL } 728 For crlUrl, the IA5String will specify the URL at which the CRL is 729 available. For crlNum, the INTEGER will specify the value of the CRL 730 number extension of the relevant CRL. For crlTime, the 731 GeneralizedTime will indicate the time at which the relevant CRL was 732 issued. 734 2.3.4.2. Archive Cutoff 736 An OCSP responder MAY choose to retain revocation information beyond 737 a certificate's expiration. The date obtained by subtracting this 738 retention interval value from the producedAt time in a response is 739 defined as the certificate's "archive cutoff" date. 741 OCSP-enabled applications would use an OCSP archive cutoff date to 742 contribute to a proof that a digital signature was (or was not) 743 reliable on the date it was produced even if the certificate needed 744 to validate the signature has long since expired. 746 OCSP responders that provide support for such historical reference 747 SHOULD include an archive cutoff date extension in responses. The 748 identifier for this extension will be id-pkix-ocsp-archive-cutoff, 749 while the value will be ArchiveCutoff. 751 id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 } 752 ArchiveCutoff ::= GeneralizedTime 754 To illustrate, if a server is operated with a 7-year retention 755 interval policy and status was produced at time t1 then the value for 756 ArchiveCutoff in the response would be (t1 - 7 years). 758 Note that when an OCSP response includes status information for more 759 than one certificate, the server may choose to include the archive 760 cutoff extension for only some of the certificates and may specify 761 different ArchiveCutoff values for different certificates. 763 2.3.4.3. Invalidity Date 765 For certificates with a revocation status of "revoked", OCSP 766 responders may include the invalidity date CRL entry extension, as 767 described in Section 5.3.2 of [RFC5280], in singleExtensions to 768 provide the date on which it is known or suspected that the private 769 key was compromised or that the the certificate otherwise became 770 invalid. 772 [Editor's note: RFC 2560 states that all the extensions specified as 773 CRL Entry Extensions in Section 5.3 of RFC 2459 are also supported as 774 singleExtensions. However, RFC 2459 specifies 4 CRL entry 775 extensions: reason Code, hold instruction code, invalidity date, and 776 certificate issuer. RevokedInfo already includes a revocationReason 777 field, so including the reason code extension in singleExtensions 778 would be redundant. Certificate issuer would similarly be redundant 779 since the identity of the certificate's issuer is already known. 780 Hold instruction code extension was removed from RFC 5280 and so 781 should not be included here either. So, that leaves invalidity date 782 as the only CRL entry extension in RFC 5280 that would be appropriate 783 for inclusion in singleExtensions.] 785 2.3.5. Response Signatures 787 All responses of the basic response type MUST be digitally signed. 788 This section addresses the means by which OCSP responders determine 789 which key and signature algorithm to use to ensure that OCSP clients 790 can verify the signatures on OCSP response messages. 792 2.3.5.1. Authorized Responders 794 As described in Section 1.2, in order for an OCSP client to accept a 795 response from a responder for which it is not locally configured to 796 accept OCSP responses, the responder MUST be authorized by the issuer 797 of the target certificate(s). This section provides additional 798 information about the requirements for a CA to designate an OCSP 799 responder as authorized to provide revocation status information for 800 the certificates that it issues. 802 o Integrated OCSP responder 804 CAs that sign OCSP responses implicitly authorize themselves to 805 provide revocation status information for the certificates that 806 they issue. When a CA signs OCSP responses to provide revocation 807 status information for its own certificates, it may sign the 808 responses using the same key as was used to sign the target 809 certificate(s) or using a different key. One reason that a CA may 810 sign an OCSP response using a different key would be if the CA had 811 performed a key rollover since it issued the target 812 certificate(s). 814 Note: Some OCSP clients, when accepting responses from an 815 integrated OCSP responder, will only accept OCSP responses that 816 are signed using the same key as the target certificate(s). 818 o Designated OCSP responder 820 In order for a CA to designate an OCSP responder other than itself 821 as authorized to provide revocation status information for the 822 certificates that it issues, the CA MUST issue a certificate to 823 the OCSP responder that: 825 o contains the public key required to validate the signatures 826 on OCSP responses signed by the responder; and 828 o has an extended key usage extension that includes the 829 id-kp-OCSPSigning OID. 831 id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9} 833 The CA does not need to sign this certificate using the same key 834 as was used to sign the target certificate(s), but the certificate 835 MUST be issued to the OCSP responder directly by the CA that 836 issued the target certificate(s). 838 Note: Some OCSP clients, when accepting OCSP responses from a 839 designated OCSP responder, will only accept OCSP responses if 840 the certificate required to validate the signature on the OCSP 841 response was signed using the same key as the target 842 certificate(s). 844 2.3.5.2. Revocation Information for OCSP Responder's Certificate 846 Since an authorized OCSP responder provides revocation status 847 information for one or more CAs, OCSP clients need to know how to 848 check that an authorized responder's certificate has not been 849 revoked. CAs may choose to deal with this problem in one of three 850 ways: 852 o A CA may specify that an OCSP client can trust a responder for the 853 lifetime of the responder's certificate. The CA does so by 854 including the extension id-pkix-ocsp-nocheck. This SHOULD be a 855 non-critical extension. The value of the extension SHALL be NULL. 856 CAs issuing such a certificate should realize that a compromise of 857 the responder's key is as serious as the compromise of a CA key 858 used to sign CRLs, at least for the validity period of this 859 certificate. CA's may choose to issue this type of certificate 860 with a very short lifetime and renew it frequently. 861 [Editor's note: I changed "should be NULL" to "SHALL be NULL".] 863 id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } 865 o A CA may specify how to check the responder's certificate for 866 revocation. This can be done using CRL Distribution Points if the 867 check should be done using CRLs, or Authority Information Access 868 if the check should be done in some other way. Details for 869 specifying either of these two mechanisms are available in 870 [RFC5280]. 872 o A CA may choose not to specify any method of revocation checking 873 for the responder's certificate, in which case it would be up to 874 the OCSP client's local security policy to decide whether that 875 certificate should be checked for revocation. 877 2.3.5.3. Responder Signature Algorithm Selection 879 This section describes rules for the OCSP responder to use to select 880 the algorithm to use the sign the response. 882 2.3.5.3.1. Dynamic Response 884 A responder MAY maximize the potential for ensuring interoperability 885 by selecting a supported signature algorithm using the following 886 order of precedence, as long as the selected algorithm meets all 887 security requirements of the OCSP responder, where the first method 888 has the highest precedence: 890 1. Select an algorithm specified as a preferred signature algorithm 891 in the client request. 893 2. Select the signature algorithm used to sign a CRL issued by the 894 certificate issuer providing status information for the 895 certificate specified by CertID. 897 3. Select the signature algorithm used to sign the OCSP request. 899 4. Select a signature algorithm that has been advertised as being 900 the default signature algorithm for the signing service using an 901 out-of-band mechanism. 903 5. Select a mandatory or recommended signing algorithm specified for 904 the version of the OCSP protocol in use (see Section 2.3.6.1). 906 A responder SHOULD always apply the lowest numbered selection 907 mechanism that is known, supported, and that meets the responder's 908 criteria for cryptographic algorithm strength. 910 2.3.5.3.2. Static Response 912 For purposes of efficiency, an OCSP responder is permitted to 913 generate static responses in advance of a request. The case may not 914 permit the responder to make use of the client request data during 915 the response generation. However, the responder SHOULD still use the 916 client request data during the selection of the pre-generated 917 response to be returned. Responders MAY use the historical client 918 requests as part of the input to the decisions of what different 919 algorithms should be used to sign the pre-generated responses. 921 2.3.6. Response Verification 923 Prior to accepting a response of the basic response type as valid, 924 OCSP clients MUST confirm that: 926 1. the certificates identified in the response correspond to the 927 certificates that were identified in the corresponding 928 request; 930 2. the signature on the response is valid; 932 3. the identity of the signer matches the intended recipient of 933 the request; [Editor's note: I think this should be deleted. 934 Except in the case of a locally trusted OCSP responder, the 935 client only knows the URL of the OCSP responder, not the 936 identity of the responder. Isn't it sufficient for the client 937 to verify that the signer is authorized?] 939 4. the signer is currently authorized to sign the response (see 940 Section 2.3.6.2); 942 5. the time at which the status being indicated is known to be 943 correct (thisUpdate) is sufficiently recent; and 945 6. when available, the time at or before which newer information 946 will be available about the status of the certificate 947 (nextUpdate) is greater than the current time. 949 2.3.6.1. Mandatory and Optional Cryptographic Algorithms 951 Clients that request OCSP services SHALL be capable of processing 952 responses signed using RSA with SHA-1 (identified by 953 sha1WithRSAEncryption OID specified in [RFC3279]) and RSA with 954 SHA-256 (identified by sha256WithRSAEncryption OID specified in 955 [RFC4055]). Clients SHOULD also be capable of processing responses 956 signed using DSA keys (identified by the id-dsa-with-sha1 OID 957 specified in [RFC3279]). Clients MAY support other algorithms. 959 2.3.6.2. Verifying Responder's Authorization 961 Systems or applications that rely on OCSP responses MUST reject a 962 response if the certificate required to validate the signature on the 963 response fails to meet at least one of the following criteria: 965 1. Matches a local configuration of OCSP signing authority for 966 the certificate in question (i.e., is signed by a locally 967 trusted OCSP responder). 969 2. Is the certificate of the CA that issued the certificate in 970 question. (This criterion is satisfied if the subject DN in 971 the certificate required to validate the signature on the OCSP 972 response is the same as the issuer DN in the certificate in 973 question.) 975 3. Has an extended key usage extension that includes the id-ad- 976 ocspSigning OID and is issued by the CA that issued the 977 certificate in question. (For this criterion to be satisfied, 978 the issuer DN in the certificate required to validate the 979 signature on the OCSP response MUST be the same as the issuer 980 DN in the certificate in question.) 982 Systems or applications that rely on OCSP responses MUST be capable 983 of detecting and enforcing use of the id-ad-ocspSigning value as 984 described in Section 2.3.5.1. They MAY provide a means of locally 985 configuring one or more OCSP signing authorities, and specifying the 986 set of CAs for which each signing authority is trusted. 988 Additional acceptance or rejection criteria may apply to either the 989 response itself or to the certificate used to validate the signature 990 on the response. 992 3. OCSP Responder Discovery 994 CAs that operate as integrated OCSP responders or that designate one 995 or more OCSP responders as authorized to provide revocation status 996 information for the certificates that they issue SHALL include an 997 authorityInfoAccess extension (defined in [RFC5280], Section 4.2.2.1) 998 in certificates that can be checked using OCSP. The 999 authorityInfoAccess extension MUST include an entry with an 1000 accessMethod of id-ad-ocsp and an accessLocation that is a 1001 uniformResourceIdentifier (URI). The value of the accessLocation 1002 field in the certificate defines the transport (e.g., HTTP) used to 1003 access the OCSP responder and may contain other transport dependent 1004 information (e.g., a URL). 1006 Information about the access location of OCSP responders that are 1007 neither integrated nor designated SHOULD NOT be included in the 1008 authorityInfoAccess extension of certificates. Instead, the access 1009 location for such OCSP responders SHOULD be provided using out-of- 1010 band means and be configured locally at the OCSP client. 1012 [Editor's note: This text was based on my original interpretation of 1013 Section 3.1 in RFC 2560. However, emails from 1999 1014 (http://www.ietf.org/mail-archive/web/pkix/current/msg25976.html) 1015 imply that the text was only intended to impose a requirement on CA 1016 products, not to require CAs to include the extension under certain 1017 circumstances. Was the second paragraph in Section 3.1 of RFC 2560 1018 only intended to impose a requirement on CA products?] 1020 4. Security Considerations 1022 For this service to be effective, certificate using systems must 1023 connect to the certificate status service provider. In the event 1024 such a connection cannot be obtained, certificate-using systems could 1025 implement CRL processing logic as a fall-back position. 1027 A denial of service vulnerability is evident with respect to a flood 1028 of queries. The production of a cryptographic signature 1029 significantly affects response generation cycle time, thereby 1030 exacerbating the situation. Unsigned error responses open up the 1031 protocol to another denial of service attack, where the attacker 1032 sends false error responses. 1034 The use of pre-computed responses allows replay attacks in which an 1035 old (good) response is replayed prior to its expiration date but 1036 after the certificate has been revoked. Deployments of OCSP should 1037 carefully evaluate the benefit of pre-computed responses against the 1038 probability of a replay attack and the costs associated with its 1039 successful execution. 1041 Requests do not contain the responder to which they are directed. 1042 This allows an attacker to replay a request to any number of OCSP 1043 responders. 1045 The reliance of HTTP caching in some deployment scenarios may result 1046 in unexpected results if intermediate servers are incorrectly 1047 configured or are known to possess cache management faults. 1048 Implementers are advised to take the reliability of HTTP cache 1049 mechanisms into account when deploying OCSP over HTTP. 1051 The mechanism used to choose the response signing algorithm MUST be 1052 considered to be sufficiently secure against cryptanalytic attack for 1053 the intended application. 1055 In most applications it is sufficient for the signing algorithm to be 1056 at least as secure as the signing algorithm used to sign the original 1057 certificate whose status is being queried. However, this criteria 1058 may not hold in long-term archival applications in which the status 1059 of a certificate is being queried for a date in the distant past, 1060 long after the signing algorithm has ceased being considered 1061 trustworthy. 1063 4.1. Use of Insecure Algorithms 1065 It is not always possible for a responder to generate a response that 1066 the client is expected to understand and that meets contemporary 1067 standards for cryptographic security. In such cases an OCSP 1068 responder operator MUST balance the risk of employing a compromised 1069 security solution and the cost of mandating an upgrade, including the 1070 risk that the alternative chosen by end users will offer even less 1071 security or no security. 1073 In archival applications it is quite possible that an OCSP responder 1074 might be asked to report the validity of a certificate on a date in 1075 the distant past. Such a certificate might employ a signing method 1076 that is no longer considered acceptably secure. In such 1077 circumstances the responder MUST NOT generate a signature for a 1078 signing mechanism that is considered unacceptably insecure. 1080 A client MUST accept any signature algorithm in a response that it 1081 specified as a preferred signature algorithm in the request. It 1082 follows, therefore, that a client MUST NOT specify as a preferred 1083 signature algorithm any algorithm that is either not supported or not 1084 considered acceptably secure. 1086 4.2. Man in the Middle Downgrade Attack 1088 The mechanism to support client indication of preferred signature 1089 algorithms is not protected against a man in the middle downgrade 1090 attack. This constraint is not considered to be a significant 1091 security concern since the OCSP responder MUST NOT sign OCSP 1092 responses using weak algorithms even if requested by the client. In 1093 addition, the client can reject OCSP responses that do not meet its 1094 own criteria for acceptable cryptographic security no matter what 1095 mechanism is used to determine the signature algorithm of the 1096 response. 1098 4.3. Denial of Service Attack 1100 Algorithm agility mechanisms defined in this document introduce a 1101 slightly increased attack surface for denial of service attacks where 1102 the client request is altered to require algorithms that are not 1103 supported by the server or that do not match pre-generated responses. 1105 5. IANA Considerations 1107 Request types and extensions in OCSP requests and responses are 1108 identified using object identifiers. The objects are identified in 1109 an arc delegated by IANA to the PKIX Working Group. No further 1110 action by IANA is necessary for this document or any anticipated 1111 updates. 1113 6. Acknowledgments 1115 TBD 1117 7. References 1119 7.1. Normative References 1121 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1122 Requirement Levels", BCP 14, RFC 2119, March 1997. 1124 [RFC3279] Polk, W., Housley, R., and L. Bassham, "Algorithms and 1125 Identifiers for the Internet X.509 Public Key 1126 Infrastructure Certificate and Certificate Revocation List 1127 (CRL) Profile", RFC 3279, April 2002. 1129 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 1130 Algorithms and Identifiers for RSA Cryptography for use in 1131 the Internet X.509 Public Key Infrastructure Certificate 1132 and Certificate Revocation List (CRL) Profile", RFC 4055, 1133 June 2005. 1135 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1136 Housley, R. and W. Polk, "Internet X.509 Public Key 1137 Infrastructure Certificate and Certificate Revocation List 1138 (CRL) Profile", RFC 5280, May 2008. 1140 [X.690] ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995, 1141 Information Technology - ASN.1 encoding rules: 1142 Specification of Basic Encoding Rules (BER), Canonical 1143 Encoding Rules (CER) and Distinguished Encoding Rules 1144 (DER). 1146 7.2. Informative References 1148 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1149 Adams, "X.509 Internet Public Key Infrastructure Online 1150 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1152 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 1153 L., Leach, P., and T. Berners-Lee, "Hypertext Transfer 1154 Protocol -- HTTP/1.1", RFC 2616, June 1999. 1156 [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online 1157 Certificate Status Protocol (OCSP) Profile for High-Volume 1158 Environments", RFC 5019, September 2007. 1160 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 1161 Public Key Infrastructure Using X.509", RFC 5912, June 1162 2010. 1164 Appendix A. OCSP over HTTP 1166 This appendix describes the formatting that will be done to the 1167 request and response to support HTTP [RFC2616]. 1169 A.1. Request 1171 HTTP-based OCSP requests can use either the GET or the POST method to 1172 submit their requests. To enable HTTP caching, small requests (that 1173 after encoding are less than 255 bytes), MAY be submitted using GET. 1174 If HTTP caching is not important, or the request is greater than 255 1175 bytes, the request SHOULD be submitted using POST. Where privacy is 1176 a requirement, OCSP transactions exchanged using HTTP MAY be 1177 protected using either TLS/SSL or some other lower layer protocol. 1179 An OCSP request using the GET method is constructed as follows: 1181 GET {url}/{url-encoding of base-64 encoding of the DER encoding of 1182 the OCSPRequest} 1183 where {url} may be derived from the value of AuthorityInfoAccess or 1184 other local configuration of the OCSP client. 1186 An OCSP request using the POST method is constructed as follows: The 1187 Content-Type header has the value "application/ocsp-request" while 1188 the body of the message is the binary value of the DER encoding of 1189 the OCSPRequest. 1191 A.2. Response 1193 An HTTP-based OCSP response is composed of the appropriate HTTP 1194 headers, followed by the binary value of the DER encoding of the 1195 OCSPResponse. The Content-Type header has the value 1196 "application/ocsp-response". The Content-Length header SHOULD 1197 specify the length of the response. Other HTTP headers MAY be 1198 present and MAY be ignored if not understood by the requestor. 1200 Appendix B. ASN.1 Modules 1202 This appendix includes the ASN.1 modules for OCSP. Appendix B.1 1203 includes an ASN.1 module that conforms to the 1998 version of ASN.1 1204 for all syntax elements of OCSP other than the preferred signature 1205 algorithms extension. An alternative to this module that conforms to 1206 the 2002 version of ASN.1 my be found in Section 4 of [RFC5912]. 1207 Appendix B.2 includes two ASN.1 modules for the preferred signature 1208 algorithms extension, one that conforms to the 1998 version of ASN.1 1209 and one that conforms to the 2002 version of ASN.1. 1211 [Editor's note: The OCSP ASN.1 module in Appendix B.1 did not have 1212 an OID, so I copied the OID from draft-ietf-pkix-ocspagility-08.txt. 1213 Why does the OCSP module import Certificate, AlgorithmIdentifier, and 1214 CRLReason from AuthenticationFramework when Certificate and 1215 AlgorithmIdentifier are in PKIX1Explicit88 and CRLReason is in 1216 PKIX1Implicit88?] 1218 B.1. OCSP in ASN.1 1220 OCSP {iso(1) identified-organization(3) dod(6) internet(1) 1221 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)} 1223 DEFINITIONS EXPLICIT TAGS::= 1225 BEGIN 1227 IMPORTS 1229 -- Directory Authentication Framework (X.509) 1230 Certificate, AlgorithmIdentifier, CRLReason 1231 FROM AuthenticationFramework { joint-iso-itu-t ds(5) module(1) 1232 authenticationFramework(7) 3 } 1234 -- PKIX Certificate Extensions 1235 AuthorityInfoAccessSyntax 1236 FROM PKIX1Implicit88 {iso(1) identified-organization(3) 1237 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1238 id-mod(0) id-pkix1-implicit-88(2)} 1240 Name, GeneralName, CertificateSerialNumber, Extensions, 1241 id-kp, id-ad-ocsp 1242 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 1243 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1244 id-mod(0) id-pkix1-explicit-88(1)}; 1246 OCSPRequest ::= SEQUENCE { 1247 tbsRequest TBSRequest, 1248 optionalSignature [0] EXPLICIT Signature OPTIONAL } 1250 TBSRequest ::= SEQUENCE { 1251 version [0] EXPLICIT Version DEFAULT v1, 1252 requestorName [1] EXPLICIT GeneralName OPTIONAL, 1253 requestList SEQUENCE OF Request, 1254 requestExtensions [2] EXPLICIT Extensions OPTIONAL } 1256 Signature ::= SEQUENCE { 1257 signatureAlgorithm AlgorithmIdentifier, 1258 signature BIT STRING, 1259 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 1261 Version ::= INTEGER { v1(0) } 1263 Request ::= SEQUENCE { 1264 reqCert CertID, 1265 singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } 1267 CertID ::= SEQUENCE { 1268 hashAlgorithm AlgorithmIdentifier, 1269 issuerNameHash OCTET STRING, -- Hash of Issuer's DN 1270 issuerKeyHash OCTET STRING, -- Hash of Issuers public key 1271 serialNumber CertificateSerialNumber } 1273 OCSPResponse ::= SEQUENCE { 1274 responseStatus OCSPResponseStatus, 1275 responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } 1277 OCSPResponseStatus ::= ENUMERATED { 1278 successful (0), -- Response has valid confirmations 1279 malformedRequest (1), -- Illegal confirmation request 1280 internalError (2), -- Internal error in issuer 1281 tryLater (3), -- Try again later 1282 -- (4) is not used 1283 sigRequired (5), -- Must sign the request 1284 unauthorized (6) -- Request unauthorized 1285 } 1287 ResponseBytes ::= SEQUENCE { 1288 responseType OBJECT IDENTIFIER, 1289 response OCTET STRING } 1291 BasicOCSPResponse ::= SEQUENCE { 1292 tbsResponseData ResponseData, 1293 signatureAlgorithm AlgorithmIdentifier, 1294 signature BIT STRING, 1295 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 1297 ResponseData ::= SEQUENCE { 1298 version [0] EXPLICIT Version DEFAULT v1, 1299 responderID ResponderID, 1300 producedAt GeneralizedTime, 1301 responses SEQUENCE OF SingleResponse, 1302 responseExtensions [1] EXPLICIT Extensions OPTIONAL } 1304 ResponderID ::= CHOICE { 1305 byName [1] Name, 1306 byKey [2] KeyHash } 1308 KeyHash ::= OCTET STRING --SHA-1 hash of responder's public key 1309 --(excluding the tag and length fields) 1311 SingleResponse ::= SEQUENCE { 1312 certID CertID, 1313 certStatus CertStatus, 1314 thisUpdate GeneralizedTime, 1315 nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, 1316 singleExtensions [1] EXPLICIT Extensions OPTIONAL } 1318 CertStatus ::= CHOICE { 1319 good [0] IMPLICIT NULL, 1320 revoked [1] IMPLICIT RevokedInfo, 1321 unknown [2] IMPLICIT UnknownInfo } 1323 RevokedInfo ::= SEQUENCE { 1324 revocationTime GeneralizedTime, 1325 revocationReason [0] EXPLICIT CRLReason OPTIONAL } 1327 UnknownInfo ::= NULL 1329 ArchiveCutoff ::= GeneralizedTime 1331 AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER 1333 ServiceLocator ::= SEQUENCE { 1334 issuer Name, 1335 locator AuthorityInfoAccessSyntax } 1337 -- Object Identifiers 1339 id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } 1340 id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } 1341 id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } 1342 id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } 1343 id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } 1344 id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 } 1345 id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } 1346 id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 } 1347 id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 } 1349 END 1350 B.2. Preferred Signature Algorithms ASN.1 1352 B.2.1. ASN.1 Module 1354 OCSP-AGILITY-2009 { iso(1) identified-organization(3) dod(6) 1355 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1356 id-mod-ocsp-agility-2009-93(66) } 1358 DEFINITIONS EXPLICIT TAGS ::= 1359 BEGIN 1361 EXPORTS ALL; -- export all items from this module 1362 IMPORTS 1364 id-pkix-ocsp 1365 FROM OCSP-2009 -- From [RFC5912] 1366 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 1367 mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-02(48) } 1369 AlgorithmIdentifier{}, SIGNATURE-ALGORITHM, PUBLIC-KEY 1370 FROM AlgorithmInformation-2009 -- From [RFC5912] 1371 { iso(1) identified-organization(3) dod(6) internet(1) 1372 security(5) mechanisms(5) pkix(7) id-mod(0) 1373 id-mod-algorithmInformation-02(58) } 1375 EXTENSION 1376 FROM PKIX-CommonTypes-2009 -- From [RFC5912] 1377 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 1378 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} ; 1380 -- Add re-preferred-signature-algorithms to the set of extensions 1381 -- for TBSRequest.requestExtensions 1383 re-preferred-signature-algorithms EXTENSION ::= { 1384 SYNTAX PreferredSignatureAlgorithms 1385 IDENTIFIED BY id-pkix-ocsp-pref-sig-algs } 1387 id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 } 1389 PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm 1391 PreferredSignatureAlgorithm ::= SEQUENCE { 1392 sigIdentifier AlgorithmIdentifier{SIGNATURE-ALGORITHM, {...}}, 1393 certIdentifier AlgorithmIdentifier{PUBLIC-KEY, {...}} OPTIONAL 1394 } 1396 END 1397 B.2.2. 1988 ASN.1 Module 1399 OCSP-AGILITY-88 { iso(1) identified-organization(3) dod(6) internet(1) 1400 security(5) mechanisms(5) pkix(7) id-mod(0) 1401 id-mod-ocsp-agility-2009-88(67) } 1403 DEFINITIONS EXPLICIT TAGS ::= 1404 BEGIN 1406 -- EXPORTS ALL; 1407 IMPORTS 1409 id-pkix-ocsp 1410 FROM OCSP {iso(1) identified-organization(3) dod(6) internet(1) 1411 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)} 1413 AlgorithmIdentifier 1414 FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) 1415 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1416 id-pkix1-explicit(18) }; 1418 id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 } 1420 PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm 1422 PreferredSignatureAlgorithm ::= SEQUENCE { 1423 sigIdentifier AlgorithmIdentifier, 1424 certIdentifier AlgorithmIdentifier OPTIONAL } 1426 END 1428 Appendix C. Media Types 1430 C.1. application/ocsp-request 1432 Type name: application 1434 Subtype name: ocsp-request 1436 Required parameters: None 1438 Optional parameters: None 1440 Encoding considerations: binary 1442 Security considerations: Carries a request for information. This 1443 request may optionally be cryptographically signed. 1445 Interoperability considerations: None 1447 Published specification: X.509 Internet Public Key Infrastructure 1448 Online Certificate Status Protocol - OCSP 1450 Applications that use this media type: OCSP clients 1452 Additional information: 1453 Magic number(s): None 1454 File extension(s): .ORQ 1455 Macintosh File Type Code(s): none 1457 Person & email address to contact for further information: 1458 Ambarish Malpani 1460 Intended usage: COMMON 1462 Restrictions on usage: none 1464 Author: 1465 Ambarish Malpani 1467 Change controller: 1468 The IESG 1470 C.2. application/ocsp-response 1472 Type name: application 1474 Subtype name: ocsp-response 1476 Required parameters: None 1478 Optional parameters: None 1480 Encoding considerations: binary 1482 Security considerations: Carries a cryptographically signed response. 1484 Interoperability considerations: None 1486 Published specification: X.509 Internet Public Key Infrastructure 1487 Online Certificate Status Protocol - OCSP 1489 Applications which use this media type: OCSP servers 1491 Additional information: 1492 Magic number(s): None 1493 File extension(s): .ORS 1494 Macintosh File Type Code(s): none 1496 Person & email address to contact for further information: 1497 Ambarish Malpani 1499 Intended usage: COMMON 1501 Restrictions on usage: none 1503 Author: 1504 Ambarish Malpani 1506 Change controller: 1507 The IESG 1509 Appendix D. Example PKIs With OCSP Responders 1511 This appendix provides some examples of valid PKI architectures that 1512 include OCSP responders. 1514 D.1. Integrated OCSP Responders 1516 The examples in this appendix involve integrated OCSP responders. 1517 None of the certificates depicted in the examples in this appendix 1518 include an extended key usage extension that asserts the 1519 id-kp-OCSPSigning OID. 1521 Figure 1 depicts a scenario in which the OCSP response is signed 1522 using the same key as the target certificate. 1524 +-----------------------------------------+ 1525 | Certification Authority/OCSP Responder | 1526 | +-------------------------------------+ | 1527 | | CA's certificate | | 1528 | | +-------------------------------+ | | 1529 | | | certificate and OCSP response | | | 1530 | | | signing key | | | 1531 | | +---|---------------------|-----+ | | 1532 | +------|---------------------|--------+ | 1533 +--------|---------------------|----------+ 1534 | | 1535 V V 1536 +---------------+ +--------------------+ 1537 | OCSP response | | target certificate | 1538 +---------------+ +--------------------+ 1540 Figure 1. Integrated OCSP Responder With One Certificate and OCSP 1541 Response Signing Key 1543 Figures 2 and 3 depict scenarios in which the OCSP response is signed 1544 using a different key than the one used to sign the target 1545 certificate. In each case, the CA has performed a key rollover since 1546 it issued the target certificate, and is using its new key to sign 1547 OCSP responses. In Figure 2, the CA has used its new private key to 1548 sign a self-issued certificate that contains its old public key. In 1549 Figure 3, the CA has been issued a new certificate from the root CA, 1550 while the certificate from the root CA certifying the old public key 1551 remains valid. 1553 +------------------------------------------------------+ 1554 | Certification Authority/OCSP Responder | 1555 | +-------------------+ +-------------------------+ | 1556 | | CA's certificate | | self-issued certificate | | 1557 | | +---------------+ | | +-------------+ | | 1558 | | | OCSP response | | | | certificate | | | 1559 | | | signing key |----------->| signing key | | | 1560 | | +-----|---------+ | | +----|--------+ | | 1561 | +-------|-----------+ +----------|--------------+ | 1562 +---------|---------------------------|----------------+ 1563 | | 1564 V V 1565 +---------------+ +--------------------+ 1566 | OCSP response | | target certificate | 1567 +---------------+ +--------------------+ 1569 Figure 2. Integrated OCSP Responder With a Self-issued Key 1570 Rollover Certificate 1572 +-----------------------------------------+ 1573 | Root CA | 1574 | +-------------------------------------+ | 1575 | | Root CA's self-signed certificate | | 1576 | | +-------------------------------+ | | 1577 | | | certificate | | | 1578 | | | signing key | | | 1579 | | +--|-------------------------|--+ | | 1580 | +-----|-------------------------|-----+ | 1581 +-------|-------------------------|-------+ 1582 | | 1583 +-----------|-------------------------|------------+ 1584 | V CA/OCSP Responder V | 1585 |+--------------------+ +--------------------+ | 1586 || CA's certificate 2 | | CA's certificate 1 | | 1587 || +---------------+ | | +-------------+ | | 1588 || | OCSP response | | | | certificate | | | 1589 || | signing key | | | | signing key | | | 1590 || +------|--------+ | | +------|------+ | | 1591 |+--------|-----------+ +---------|----------+ | 1592 +---------|---------------------------|------------+ 1593 | | 1594 V V 1595 +---------------+ +--------------------+ 1596 | OCSP response | | target certificate | 1597 +---------------+ +--------------------+ 1599 Figure 3. Integrated OCSP Responder With a Separate Key Certified 1600 by Root CA 1602 D.2. Designated OCSP Responders 1604 The examples in this appendix involve designated OCSP responders. 1605 Certificates that are marked with "**" include an extended key usage 1606 extension with the id-kp-OCSPSigning OID. 1608 Figure 4 depicts a scenario in which the OCSP responder's certificate 1609 is signed using the same key as the target certificate. 1611 +-----------------------------------------+ 1612 | Certification Authority | +----------------------+ 1613 | +-------------------------------------+ | | OCSP Responder's | 1614 | | CA's certificate | | | certificate **| 1615 | | +-------------------------------+ | | | +------------------+ | 1616 | | | certificate signing key |------>| | OCSP Responder's | | 1617 | | +---------------|---------------+ | | | | key | | 1618 | +------------------|------------------+ | | +--------|---------+ | 1619 +--------------------|--------------------+ +----------|-----------+ 1620 | | 1621 V V 1622 +--------------------+ +---------------+ 1623 | target certificate | | OCSP response | 1624 +--------------------+ +---------------+ 1626 Figure 4. Designated OCSP Responder in Which CA Has One Certificate 1627 Signing Key 1629 +-------------------------------------------------------------------+ 1630 | Root CA | 1631 | +-----------------------------------+ +------------------------+| 1632 | | Root CA's self-signed certificate | | OCSP certificate **|| 1633 | | +-------------------------------------------------------------+|| 1634 | | | certificate and OCSP signing key ||| 1635 | | +---------------|---------------------------------------------+|| 1636 | +-----------------|-----------------+ +-----------^------------+| 1637 +-------------------|---------------------------------|-------------+ 1638 | | 1639 V | 1640 +-----------------------------+ | 1641 | Sub CA certificate | | 1642 | +-------------------------+ | | 1643 | | certificate signing key |--------------------+ 1644 | +-------------------------+ | 1645 +-----------------------------+ 1647 Figure 5. Integrated and Designated OCSP Responder 1648 Figure 5 depicts a hierarchical PKI in which the root CA uses its key 1649 to sign OCSP responses for both the certificates that it issues and 1650 certificates issued by the subordinate CA. The subordinate CA has 1651 designated the root CA as authorized to provide revocation status 1652 information for the certificates that it issues by issuing a 1653 certificate to the root CA with an extended key usage extension that 1654 includes the id-kp-OCSPSigning OID. When an OCSP client is verifying 1655 a response from the OCSP responder that contains a target certificate 1656 issued by the root CA the OCSP responder is an integrated OCSP 1657 responder. When an OCSP client is verifying a response from the OCSP 1658 responder that contains a target certificate issued by the 1659 subordinate CA the OCSP responder is a designated OCSP responder. 1661 Figure 6 depicts a scenario in which the OCSP responder's certificate 1662 is signed using a different key than the one used to sign the target 1663 certificate. The CA has performed a key rollover since it issued the 1664 target certificate, and the OCSP responder's certificate was signed 1665 using the CA's new private key. The CA has used its new private key 1666 to sign a self-issued certificate that contains its old public key. 1668 +-----------------------------------------------------+ 1669 | Certification Authority | 1670 |+--------------------+ +-------------------------+ | 1671 || CA's certificate | | self-issued certificate | | 1672 || +---------------+ | | +---------------+ | | 1673 || | certificate | | | | certificate | | | 1674 || | signing key 2 |---------->| signing key 1 | | | 1675 || +----------|----+ | | +-------|-------+ | | 1676 |+------------|-------+ +------------|------------+ | 1677 +-------------|------------------------|--------------+ 1678 | | 1679 V V 1680 +----------------------+ +-------------+ 1681 | OCSP Responder's | | target | 1682 | certificate **| | certificate | 1683 | +------------------+ | +-------------+ 1684 | | OCSP Responder's | | 1685 | | key ------>+---------------+ 1686 | +------------------+ | | OCSP response | 1687 +----------------------+ +---------------+ 1689 Figure 6. Designated OCSP Responder and CA with a Self-issued Key 1690 Rollover Certificate 1692 Figure 7 depicts another scenario in which the OCSP responder's 1693 certificate is signed using a different key than the one used to sign 1694 the target certificate. As in Figure 6, the CA has performed a key 1695 rollover since it issued the target certificate, and the OCSP 1696 responder's certificate was signed using the CA's new private key. 1697 In this case, however, the CA has been issued a new certificate from 1698 the root CA, while the certificate from the root CA certifying the 1699 old public key remains valid. 1701 In the PKI in Figure 7, there is also a designated OCSP responder 1702 that provides revocation status information for certificates issued 1703 by the root CA. So, the root CA has issued a certificate to this 1704 OCSP responder that includes an extended key usage extension with the 1705 id-kp-OCSPSigning OID. 1707 +-----------------------------------------+ 1708 | Root CA | 1709 | +-------------------------------------+ | +----------------------+ 1710 | | Root CA's self-signed certificate | | | Root's OCSP | 1711 | | +-------------------------------+ | | | Responder's cert **| 1712 | | | certificate | | | | +------------------+ | 1713 | | | signing key |-------->| Root's OCSP | | 1714 | | +-|---------------------------|-+ | | | | Responder's key | | 1715 | +----|---------------------------|----+ | | +------------------+ | 1716 +------|---------------------------|------+ +----------------------+ 1717 | | 1718 +------|---------------------------|------------------+ 1719 | V Certification Authority V | 1720 | +----------------------+ +--------------------+ | 1721 | | CA's certificate 2 | | CA's certificate 1 | | 1722 | | +---------------+ | | +---------------+ | | 1723 | | | certificate | | | | certificate | | | 1724 | | | signing key 2 | | | | signing key 1 | | | 1725 | | +----------|----+ | | +-----|---------+ | | 1726 | +-------------|--------+ +--------|-----------+ | 1727 +---------------|-----------------------|-------------+ 1728 | | 1729 V V 1730 +----------------------+ +-------------+ 1731 | OCSP Responder's | | target | 1732 | certificate **| | certificate | 1733 | +------------------+ | +-------------+ 1734 | | OCSP Responder's | | 1735 | | key ------->+---------------+ 1736 | +------------------+ | | OCSP response | 1737 +----------------------+ +---------------+ 1739 Figure 7. Designated OCSP Responder and CA With Two Keys Certified 1740 by Root CA 1741 As noted in Section 2.3.5.1, some OCSP clients cannot validate 1742 signatures on OCSP responses created by designated OCSP responders if 1743 the OCSP responder's certificate has been signed using a different 1744 key than the target certificate. Figure 8 depicts a CA that 1745 accommodates this limitation by issuing two certificates to the 1746 designated OCSP responder, one signed with its old private key and 1747 one signed with its new private key. Both certificates include an 1748 extended key usage extension with the id-kp-OCSPSigning OID. 1750 As in Figure 7, there is also a designated OCSP responder that 1751 provides revocation status information for certificates issued by the 1752 root CA, and so this responder has been issued a certificate by the 1753 root CA. 1755 +-----------------------------------------+ 1756 | Root CA | 1757 | +-------------------------------------+ | +----------------------+ 1758 | | Root CA's self-signed certificate | | | Root's OCSP | 1759 | | +-------------------------------+ | | | Responder's cert **| 1760 | | | certificate | | | | +------------------+ | 1761 | | | signing key |-------->| Root's OCSP | | 1762 | | +-|---------------------------|-+ | | | | Responder's key | | 1763 | +----|---------------------------|----+ | | +------------------+ | 1764 +------|---------------------------|------+ +----------------------+ 1765 | | 1766 +------|---------------------------|------------------+ 1767 | V Certification Authority V | 1768 | +----------------------+ +--------------------+ | 1769 | | CA's certificate 2 | | CA's certificate 1 | | 1770 | | +---------------+ | | +---------------+ | | 1771 | | | certificate | | | | certificate | | | 1772 | | | signing key 2 | | | | signing key 1 | | | 1773 | | +----------|----+ | | +-----|---------+ | | 1774 | +-------------|--------+ +--------|-----------+ | 1775 +---------------|-----------------------|-------------+ 1776 | | 1777 V V 1778 +----------------------+ +----------------------+ 1779 | OCSP Responder's | | OCSP Responder's | 1780 | certificate 1 **| | certificate 2 **| 1781 | +-----------------------------------------------+ | 1782 | | OCSP Responder's key | | 1783 | +-----------------------------------------------+ | 1784 +----------------------+ +----------------------+ 1786 Figure 8. Designated OCSP Responder With Two Certificates 1787 Figure 9 depicts a scenario in which an organization has a 1788 hierarchical PKI with three CAs, but has a single designated OCSP 1789 responder, which each CA has designated as being authorized to 1790 provide revocation status information for the certificates that it 1791 has issued. In order to satisfy the requirement that the authorizing 1792 CA issue a certificate directly to the designated OCSP responder, 1793 each of the CAs has issued a certificate to the OCSP responder that 1794 includes the id-kp-ocspSigning OID in the extended key usage 1795 extension. The subject public key in each of the three certificates 1796 issued to the OCSP responder is the same since the OCSP responder 1797 uses the same private key to sign all responses. 1799 +-----------------------------------------+ 1800 | Root CA | 1801 | +-------------------------------------+ | 1802 | | Root CA's self-signed certificate | | 1803 | | +-------------------------------+ | | 1804 | | | Root CA's certificate | | | 1805 | | | signing key | | | 1806 | | +----|------------|---------|---+ | | 1807 | +-------|------------|---------|------+ | 1808 +---------|------------|---------|--------+ 1809 | | | 1810 +----------------|-------+ | +----|-------------------+ 1811 | CA 1 V | | | V CA 2 | 1812 | +--------------------+ | | | +--------------------+ | 1813 | | CA 1's certificate | | | | | CA 2's certificate | | 1814 | | +---------------+ | | | | | +---------------+ | | 1815 | | | CA 1's | | | | | | | CA 2's | | | 1816 | | | certificate | | | | | | | certificate | | | 1817 | | | signing key | | | | | | | signing key | | | 1818 | | +-----|---------+ | | | | | +---------|-----+ | | 1819 | +-------|------------+ | | | +------------|-------+ | 1820 +---------|--------------+ | +--------------|---------+ 1821 | | | 1822 V V V 1823 +------------------+ +------------------+ +------------------+ 1824 | OCSP Responder's | | OCSP Responder's | | OCSP Responder's | 1825 | certificate 1 **| | certificate 2 **| | certificate 3 **| 1826 | +--------------------------------------------------------+ | 1827 | | OCSP Responder's key | | 1828 | +--------------------------------------------------------+ | 1829 +------------------+ +------------------+ +------------------+ 1831 Figure 9. Hierarchical PKI with One Designated OCSP Responder 1833 D.3. Locally Trusted OCSP Responder 1835 Figure 10 depicts a PKI with a locally trusted OCSP responder. The 1836 PKI consists of six companies' CAs that are connected through a 1837 bridge CA. Company F operates an OCSP responder that it only makes 1838 accessible to computers owned by Company F. Company F's computers 1839 have been configured to trust the OCSP responder's public key to 1840 validate signatures on OCSP responses and have also been configured 1841 to use the OCSP responder to obtain revocation status information for 1842 all certificates. 1844 Each of the CAs in the PKI issues CRLs, which they make available 1845 from publicly accessible directories. The OCSP responder retrieves 1846 these CRLs and uses the information in them to generate responses for 1847 its clients. 1849 +-----------+ +-----------+ +-----------+ 1850 | Company A | | Company B | | Company C | 1851 | CA | | CA | | CA | 1852 +-----------+ +-----------+ +-----------+ 1853 \ | / 1854 \ | / 1855 +-----------+ +----------------+ +-----------+ 1856 | Company D | | Bridge | | Company E | 1857 | CA |---| CA |---| CA | 1858 +-----------+ +----------------+ +-----------+ 1859 | 1860 | 1861 +-------------+ 1862 | Company F | 1863 | Root CA | 1864 +-------------+ 1865 / | \ 1866 / | \ 1867 +-----------+ +-----------+ +-----------+ 1868 | Company F | | Company F | | Company F | 1869 | Sub CA 1 | | Sub CA 2 | | Sub CA 3 | 1870 +-----------+ +-----------+ +-----------+ 1872 +------------------------------+ 1873 | Company F's OCSP Responder's | 1874 | self-signed certificate | 1875 | +----------------------+ | +---------------+ 1876 | | OCSP Responder's key |------>| OCSP response | 1877 | +----------------------+ | +---------------+ 1878 +------------------------------+ 1880 Figure 10. Locally Trusted OCSP Responder 1882 Author's Address 1884 David Cooper 1885 National Institute of Standards and Technology 1886 100 Bureau Drive, Mail Stop 8930 1887 Gaithersburg, MD 20899-8930 1888 USA 1889 EMail: david.cooper@nist.gov