INTERNET-DRAFT D. Pinkas Intended Status: Proposed Standard Bull SAS Obsoletes: 2560, 6277 (if approved) Expires: February 22, 2013 August 23, 2012 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP draft-pinkas-rfc2560bis-00 Abstract This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFC 2560 and RFC 6277. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Denis Pinkas Expires February 22, 2013 [Page 1] INTERNET DRAFT PKIX OCSP August 23, 2012 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Response . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Exception Cases . . . . . . . . . . . . . . . . . . . . . . 10 3. Functional Requirements . . . . . . . . . . . . . . . . . . . 10 3.1. Requirements for certificate content . . . . . . . . . . . 10 3.1.1. Target certificate content . . . . . . . . . . . . . . 10 3.1.2. OCSP certificate content . . . . . . . . . . . . . . . 11 3.1.3. CA certificate content . . . . . . . . . . . . . . . . 11 3.2. Requirements for CAs supporting directly an OCSP service . 11 3.3. Requirements for CAs using OCSP Responders . . . . . . . . 11 3.3.1. Designation of a new OCSP Responder . . . . . . . . . . 11 3.3.2. CA key rollover . . . . . . . . . . . . . . . . . . . . 12 3.3.3. OCSP Responder key rollover . . . . . . . . . . . . . . 12 3.4. Requirements for OCSP clients . . . . . . . . . . . . . . . 12 4. Detailed Protocol . . . . . . . . . . . . . . . . . . . . . . .13 4.1. Request Syntax . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Response Syntax . . . . . . . . . . . . . . . . . . . . . . 14 4.3. Response processing . . . . . . . . . . . . . . . . . . . . 17 4.3.1. Response processing by OCSP servers . . . . . . . . . . 18 4.3.1.1. Processing by a CA acting as an OCSP responder . . 18 4.3.1.2. Processing by an OCSP Responder . . . . . . . . . . 19 4.3.2. Response processing by an OCSP client . . . . . . . . . . 21 4.4. Mandatory and Optional Cryptographic Algorithms . . . . . . 24 4.5. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 24 4.5.1. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.5.2. CRL References . . . . . . . . . . . . . . . . . . . . 25 4.5.3. Acceptable Response Types . . . . . . . . . . . . . . . 25 4.5.4. Archive Cutoff . . . . . . . . . . . . . . . . . . . . 25 4.5.5. CRL Entry Extensions . . . . . . . . . . . . . . . . . 26 4.5.6. Service Locator . . . . . . . . . . . . . . . . . . . . 26 4.5.7. Preferred Signature Algorithms . . . . . . . . . . . . 26 4.5.7.1. Extension Syntax . . . . . . . . . . . . . . . . . 27 4.5.7.2. Responder Signature Algorithm Selection . . . . . . 28 4.5.7.2.1. Dynamic Response . . . . . . . . . . . . . . . 28 4.5.7.2.2. Static Response . . . . . . . . . . . . . . . . 29 Denis Pinkas Expires February 22, 2013 [Page 2] INTERNET DRAFT PKIX OCSP August 23, 2012 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 29 5.1. Denial of service attack using false error responses . . . 29 5.2. Using CRLs as a fall-back mechanism . . . . . . . . . . . . 29 5.3. Different results when using OCSP and CRLs . . . . . . . . 29 5.4. Denial of service attack using a flood of queries . . . . . 30 5.5. Use of precomputed responses . . . . . . . . . . . . . . . 30 5.6. Preferred Signature Algorithms . . . . . . . . . . . . . . 30 5.6.1. Use of insecure algorithms . . . . . . . . . . . . . . 31 5.6.2. Man in the Middle Downgrade Attack . . . . . . . . . . 31 5.6.3. Denial of Service Attack . . . . . . . . . . . . . . . 31 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 31 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.1. Normative References . . . . . . . . . . . . . . . . . . . 32 7.2. Informative References . . . . . . . . . . . . . . . . . . 32 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.1 OCSP over HTTP . . . . . . . . . . . . . . . . . . . . . . . 34 A.1.1. Request . . . . . . . . . . . . . . . . . . . . . . . . 34 A.1.2. Response . . . . . . . . . . . . . . . . . . . . . . . 34 Appendix B. ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 38 B.1. OCSP in ASN.1 . . . . . . . . . . . . . . . . . . . . . . . 38 B.2. Preferred Signature Algorithms ASN.1 . . . . . . . . . . . 38 B.2.1. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 38 B.2.2. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . . 39 Appendix C. MIME registrations . . . . . . . . . . . . . . . . . . 40 C.1. application/ocsp-request . . . . . . . . . . . . . . . . . 40 C.2. application/ocsp-response . . . . . . . . . . . . . . . . . 40 Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . . 41 Denis Pinkas Expires February 22, 2013 [Page 3] INTERNET DRAFT PKIX OCSP August 23, 2012 1. Introduction This document specifies an on line protocol able to provide the revocation status of a digital certificate. It also specifies requirements for the entities concerned with this protocol: OCSP clients, OCSP servers and CAs making use of OCSP servers. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This specification obsoletes [RFC2560] and [RFC6277]. The primary reason for the publication of this document is to address ambiguities that have been found since the publication of RFC 2560. This document differs from RFC 2560 in the following areas: All over the document the term "OCSP Responder" (with a capital R) indicates an OCSP server which has received a delegation from at least one CA and which has obtained at least one OCSP certificate, whereas the terms "OCSP server" and "OCSP responder" are used to designate either a CA providing itself an OCSP service or an OCSP Responder. o Section 2 has been rephrased to indicate that the response may provide fresher status than CRLs, but not necessarily. o Section 2.1 has been rephrased to indicate that the request may contain one or more target certificate identifiers. o Section 2.2 has been rephrased, in particular to indicate that the key used to sign an OCSP response MUST be either the key from a CA or the key from an OCSP Responder. In the later case, the certificate(s) issued to the OCSP Responder MUST be directly issued by the CA that has issued a target certificate and under the same key that was used to sign the target certificate. In both cases, the validity of the signature over the OCSP response MUST be evaluated for each target certificate. o Section 2.3 extends the use of the "unauthorized" error response, as specified in [RFC5019]. o Section 2.4 has been removed and its material has been incorporated into section 4.2. o Section 2.5 has been removed and its material has been incorporated at the end of section 4.2. Denis Pinkas Expires February 22, 2013 [Page 4] INTERNET DRAFT PKIX OCSP August 23, 2012 o Section 2.6 has been removed and its material has been incorporated at the end of section 2.2. o Section 2.7 has been removed since it did not solved the issue of a CA key compromise correctly: the verification of the certification path is the right way to solve the issue and is in the usual procedure. o Section 3 was only addressing the content of a target certificate and signed response acceptance requirements. It has been expanded to specify the content of a target certificate, of an OCSP certificate and of a CA certificate. It now addresses requirements for CAs with a locally hosted OCSP service as well as with OCSP Responders. It addresses the ways to perform key rollovers. o Section 3 adds a requirement for an OCSP client to verify that the current time is within the validity period of the target certificate. o Section 4.1 gathers text that was spread around RFC 2560 and now details every parameter from the ASN.1 syntax. o Section 4.1.2 has been incorporated into section 4.1. o Section 4.2 gathers text that was spread around RFC 2560 and now details every parameter from the ASN.1 syntax. o Sections 4.2.1 and 4.2.2 have been incorporated into section 4.2. o Section 4.2 adds a requirement for the OCSP server to include OCSP certificates in the certs field of BasicOCSPResponse when the OCSP server is an authorized OCSP Responder. o Section 4.2 specifies that the local system time is the local UTC time. o Section 4.2 states that a response may include revocation status information for certificates that were not included in the request, as permitted in [RFC5019]. o Section 4.3 has been remodeled to detail the processing of an OCSP request and the construction of an OCSP response by an OCSP server acting as an OCSP responder and by an OCSP Responder, and the processing in three steps of an OCSP response by an OCSP client or by a verifier. o Section 4.3 addresses the verification of an OCSP response both at the current time and at a time in the past. Denis Pinkas Expires February 22, 2013 [Page 5] INTERNET DRAFT PKIX OCSP August 23, 2012 o Section 4.3 changes the set of cryptographic algorithms that clients MUST support and the set of cryptographic algorithms that clients SHOULD support as specified in [RFC6277]. o Section 4.5.1 specifies the ASN.1 syntax for the nonce extension, which was missing in RFC 2560. o Section 4.5.7 incorporates the text which was originally present in [RFC6277] and specifies an extension that may be included in a request message to specify signature algorithms the client would prefer the server use to sign the response. o Section 5 adds a new warning: the root used by an OCSP Responder to verified published CRLs is not necessarily the same as the one that would be used by the OCSP client if it were going to verify the CRLs itself. Hence the revocation status may not be identical in both cases. o Section 5 is now addressing a technique to limit a flood of queries when a large number of certificates is supported by the same OCSP Responder. o Section 5 provides an alternative for archival applications when the algorithm used to sign an OCSP request becomes weak: the use of time-stamping. An overview of the protocol is provided in section 2. Functional requirements are specified in section 3. Details of the protocol are in section 4. Security issues with the protocol are covered in section 5. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1 syntactic elements and appendix C specifies the mime types for the messages. Denis Pinkas Expires February 22, 2013 [Page 6] INTERNET DRAFT PKIX OCSP August 23, 2012 2. Protocol Overview The Online Certificate Status Protocol (OCSP) is a client-server protocol which enables applications to obtain the revocation status of one or more certificates either "good", "revoked", or "unknown". The revocation status may be provided by the server either using a real time access to a database of issued certificates, or using a batch access to a database of issued certificates, or using a real time access to a database of revocation statuses of issued certificates, or using a batch access to a database of revocation statuses of issued certificates, or using CRLs, or using a combination of base CRLs and delta CRLs. In the first case, it is possible to obtain timely revocation status information, whereas in the other cases, the freshness of the revocation status is not better than the mechanisms it is based on. OCSP may also provide additional status information using extensions. When using OCSP, an OCSP client issues a certificate revocation status request to an OCSP responder for one or more certificates and then suspends acceptance of the certificate(s) in question until the responder provides a response. This document specifies the data that needs to be exchanged between an application checking the status of a certificate and the server providing that status. The document also specifies requirements for CAs using OCSP servers, for OCSP clients and for OCSP servers. 2.1. Request An OCSP request contains the following data: -- a protocol version, -- a service request, -- one or more target certificate identifiers, and -- optional extensions which MAY be processed by the OCSP server. An OCSP request MAY be signed. 2.2. Response Upon receipt of a request, an OCSP server determines if: 1. the message is well formed, 2. the OCSP responder is configured to provide the requested service, and 3. the request contains the information needed by the responder. Denis Pinkas Expires February 22, 2013 [Page 7] INTERNET DRAFT PKIX OCSP August 23, 2012 If any one of the prior conditions is not met, the OCSP server produces an error message; otherwise, it returns a definitive response. OCSP responses can be of various types. An OCSP response consists of a response type and the bytes of the actual response. There is one basic type of OCSP response that MUST be supported by all OCSP servers and clients. The rest of this document pertains only to this basic response type. All definitive response messages SHALL be digitally signed. A response message MUST either be signed by a certificate's issuer or by an authorized OCSP Responder. In that later case, the CA MUST explicitly designate the OCSP Responder by issuing an OCSP certificate to the OCSP Responder. OCSP signing delegation SHALL be indicated by the inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate extension included in the OCSP response signer's certificate. This certificate MUST be issued directly by the CA and under the same key that was used to issue the target certificate. Systems or applications that rely on OCSP responses MUST be capable of detecting and enforcing use of the id-ad-ocspSigning value as described above. They MAY provide a means of locally configuring one or more OCSP signing authorities, and specifying the set of CAs for which each signing authority is trusted. A definitive response message is composed of: -- the version of the response syntax, -- an identifier of the OCSP server, -- the time at which the response was produced, -- single responses for each of the target certificates, -- optional extensions, -- the signature algorithm OID, -- the signature computed across hash of the response, and -- optional certificates. The single response for each of the target certificates in a request consists of: -- a target certificate identifier, -- the certificate status value (good, revoked or unknown), -- the response validity interval, and -- optional extensions. The purpose of the identifier of the OCSP server is to allow OCSP clients to find whether the definitive response was signed by a CA or by an OCSP Responder. Denis Pinkas Expires February 22, 2013 [Page 8] INTERNET DRAFT PKIX OCSP August 23, 2012 The identifier of the OCSP server SHOULD either be the name or the key from a CA, or the name or the key from a OCSP Responder. Unless there exist local rules (which are outside the scope of this document) for verifying that a single response is correctly signed, the following applies: When the identifier matches with the name of the CA which has issued the target certificate or corresponds to the key used to issue the target certificate, then a single response is correctly signed only if the digital signature of the OCSP response is valid using the key used to sign the target certificate. When the identifier does not match with the name of the CA which has issued the target certificate or does not correspond to the key used to issue the target certificate, then an single response is correctly signed only if : (a) there exists in the response an OCSP certificate issued by the CA which has issued the target certificate which is signed by the same key as the one used to issue the target certificate, and (b) the digital signature of the OCSP response is valid using the subjectPublicKey contained in this OCSP certificate. This specification defines the following definitive response indicators for use in the certificate status value: -- good, -- revoked, or -- unknown. The "good" status indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate's validity interval. Response extensions may be used to convey additional information on assertions made by the server regarding the status of the certificate such as positive statement about issuance, validity, etc. The "revoked" status indicates that the certificate has been revoked (either permanently or temporarily (on hold)). The "unknown" status indicates either that the server doesn't know about the revocation status of the certificate being requested or does not know about the certificate being requested. Denis Pinkas Expires February 22, 2013 [Page 9] INTERNET DRAFT PKIX OCSP August 23, 2012 2.3. Exception Cases In case of errors, the OCSP Responder may return an error message. These messages are not signed. Errors can be of the following types: -- malformedRequest, -- internalError, -- tryLater, -- sigRequired, or -- unauthorized. A server produces the "malformedRequest" response if the request received does not conform to the OCSP syntax. The response "internalError" indicates that the OCSP responder reached an inconsistent internal state. The query should be retried, potentially with another responder. In the event that the OCSP server is operational, but unable to return a status for the requested certificate, the "tryLater" response can be used to indicate that the service exists, but is temporarily unable to respond. The response "sigRequired" is returned in cases where the server requires the client to sign the request in order to construct a response. The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server or the server is not capable of responding authoritatively (cf. [RFC5019], Section 2.2.3). 3. Functional Requirements 3.1. Requirements for certificate content 3.1.1. Target certificate content In order to convey to OCSP clients a well-known point of information access, CAs SHALL provide the capability to include the AuthorityInfoAccess extension (defined in [RFC5280], section 4.2.2.1) in certificates that can be checked using OCSP. CAs that support an OCSP service, either hosted locally or provided by an Authorized Responder, MUST provide for the inclusion of a value for a uniformResourceIndicator (URI) accessLocation and the OID value id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE. The value of the accessLocation field in the subject certificate defines the transport (e.g. HTTP) used to access the OCSP server and MAY contain other transport dependent information (e.g. a URL). Denis Pinkas Expires February 22, 2013 [Page 10] INTERNET DRAFT PKIX OCSP August 23, 2012 3.1.2. OCSP certificate content An OCSP certificate MUST contains the id-kp-OCSPSigning extended key usage as defined in section 4.2.1.12 from RFC 5280. It indicates that the certificate's issuer explicitly delegated OCSP signing authority to an authorized OCSP Responder that is using its own key. The digitalSignature bit in the keyUsage extension MUST also be set. 3.1.3. CA certificate content CAs that delegate the issuance of OCSP responses to one or more OCSP Responders MUST issue an OCSP certificate to each of these OCSP Responders. Their CA certificate MUST allow them to sign these OCSP certificates. Therefore the digitalSignature bit in the keyUsage extension MUST be set. Note 1: Since the CA issues certificates, the keyCertSign bit MUST also be set. Note 2: If the CA supports CRLs, in particular to revoke the certificate of the OCSP Responders, then the cRLSign bit, the digitalSignature bit and the keyCertSig bit MUST be set. 3.2. Requirements for CAs supporting directly an OCSP service When a CA that directly supports an OCSP service performs a key rollover: - for certificates issued under the old key, the CA SHALL continue to sign the revocation status of OCSP responses with that old key at least until all these certificates are expired, and - for certificates issued under the new key, the CA SHALL change the accessLocation in the AIA extension field of these certificates and sign the revocation status of OCSP responses with that new key at least until all these certificates are expired. 3.3. Requirements for CAs using OCSP Responders 3.3.1. Designation of a new OCSP Responder When a CA designates a new OCSP Responder, then it SHALL change the accessLocation in the AIA extension field for the newly issued certificates and issue an OCSP certificate to the new OCSP Responder using its current key. Denis Pinkas Expires February 22, 2013 [Page 11] INTERNET DRAFT PKIX OCSP August 23, 2012 3.3.2. CA key rollover When a CA that uses OCSP Responders performs a key rollover, then it MUST either designate a new OCSP Responder or keep the current OCSP Responder(s). If the CA designates a new OCSP Responder, then it SHALL change the accessLocation in the AIA extension field for the newly issued certificates and issue an OCSP certificate to the new OCSP Responder using its new key. If the CA keeps the same OCSP Responder(s), then it SHALL continue to use the same accessLocation(s) in the AIA extension field for the newly issued certificates and issue an OCSP certificate to the appropriate OCSP Responder(s) using its new key. 3.3.3. OCSP Responder key rollover When an OCSP Responder performs a key rollover (asynchronously from a CA key rollover), then each CA which has designated an OCSP Responder SHALL issue a new certificate for that OCSP Responder and for each of its issuing keys which meets the following property: - the issuing key has been used to sign at least one certificate which contains an AIA extension designating that OCSP Responder and that certificate is not yet expired. For a given URI value identifying the location of an OCSP Responder, the OCSP Responder SHALL only use one OCSP key pair value. 3.4. Requirements for OCSP clients An OCSP request allows getting in a single response the revocation status of one or more certificates. In order to request the status of one or more certificates in a single request, OCSP clients SHALL follow the following rules : For each candidate certificate, OCSP clients SHALL verify whether there exists a locally defined rule for the certificate in question which indicates the URI where the OCSP responder is located. If this rule exists, it SHALL be followed. Otherwise, OCSP clients SHALL determine whether the candidate certificate contains an AIA extension with an accessMethod which contains the id-ad-ocsp OID. If it is the case, the accessLocation contains a uniformResourceIdentifier (URI) which indicates the location of the OCSP server for that certificate. Certificates that contain the same URI MAY be grouped in a single request. Denis Pinkas Expires February 22, 2013 [Page 12] INTERNET DRAFT PKIX OCSP August 23, 2012 For each candidate certificate, the OCSP client SHALL verify that the current time is within the validity period of the target certificate. If this is not the case, the candidate certificate SHALL be discarded. 4. Detailed Protocol The ASN.1 syntax imports terms defined in [RFC5280]. For signature calculation, the data to be signed is encoded using the ASN.1 distinguished encoding rules (DER) [X.690]. ASN.1 EXPLICIT tagging is used as a default unless specified otherwise. The terms imported from elsewhere are: Extensions, CertificateSerialNumber, SubjectPublicKeyInfo, Name, AlgorithmIdentifier, CRLReason. 4.1. Request syntax This section specifies the ASN.1 specification for a request. The actual formatting of the message could vary depending on the transport mechanism used (HTTP, SMTP, LDAP, etc.). OCSPRequest ::= SEQUENCE { tbsRequest TBSRequest, optionalSignature [0] EXPLICIT Signature OPTIONAL } TBSRequest ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, requestorName [1] EXPLICIT GeneralName OPTIONAL, requestList SEQUENCE OF Request, requestExtensions [2] EXPLICIT Extensions OPTIONAL } Signature ::= SEQUENCE { signatureAlgorithm AlgorithmIdentifier, signature BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL} Version ::= INTEGER { v1(0) } Request ::= SEQUENCE { reqCert CertID, singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } CertID ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, -- Hash of Issuer's DN issuerKeyHash OCTET STRING, -- Hash of Issuers public key serialNumber CertificateSerialNumber } Denis Pinkas Expires February 22, 2013 [Page 13] INTERNET DRAFT PKIX OCSP August 23, 2012 requestorName is optional and MAY be used by the server for access control and audit purposes. requestList contains one or more single requests. requestExtensions is OPTIONAL. Any specific extension is OPTIONAL. The critical flag SHOULD NOT be set for any of them. Section 4.5 suggests several useful extensions. Additional extensions MAY be defined in additional RFCs. Unrecognized extensions MUST be ignored (unless they have the critical flag set and are not understood). reqCert contains the identifier of a target certificate. issuerNameHash is the hash of the Issuer's distinguished name. The hash shall be calculated over the DER encoding of the issuer's name field in the certificate being checked. issuerKeyHash is the hash of the Issuer's public key. The hash shall be calculated over the value (excluding tag and length) of the subject public key field in the issuer's certificate. The hash algorithm used for both these hashes, is identified in hashAlgorithm. serialNumber is the serial number of the certificate for which status is being requested. Note: The primary reason to use the hash of the CA's public key in addition to the hash of the CA's name, to identify the issuer, is that it is possible that two CAs may choose to use the same Name (uniqueness in the Name is a recommendation that cannot be enforced). Two CAs will never, however, have the same public key unless the CAs either explicitly decided to share their private key, or the key of one of the CAs was compromised. singleRequestExtensions is OPTIONAL. Any specific extension is OPTIONAL. The critical flag SHOULD NOT be set for any of them. The requestor MAY choose to sign the OCSP request. In that case, the signature is computed over the tbsRequest structure. If the request is signed, the requestor SHALL specify its name in the requestorName field. Also, for signed requests, the requestor MAY include certificates that help the OCSP responder verify the requestor's signature in the certs field of Signature. 4.2 Response Syntax This section specifies the ASN.1 specification for a confirmation response. The actual formatting of the message could vary depending on the transport mechanism used (HTTP, SMTP, LDAP, etc.). Denis Pinkas Expires February 22, 2013 [Page 14] INTERNET DRAFT PKIX OCSP August 23, 2012 An OCSP response at a minimum consists of a responseStatus field indicating the processing status of the prior request. If the value of responseStatus is one of the error conditions, responseBytes are not set. OCSPResponse ::= SEQUENCE { responseStatus OCSPResponseStatus, responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } OCSPResponseStatus ::= ENUMERATED { successful (0), --Response has valid confirmations malformedRequest (1), --Illegal confirmation request internalError (2), --Internal error in issuer tryLater (3), --Try again later --(4) is not used sigRequired (5), --Must sign the request unauthorized (6) --Request unauthorized } The value for responseBytes consists of an OBJECT IDENTIFIER and a response syntax identified by that OID encoded as an OCTET STRING. ResponseBytes ::= SEQUENCE { responseType OBJECT IDENTIFIER, response OCTET STRING } For a basic OCSP responder, responseType will be id-pkix-ocsp-basic. id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } OCSP responders SHALL be capable of producing responses of the id- pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL be capable of receiving and processing responses of the id-pkix-ocsp-basic response type. The value for response SHALL be the DER encoding of BasicOCSPResponse. BasicOCSPResponse ::= SEQUENCE { tbsResponseData ResponseData, signatureAlgorithm AlgorithmIdentifier, signature BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } The value for signature SHALL be computed on the hash of the DER encoding ResponseData. Denis Pinkas Expires February 22, 2013 [Page 15] INTERNET DRAFT PKIX OCSP August 23, 2012 If the responder is not a CA, it SHALL include OCSP certificates in the certs field of BasicOCSPResponse that allow the OCSP client verifying the responder's signature. If no certificates are included then certs SHOULD be absent. ResponseData ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, responderID ResponderID, producedAt GeneralizedTime, responses SEQUENCE OF SingleResponse, responseExtensions [1] EXPLICIT Extensions OPTIONAL } ResponderID ::= CHOICE { byName [1] Name, byKey [2] KeyHash } KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key (excluding the tag and length fields) SingleResponse ::= SEQUENCE { certID CertID, certStatus CertStatus, thisUpdate GeneralizedTime, nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, singleExtensions [1] EXPLICIT Extensions OPTIONAL } CertStatus ::= CHOICE { good [0] IMPLICIT NULL, revoked [1] IMPLICIT RevokedInfo, unknown [2] IMPLICIT UnknownInfo } RevokedInfo ::= SEQUENCE { revocationTime GeneralizedTime, revocationReason [0] EXPLICIT CRLReason OPTIONAL } UnknownInfo ::= NULL responderID indicates either the name or the key from a CA, or the name or the key from a OCSP Responder. producedAt indicates the time at which this response was signed. responses contains one or more single responses. responseExtensions is OPTIONAL. Any specific extension is OPTIONAL. The critical flag may or may not be set. certID is usually a copy of the same field which was placed in the request, but for OCSP responders which pre-produce signed responses certID may be the identifier of a target certificate that was not present in the request (see the end of section 4.2). Denis Pinkas Expires February 22, 2013 [Page 16] INTERNET DRAFT PKIX OCSP August 23, 2012 certStatus indicates the status of the certificate: either good, revoked or unknown. thisUpdate indicates the time at which the status being indicated is known to be correct. nextUpdate indicates the time at or before which newer information will be available about the status of the certificate. If nextUpdate is not set, the server is indicating that newer revocation information is available all the time. If nextUpdate is set, it often corresponds to the {thisUpdate, nextUpdate} interval in CRLs. Responses whose nextUpdate value is earlier than the local UTC time value SHOULD be considered unreliable. Responses whose thisUpdate time is later than the local UTC time SHOULD be considered unreliable. singleExtensions is OPTIONAL. Any specific extension is OPTIONAL. The critical flag SHOULD NOT be set for any of them. revocationTime indicates the time at which the certificate was revoked. revocationReason is OPTIONAL. It is defined in section 5.3.1 from RFC 5280 [RFC5280]. The response MUST include a SingleResponse for each certificate in the request and SHOULD NOT include any additional SingleResponse elements. There is however one exception: OCSP responders MAY pre-produce signed responses specifying the status of certificates at a specified time. The time at which the status was known to be correct SHALL be reflected in the thisUpdate field of the response. OCSP responders that pre-generate status responses MAY return responses that include additional SingleResponse elements if necessary to improve response pre-generation performance or cache efficiency (as permitted in [RFC5019]). 4.3. Response processing This section describes various processing algorithms. Conforming implementations of this specification are not required to implement these processing algorithms, but MUST provide functionality equivalent to the external behavior resulting from these algorithms. Any algorithm may be used by a particular implementation so long as it produces the correct result. Denis Pinkas Expires February 22, 2013 [Page 17] INTERNET DRAFT PKIX OCSP August 23, 2012 4.3.1. Response processing by OCSP servers The behavior of an OCSP server will be different whether the OCSP server is a CA acting as an OCSP responder or is an OCSP Responder which received a delegation from one or more CAs. 4.3.1.1. Processing by a CA acting as an OCSP responder The OCSP responder SHALL maintain a list of entries. Each entry SHALL contain: - the URI associated to the OCSP responder, from which the OCSP requests are received, - the DN from that CA, - an issuing public key from that CA, - the method(s) used to obtain the revocation status of the certificates issued under that CA issuing public key, and - the CA private key corresponding to the issuing public key. For a given URI value, the OCSP responder SHALL only use one CA key pair value. When it receives an OCSP request on that URI, the OCSP responder SHALL handle exceptions according to section 2.3. If the OCSP request contains the name of a requestor, the OCSP responder SHALL verify whether there exists a locally defined rule which regulates access control. If this rule exists, it SHALL be followed. Then, for each target certificate, the OCSP responder SHALL verify whether both the hash of the issuer's DN and the hash of the issuer public key which are present in the request are eligible to a locally defined rule which indicates that the OCSP responder is responsible to provide the revocation status of that target certificate. If this rule exists, it SHALL be followed. Otherwise, the OCSP responder SHALL determine whether it is responsible to provide the revocation status of that target certificate according to the following rule. For each target certificate, the OCSP responder SHALL verify whether both the hash of the issuer's DN and the hash of the issuer public key which are present in the request match respectively with the DN and the hash of the public key of contained in an entry from the list of entries maintained by this OCSP responder. When there is no match, then the OCSP responder SHALL indicate the "unknown" status and proceed with the next target certificate from the OCSP request. Denis Pinkas Expires February 22, 2013 [Page 18] INTERNET DRAFT PKIX OCSP August 23, 2012 When there is a match, then the OCSP responder SHALL use the serial number of the target certificate that is present in the request and determine the revocation status of that certificate according to the method(s) defined in the entry. When the revocation status is provided by the server using a real time access to a database of revocation statuses of issued certificates, then the thisUpdate field SHALL be present in the SingleResponse response whereas the nextUpdate field SHALL be missing. Otherwise, both the thisUpdate and the nextUpdate fields SHALL be present in the SingleResponse. The time at which this response will be signed MUST be indicated in the producedAt field from the SingleResponse. If a singleRequestExtensions is present in the request it MUST be processed. If there is another target certificate present in the request, it SHALL be processed in the same way. If a requestExtensions is present in the request it MUST be processed. The OCSP response MUST be signed using the CA issuing private key. The certs field SHOULD be kept empty. 4.3.1.2. Processing by an OCSP Responder For each CA from which it has received a delegation, the OCSP Responder SHALL maintain a list of entries. Each entry SHALL contain: - the URI associated to this OCSP Responder, from which the OCSP requests are received, - the DN from that CA, - an issuing public key from that CA, - the method(s) used to obtain the revocation status of the certificates issued under that CA issuing public key, and - an OCSP certificate, - the OCSP public key contained in that OCSP certificate, and - the method used to gain access and sign with OCSP private key corresponding to that OCSP certificate. For a given URI value, the OCSP Responder SHALL only use one OCSP key pair value. Therefore there cannot be two entries with the same URI value and a different OCSP public key value. Denis Pinkas Expires February 22, 2013 [Page 19] INTERNET DRAFT PKIX OCSP August 23, 2012 NOTE: a BasicOCSPResponse can only be signed using a single private key. The OCSP certificate SHALL be signed by the CA issuing private key which corresponds to the issuing CA public key that is in this entry, unless some specific rules are agreed between the OCSP Responder and OCSP clients. In that later case, the OCSP certificate MAY be signed by a different entity. When it receives an OCSP request, the OCSP responder SHALL handle exceptions according to section 2.3. If the OCSP request contains the name of a requestor, the OCSP responder SHALL verify whether there exists a locally defined rule which regulates access control. If this rule exists, it SHALL be followed. For each target certificate, the OCSP Responder SHALL verify whether both the hash of the issuer's DN and the hash of the issuer public key which are present in the OCSP request match with those from an entry. When there is no match, then the OCSP Responder SHALL indicate the "unknown" status and proceed with the next target certificate from the OCSP request. When there is a match, the OCSP Responder SHALL use the serial number of the target certificate this is present in the OCSP request to determine the revocation status of that certificate according to the method(s) indicated in the entry. When the revocation status is provided by the server using a real time access to a database of revocation statuses of issued certificates, then the thisUpdate field SHALL be present in the SingleResponse response whereas the nextUpdate field SHALL be missing. Otherwise, both the thisUpdate and the nextUpdate fields SHALL be present in the SingleResponse. The time at which this response will be signed MUST be indicated in the producedAt field from the SingleResponse. If a singleRequestExtensions is present in the request it MUST be processed. If there is another target certificate present in the request, it SHALL be processed in the same way. If a requestExtensions is present in the request it SHALL be processed. Denis Pinkas Expires February 22, 2013 [Page 20] INTERNET DRAFT PKIX OCSP August 23, 2012 The OCSP response MUST be signed using the OCSP private key. Unless there is a local rule which states differently, for every target certificate which matches both with the hash of a CA DN and an issuing public key from an entry, the OCSP certificate of that entry SHALL be placed in the certs field. It may happen, that none of the target certificates from the OCSP request matches both with the hash of a CA DN and an issuing public key from an entry. In that case and unless a local rule states differently, the certs field from the BasicOCSPResponse SHOULD be kept empty (to limit the disclose of the names of the CAs from which the OCSP Responder received a delegation from). 4.3.2. Response processing by an OCSP client OCSP responses can be verified at the current time by an OCSP client when receiving a response, whereas old responses can be verified at a time in the past by a verifier. The algorithm below addresses both cases. Prior to processing a basic response, OCSP clients MUST determine the checking time, which may be either the current time or a time in the past. If the checking time is the current time, and if a nonce has been used in the request (see section 4.5.1), OCSP clients MUST check whether the same nonce is present in the response. If the nonce is not present or is different, then the OCSP response MUST be discarded. Only the single response(s) which are/is of interest SHALL be checked. STEP 1 OCSP clients or verifiers SHALL verify that the certificate identified in a single response is of interest. Otherwise, proceed to step 3. If the certificate status included in a single certificate response is "unknown", then the revocation status of that certificate is "unknown", and proceed to step 3. If the certificate status from the single certificate response is either "good" or "revoked", OCSP clients or verifiers SHALL check that the checking time is within the validity period of the target certificate. If it is not the case, then the revocation status of that certificate is "unknown" and proceed to step 3. If the checking time is the current time, and if a nonce has been used in the request, then proceed to step 2. Denis Pinkas Expires February 22, 2013 [Page 20] INTERNET DRAFT PKIX OCSP August 23, 2012 If the checking time is the current time, and if no nonce has been used in the request, OCSP clients MUST check that the thisUpdate field is within a time window that is "close enough" to the current time. Note: the notion of "close enough" is a local matter. It can be set to a few minutes to allow for small UTC time differences between the client and the server or to a few hours in case the server is producing pre-computed responses. If the checking time is a time in the past, verifiers MUST check that the thisUpdate field is in accordance with the verification rules (e.g. close and/or after the date of a time-stamp token). In addition, if the nextUpdate field is present, OCSP clients MUST check that the time which is indicated is greater than the checking time, otherwise the single response MUST be discarded. If checks are successful, then OCSP clients MUST process the singleExtensions field, if it is present. If the criticality flag is set and the extension is not understood, then the status of the certificate shall be 'unknown'. Otherwise, proceed to step 2. Otherwise, the revocation status of that certificate is "unknown" and proceed to step 3. STEP 2 OCSP clients or verifiers MUST build and verify a certification path for that certificate up to a trusted root, so that they have the knowledge of the CA public key value that was used to sign the target certificate. The revocation status of each certificate of that certification path (except the target certificate) SHALL be checked. If no path can be built or if one of the certificates of the path is revoked, then the revocation status of that certificate is "unknown", and proceed to step 3. If the certification path (except the target certificate) is valid, then two cases need to be considered: a) If the responderID matches with the name or the key from the CA which has issued the target certificate, then check whether the response is signed by the same key that was used to sign the target certificate. If it is the case, then the revocation status of that certificate as indicated in the certStatus field is accepted and proceed to step 3. Denis Pinkas Expires February 22, 2013 [Page 21] INTERNET DRAFT PKIX OCSP August 23, 2012 If it is not the case, then the revocation status of that certificate is "unknown" and proceed to step 3. b) If the responderID does not match with the name or the key from the CA which has issued the target certificate, then it indicates the name or the key from an OCSP Responder. Check whether there exists a local rule which applies to this target certificate to verify that the signature of the BasicOCSPRespons is valid for that single response. If this rule exists, it SHALL be followed. Otherwise check whether there is an OCSP certificate (i.e. which has both the ocspSigning OID in the extended key usage extension and the digitalSignature bit in the key usage extension) signed by the same key that was used to sign the target certificate. This certificate MUST be present in the certs field from the BasicOCSPResponse. If such certificate is not found or is invalid, then the revocation status of that certificate is "unknown" and proceed to step 3. If such certificate exists and if the checking time is within the validity period of this certificate, then it MUST be verified that the authorized responder's certificate for that target certificate has not been revoked. CAs may choose to deal with this problem in one of three ways: - A CA may specify that an OCSP client can trust a responder for the lifetime of the responder's certificate. The CA does so by including the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical extension. The value of the extension should be NULL. CAs issuing such a certificate should realize that a compromise of the responder's key is as serious as the compromise of a CA key used to sign CRLs, at least for the validity period of this certificate. CA's may choose to issue this type of certificate with a very short lifetime and renew it frequently. id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } - A CA may specify how the responder's certificate be checked for revocation. This can be done using CRL Distribution Points if the check should be done using CRLs, or Authority Information Access if the check should be done in some other way. Details for specifying either of these two mechanisms are available in [RFC5280]. Denis Pinkas Expires February 22, 2013 [Page 22] INTERNET DRAFT PKIX OCSP August 23, 2012 - A CA may choose not to specify any method of revocation checking for the responder's certificate, in which case, it would be up to the OCSP client's local security policy to decide whether that certificate should be checked for revocation or not. If one of these conditions is met, then the status for the target certificate as indicated in the certStatus field is accepted, otherwise the revocation status is "unknown". STEP 3 If there exists another single certificate status response for a target certificate that is of interest, then proceed to step 1. Otherwise the basic response is now processed. 4.4. Mandatory and Optional Cryptographic Algorithms Clients that request OCSP services SHALL be capable of processing responses signed using RSA with SHA-1 (identified by sha1WithRSAEncryption OID specified in [RFC3279]) and RSA with SHA-256 (identified by sha256WithRSAEncryption OID specified in [RFC4055]). Clients SHOULD also be capable of processing responses signed using DSA keys (identified by the id-dsa-with-sha1 OID specified in [RFC3279]). Clients MAY support other algorithms. 4.5. Extensions This section defines some standard extensions, based on the extension model employed in X.509 version 3 certificates see [RFC5280]. Support for all extensions is optional for both clients and responders. For each extension, the definition indicates its syntax, processing performed by the OCSP Responder, and any extensions which are included in the corresponding response. 4.5.1. Nonce The nonce cryptographically binds a request and a response to prevent replay attacks. The nonce is included as one of the requestExtensions in requests, while in responses it would be included as one of the responseExtensions. In both the request and the response, the nonce will be identified by the object identifier id-pkix-ocsp-nonce, while the extnValue is the value of the nonce. id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } Nonce ::= OCTET STRING Denis Pinkas Expires February 22, 2013 [Page 23] INTERNET DRAFT PKIX OCSP August 23, 2012 4.5.2. CRL References It may be desirable for the OCSP responder to indicate the CRL on which a revoked or onHold certificate is found. This can be useful where OCSP is used between repositories, and also as an auditing mechanism. The CRL may be specified by a URL (the URL at which the CRL is available), a number (CRL number) or a time (the time at which the relevant CRL was created). These extensions will be specified as singleExtensions. The identifier for this extension will be id-pkix-ocsp-crl, while the value will be CrlID. id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } CrlID ::= SEQUENCE { crlUrl [0] EXPLICIT IA5String OPTIONAL, crlNum [1] EXPLICIT INTEGER OPTIONAL, crlTime [2] EXPLICIT GeneralizedTime OPTIONAL } For the choice crlUrl, the IA5String will specify the URL at which the CRL is available. For crlNum, the INTEGER will specify the value of the CRL number extension of the relevant CRL. For crlTime, the GeneralizedTime will indicate the time at which the relevant CRL was issued. 4.5.3 Acceptable Response Types An OCSP client MAY wish to specify the kinds of response types it understands. To do so, it SHOULD use an extension with the OID id-pkix-ocsp-response, and the value AcceptableResponses. This extension is included as one of the requestExtensions in requests. The OIDs included in AcceptableResponses are the OIDs of the various response types this client can accept (e.g., id-pkix-ocsp-basic). id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 } AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER As noted in section 4.2.1, OCSP responders SHALL be capable of responding with responses of the id-pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL be capable of receiving and processing responses of the id-pkix-ocsp-basic response type. 4.5.4 Archive Cutoff An OCSP responder MAY choose to retain revocation information beyond a certificate's expiration. The date obtained by subtracting this retention interval value from the producedAt time in a response is defined as the certificate's "archive cutoff" date. Denis Pinkas Expires February 22, 2013 [Page 24] INTERNET DRAFT PKIX OCSP August 23, 2012 OCSP-enabled applications would use an OCSP archive cutoff date to contribute to a proof that a digital signature was (or was not) reliable on the date it was produced even if the certificate needed to validate the signature has long since expired. OCSP servers that provide support for such historical reference SHOULD include an archive cutoff date extension in responses. If included, this value SHALL be provided as an OCSP singleExtensions extension identified by id-pkix-ocsp-archive-cutoff and of syntax GeneralizedTime. id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 } ArchiveCutoff ::= GeneralizedTime To illustrate, if a server is operated with a 7-year retention interval policy and status was produced at time t1 then the value for ArchiveCutoff in the response would be (t1 - 7 years). 4.5.5. CRL Entry Extensions All the extensions specified as CRL Entry Extensions - in Section 5.3 of [RFC5280] - are also supported as singleExtensions. 4.5.6. Service Locator An OCSP server may be operated in a mode whereby the server receives a request and routes it to the OCSP server which is known to be authoritative for the identified certificate. The serviceLocator request extension is defined for this purpose. This extension is included as one of the singleRequestExtensions in requests. id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 } ServiceLocator ::= SEQUENCE { issuer Name, locator AuthorityInfoAccessSyntax OPTIONAL } Values for these fields are obtained from the corresponding fields in the subject certificate. 4.5.7. Preferred Signature Algorithms Since algorithms other than the mandatory to implement algorithms are allowed, and since a client currently has no mechanism to indicate it's algorithm preferences, there is always a risk that a server choosing a non-mandatory algorithm, will generate a response that the client may not support. Denis Pinkas Expires February 22, 2013 [Page 26] INTERNET DRAFT PKIX OCSP August 23, 2012 While an OCSP responder may apply rules for algorithm selection, e.g., using the signature algorithm employed by the CA for signing CRLs and certificates, such rules may fail in common situations: o The algorithm used to sign the CRLs and certificates may not be consistent with key pair being used by the OCSP responder to sign responses. o A request for an unknown certificate provides no basis for a responder to select from among multiple algorithm options. The last criterion cannot be resolved through the information available from in-band signaling using the RFC 2560 [RFC2560] protocol, without modifying the protocol. In addition, an OCSP responder may wish to employ different signature algorithms than the one used by the CA to sign certificates and CRLs for several reasons: o The responder may employ an algorithm for certificate status response that is less computationally demanding than for signing the certificate itself. o An implementation may wish to guard against the possibility of a compromise resulting from a signature algorithm compromise by employing two separate signature algorithms. This section describes: o An extension that allows a client to indicate the set of preferred signature algorithms. o Rules for signature algorithm selection that maximizes the probability of successful operation in the case that no supported preferred algorithm(s) are specified. 4.5.7.1. Extension Syntax A client MAY declare a preferred set of algorithms in a request by including a preferred signature algorithms extension in requestExtensions of the OCSPRequest. id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 } PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm PreferredSignatureAlgorithm ::= SEQUENCE { sigIdentifier AlgorithmIdentifier, pubKeyAlgIdentifier SMIMECapability OPTIONAL } Denis Pinkas Expires February 22, 2013 [Page 27] INTERNET DRAFT PKIX OCSP August 23, 2012 The syntax of AlgorithmIdentifier is defined in section 4.1.1.2 of RFC 5280 [RFC5280]. The syntax of SMIMECapability is defined in RFC 5751 [RFC5751] sigIdentifier specifies the signature algorithm the client prefers, e.g. algorithm=ecdsa-with-sha256. Parameters are absent for most common signature algorithms. pubKeyAlgIdentifier specifies the subject public key algorithm identifier the client prefers in the server's certificate used to validate the OCSP response. e.g. algorithm=id-ecPublicKey and parameters= secp256r1. pubKeyAlgIdentifier is OPTIONAL and provides means to specify parameters necessary to distinguish among different usages of a particular algorithm, e.g. it may be used by the client to specify what curve it supports for a given elliptic curve algorithm. The client MUST support each of the specified preferred signature algorithms and the client MUST specify the algorithms in the order of preference, from the most preferred to the least preferred. Section 4.4.7.1 of this document describes how a server selects an algorithm for signing OCSP responses to the requesting client. 4.5.7.2. Responder Signature Algorithm Selection RFC 2560 [RFC2560] did not specify a mechanism for deciding the signature algorithm to be used in an OCSP response. This does not provide a sufficient degree of certainty as to the algorithm selected to facilitate interoperability. 4.5.7.2.1. Dynamic Response A responder MAY maximize the potential for ensuring interoperability by selecting a supported signature algorithm using the following order of precedence, as long as the selected algorithm meets all security requirements of the OCSP responder, where the first method has the highest precedence: 1. Select an algorithm specified as a preferred signing algorithm in the client request. 2. Select the signing algorithm used to sign a certificate revocation list (CRL) issued by the certificate issuer providing status information for the certificate specified by CertID. 3. Select the signing algorithm used to sign the OCSPRequest. Denis Pinkas Expires February 22, 2013 [Page 28] INTERNET DRAFT PKIX OCSP August 23, 2012 4. Select a signature algorithm that has been advertised as being the default signature algorithm for the signing service using an out of band mechanism. 5. Select a mandatory or recommended signing algorithm specified for the version of the OCSP protocol in use. A responder SHOULD always apply the lowest numbered selection mechanism that results in the selection of a known and supported algorithm that meets the responder's criteria for cryptographic algorithm strength. 4.5.7.2.2. Static Response For purposes of efficiency, an OCSP responder is permitted to generate static responses in advance of a request. The case may not permit the responder to make use of the client request data during the response generation, however the responder SHOULD still use the client request data during the selection of the pre-generated response to be returned. Responders MAY use the historical client requests as part of the input to the decisions of what different algorithms should be used to sign the pre-generated responses. 5. Security Considerations 5.1. Denial of service attack using false error responses Unsigned error responses open up the protocol to another denial of service attack, where the attacker sends false error responses. 5.2. Using CRLs as a fall-back mechanism For this service to be effective, certificate-using systems must connect to the certificate status service provider. In the event such a connection cannot be obtained, certificate-using systems could implement CRL processing logic as a fall-back position. 5.3. Different results when using OCSP and CRLs OCSP clients or verifiers must build and verify a certification path for each target certificate up to a trusted root. When an OCSP Responder is using published CRLs, it must also build and verify a certification path for the CRLs it uses up to a trusted root. However, it should be realized that the root used by an OCSP Responder to verified these CRLs is not necessarily the same as the one that would be used by the OCSP client if it were going to verify the CRLs itself. Hence the revocation status may not be identical in both cases. Denis Pinkas Expires February 22, 2013 [Page 29] INTERNET DRAFT PKIX OCSP August 23, 2012 5.4. Denial of service attack using a flood of queries A denial of service vulnerability is evident with respect to a flood of queries. The production of a cryptographic signature significantly affects response generation cycle time, thereby exacerbating the situation. The flood of queries may either come from a flood attack or from the fact that there are too many certificates supported by the same OCSP responder. In the later case, the number of queries can be diminished by using a technique similar to the splitting of CRLs: When a block of certificates have been issued with the same accessLocation in the AIA extension field of these certificates, then the accessLocation should be changed. In this way, a given OCSP server will only serve one block of certificates. 5.5. Use of precomputed responses The use of precomputed responses allows replay attacks in which an old (good) response is replayed prior to its expiration date but after the certificate has been revoked. Deployments of OCSP should carefully evaluate the benefit of precomputed responses against the probability of a replay attack and the costs associated with its successful execution. Requests do not contain the responder they are directed to. This allows an attacker to replay a request to any number of OCSP responders. The reliance of HTTP caching in some deployment scenarios may result in unexpected results if intermediate servers are incorrectly configured or are known to possess cache management faults. Implementors are advised to take the reliability of HTTP cache mechanisms into account when deploying OCSP over HTTP. 5.6. Preferred Signature Algorithms The mechanism used to choose the response signing algorithm MUST be considered to be sufficiently secure against cryptanalytic attack for the intended application. In most applications it is sufficient for the signing algorithm to be at least as secure as the signing algorithm used to sign the original certificate whose status is being queried. This criterion may not hold in long term archival applications however in which the status of a certificate is being checked for a date in the distant past, long after the signing algorithm has ceased being considered trustworthy. Denis Pinkas Expires February 22, 2013 [Page 30] INTERNET DRAFT PKIX OCSP August 23, 2012 5.6.1. Use of insecure algorithms It is not always possible for a responder to generate a response that the client is expected to understand and that meets contemporary standards for cryptographic security. In such cases an OCSP responder operator MUST balance the risk of employing a compromised security solution and the cost of mandating an upgrade, including the risk that the alternative chosen by end users will offer even less security or no security. In archival applications it is quite possible that an OCSP responder might be asked to report the validity of a certificate on a date in the distant past. Such a certificate might employ a signing method that is no longer considered acceptably secure. In such circumstances either the responder SHOULD NOT generate a signature using a signing mechanism that is not considered acceptably secure or SHOULD time-stamp the OCSP response. A client MUST accept any signing algorithm in a response that it specified as a preferred signing algorithm in the request. It follows therefore that a client MUST NOT specify as a preferred signing algorithm any algorithm that is either not supported or not considered acceptably secure. 5.6.2. Man in the Middle Downgrade Attack The mechanism to support client indication of preferred signature algorithms is not protected against a man in the middle downgrade attack. This constraint is not considered to be a significant security concern since the OCSP responder MUST NOT sign OCSP Responses using weak algorithms, even if requested by the client. In addition, the client can reject OCSP responses that do not meet its own criteria for acceptable cryptographic security no matter what mechanism is used to determine the signing algorithm of the response. 5.6.3. Denial of Service Attack using the algorithm agility mechanisms Algorithm agility mechanisms defined in this document introduces a slightly increased attack surface for Denial-of-Service attacks where the client request is altered to require algorithms that are not supported by the server. Denial-of-Service considerations from RFC 4732 [RFC4732] are relevant for this document. 6. IANA Considerations Appendix C (MIME registrations) already contains the information which is necessary for this RFC. No further action is necessary. Denis Pinkas Expires February 22, 2013 [Page 31] INTERNET DRAFT PKIX OCSP August 23, 2012 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002. [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. [RFC6277] Santesson, S. and P. Hallam-Baker, "Online Certificate Status Protocol Algorithm Agility", RFC 6277, June 2011. [X.690] ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995, Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). 7.2. Informative References [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC4732] Handley, M., Rescorla, E., "Internet Denial-of-Service Considerations" RFC 4732, November 2006. Denis Pinkas Expires February 22, 2013 [Page 32] INTERNET DRAFT PKIX OCSP August 23, 2012 [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments", RFC 5019, September 2007. [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010. 8. Acknowledgements This document is based on RFC 2560 for which the authors were M. Myers, R. Ankney, A. Malpani and S. Galperin. It capitalizes on an original draft from S. Santesson. The initial draft of this document has been reviewed and commented by D. Rouger, R. Santini and B. Sevellec. Denis Pinkas Expires February 22, 2013 [Page 33] INTERNET DRAFT PKIX OCSP August 23, 2012 Appendix A. A.1 OCSP over HTTP This section describes the formatting that will be done to the request and response to support HTTP [RFC2616]. A.1.1 Request HTTP based OCSP requests can use either the GET or the POST method to submit their requests. To enable HTTP caching, small requests (that after encoding are less than 255 bytes), MAY be submitted using GET. If HTTP caching is not important, or the request is greater than 255 bytes, the request SHOULD be submitted using POST. Where privacy is a requirement, OCSP transactions exchanged using HTTP MAY be protected using either TLS/SSL or some other lower layer protocol. An OCSP request using the GET method is constructed as follows: GET {url}/{url-encoding of base-64 encoding of the DER encoding of the OCSPRequest} where {url} may be derived from the value of AuthorityInfoAccess or other local configuration of the OCSP client. An OCSP request using the POST method is constructed as follows: The Content-Type header has the value "application/ocsp-request" while the body of the message is the binary value of the DER encoding of the OCSPRequest. A.1.2 Response An HTTP-based OCSP response is composed of the appropriate HTTP headers, followed by the binary value of the DER encoding of the OCSPResponse. The Content-Type header has the value "application/ocsp-response". The Content-Length header SHOULD specify the length of the response. Other HTTP headers MAY be present and MAY be ignored if not understood by the requestor. Denis Pinkas Expires February 22, 2013 [Page 34] INTERNET DRAFT PKIX OCSP August 23, 2012 Appendix B. ASN.1 Modules This appendix includes the ASN.1 modules for OCSP. Appendix C.1 includes an ASN.1 module that conforms to the 1998 version of ASN.1 for all syntax elements of OCSP other than the preferred signature algorithms extension. An alternative to this module that conforms to the 2002 version of ASN.1 my be found in Section 4 of [RFC5912]. Appendix C.2 includes two ASN.1 modules for the preferred signature algorithms extension, one that conforms to the 1998 version of ASN.1 and one that conforms to the 2002 version of ASN.1. B.1. OCSP in ASN.1 OCSP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)} DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS -- PKIX Certificate Extensions AuthorityInfoAccessSyntax, CRLReason, GeneralName FROM PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) } Name, CertificateSerialNumber, Extensions, id-kp, id-ad-ocsp, Certificate, AlgorithmIdentifier FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) }; OCSPRequest ::= SEQUENCE { tbsRequest TBSRequest, optionalSignature [0] EXPLICIT Signature OPTIONAL } TBSRequest ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, requestorName [1] EXPLICIT GeneralName OPTIONAL, requestList SEQUENCE OF Request, requestExtensions [2] EXPLICIT Extensions OPTIONAL } Signature ::= SEQUENCE { signatureAlgorithm AlgorithmIdentifier, signature BIT STRING, Denis Pinkas Expires February 22, 2013 [Page 35] INTERNET DRAFT PKIX OCSP August 23, 2012 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } Version ::= INTEGER { v1(0) } Request ::= SEQUENCE { reqCert CertID, singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } CertID ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, -- Hash of Issuer's DN issuerKeyHash OCTET STRING, -- Hash of Issuers public key serialNumber CertificateSerialNumber } OCSPResponse ::= SEQUENCE { responseStatus OCSPResponseStatus, responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } OCSPResponseStatus ::= ENUMERATED { successful (0), -- Response has valid confirmations malformedRequest (1), -- Illegal confirmation request internalError (2), -- Internal error in issuer tryLater (3), -- Try again later -- (4) is not used sigRequired (5), -- Must sign the request unauthorized (6) -- Request unauthorized } ResponseBytes ::= SEQUENCE { responseType OBJECT IDENTIFIER, response OCTET STRING } BasicOCSPResponse ::= SEQUENCE { tbsResponseData ResponseData, signatureAlgorithm AlgorithmIdentifier, signature BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } ResponseData ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, responderID ResponderID, producedAt GeneralizedTime, responses SEQUENCE OF SingleResponse, responseExtensions [1] EXPLICIT Extensions OPTIONAL } ResponderID ::= CHOICE { byName [1] Name, byKey [2] KeyHash } Denis Pinkas Expires February 22, 2013 [Page 36] INTERNET DRAFT PKIX OCSP August 23, 2012 KeyHash ::= OCTET STRING --SHA-1 hash of responder's public key -- (i.e., the SHA-1 hash of the value of the -- BIT STRING subjectPublicKey [excluding -- the tag, length, and number of unused -- bits] in the responder's certificate) SingleResponse ::= SEQUENCE { certID CertID, certStatus CertStatus, thisUpdate GeneralizedTime, nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, singleExtensions [1] EXPLICIT Extensions OPTIONAL } CertStatus ::= CHOICE { good [0] IMPLICIT NULL, revoked [1] IMPLICIT RevokedInfo, unknown [2] IMPLICIT UnknownInfo } RevokedInfo ::= SEQUENCE { revocationTime GeneralizedTime, revocationReason [0] EXPLICIT CRLReason OPTIONAL } UnknownInfo ::= NULL ArchiveCutoff ::= GeneralizedTime AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER ServiceLocator ::= SEQUENCE { issuer Name, locator AuthorityInfoAccessSyntax } -- Object Identifiers id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 } id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 } id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 } END Denis Pinkas Expires February 22, 2013 [Page 37] INTERNET DRAFT PKIX OCSP August 23, 2012 B.2. Preferred Signature Algorithms ASN.1 B.2.1. ASN.1 Module OCSP-AGILITY-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-agility-2009-93(66) } DEFINITIONS EXPLICIT TAGS ::= BEGIN EXPORTS ALL; -- export all items from this module IMPORTS id-pkix-ocsp FROM OCSP-2009 -- From [RFC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-02(48) } AlgorithmIdentifier{}, SIGNATURE-ALGORITHM, PUBLIC-KEY FROM AlgorithmInformation-2009 -- From [RFC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } EXTENSION FROM PKIX-CommonTypes-2009 -- From [RFC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} ; -- Add re-preferred-signature-algorithms to the set of extensions -- for TBSRequest.requestExtensions re-preferred-signature-algorithms EXTENSION ::= { SYNTAX PreferredSignatureAlgorithms IDENTIFIED BY id-pkix-ocsp-pref-sig-algs } id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 } PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm PreferredSignatureAlgorithm ::= SEQUENCE { sigIdentifier AlgorithmIdentifier{SIGNATURE-ALGORITHM, {...}}, certIdentifier AlgorithmIdentifier{PUBLIC-KEY, {...}} OPTIONAL } END Denis Pinkas Expires February 22, 2013 [Page 38] INTERNET DRAFT PKIX OCSP August 23, 2012 B.2.2. 1988 ASN.1 Module OCSP-AGILITY-88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-agility-2009-88(67) } DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL; IMPORTS id-pkix-ocsp FROM OCSP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)} AlgorithmIdentifier FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) }; id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 } PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm PreferredSignatureAlgorithm ::= SEQUENCE { sigIdentifier AlgorithmIdentifier, certIdentifier AlgorithmIdentifier OPTIONAL } END Denis Pinkas Expires February 22, 2013 [Page 39] INTERNET DRAFT PKIX OCSP August 23, 2012 Appendix C. MIME registrations C.1 application/ocsp-request To: ietf-types@iana.org Subject: Registration of MIME media type application/ocsp-request MIME media type name: application MIME subtype name: ocsp-request Required parameters: None Optional parameters: None Encoding considerations: binary Security considerations: Carries a request for information. This request may optionally be cryptographically signed. Interoperability considerations: None Published specification: IETF PKIX Working Group Draft on Online Certificate Status Protocol - OCSP Applications which use this media type: OCSP clients Additional information: Magic number(s): None File extension(s): .ORQ Macintosh File Type Code(s): none Person & email address to contact for further information: Ambarish Malpani Intended usage: COMMON Author/Change controller: Ambarish Malpani C.2. application/ocsp-response To: ietf-types@iana.org Subject: Registration of MIME media type application/ocsp-response MIME media type name: application MIME subtype name: ocsp-response Required parameters: None Denis Pinkas Expires February 22, 2013 [Page 40] INTERNET DRAFT PKIX OCSP August 23, 2012 Optional parameters: None Encoding considerations: binary Security considerations: Carries a cryptographically signed response Interoperability considerations: None Published specification: IETF PKIX Working Group Draft on Online Certificate Status Protocol - OCSP Applications which use this media type: OCSP servers Additional information: Magic number(s): None File extension(s): .ORS Macintosh File Type Code(s): none Person & email address to contact for further information: Ambarish Malpani Intended usage: COMMON Author/Change controller: Ambarish Malpani Authors' Address Denis Pinkas Bull SAS BP 78 78340 Les Clayes sous bois France EMail: denis.pinkas@bull.net Denis Pinkas Expires February 22, 2013 [Page 41]