Internet Draft Michael Myers draft-myers-pkix-ocsp-core-00.txt TraceRoute Security December, 2002 Expires in six months Online Certificate Status Protocol Core draft-myers-pkix-ocsp-core-00.txt Status of this memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document expands the core syntax of [RFC2560] in support of additional means to identify a certificate in the Online Certificate Status Protocol (OCSP). It improves the integration of OCSP with other IETF protocols that involve X.509-based public key and attribute certificates while preserving interoperability with existing OCSP implementations. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119]. 3. Overview [RFC2560] defines OCSP as a online request-response PKI information acquisition protocol composed of a generic envelope and a set of standardized request and response types. An OCSP request message contains a protocol version number, a request type object identifier (OID) and request data relevant to a particular request type. Requests may be digitally signed. Responses are correspondingly structured as an OID and associated response data. Responses may or may not be digitally signed depending on service request type or error processing. Myers [Page 1] Internet Draft OCSP Core December 2002 This document extends the framework by which OCSP services are to requested and received. It does not define any specific service or extension. Services and extensions are defined in . 4. Requirements All OCSP requests and responses SHALL conform to this section. Service definitions MAY extend these requirements. 4.1 Request Syntax Requests SHALL include the following content: 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 } Version ::= INTEGER { v1(0), v2(1) } A requestExtensions field SHALL only be included if the requestExtensions field contains one or more values, else the field SHALL be omitted from the tbsRequest field of OCSPRequest. 4.2 Service Identification The revocation checking service established by [RFC2560] is referred to in this document as the Online Revocation Service (ORS). Except for ORS, all other OCSP service request types SHALL be identified by an OID in requestExtensions. To determine if a request is or is not an ORS request, servers SHALL implement logic equivalent to the following: a. Upon receipt of a OCSP request, determine if the requestExtensions field is present. b. If the requestExtensions field is absent, the request SHALL be considered an ORS request. c. If the requestExtensions field contains one or more OIDs, then if any one of those values matches the ORS OID defined in , the request SHALL be considered an ORS request. 4.3 Certificate Identification The ReqCert structure enables OCSP clients to identify a certificate using means most suitable to their environment. Myers [Page 2] Internet Draft OCSP Core December 2002 Request ::= SEQUENCE { reqCert ReqCert, singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } ReqCert ::= CHOICE { certID CertID, issuerSerial [0] IssuerAndSerialNumber, fullCert [1] FullCertificate, certIdWithSignature [2] CertIdWithSignature } FullCertificate ::= CHOICE { certificate [0] Certificate, attributeCert [1] AttributeCertificate } If certID is used in ReqCert, the value for version SHALL be v1. If any other choice in ReqCert is used, the value for version SHALL be v2. Clients SHALL support either the issuerSerial OR fullCert. Servers SHALL be capable of responding to all options of ReqCert. CertID ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, -- Hash of Issuer's DN issuerKeyHash OCTET STRING, -- Hash of Issuers public key serialNumber CertificateSerialNumber } The value for issuerNameHash SHALL be calculated over the DER encoding of the issuer's name field in the certificate being checked. The value for issuerKeyHash SHALL be calculated over the value of the BIT STRING subjectPublicKey key field (excluding tag and length) 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. CertIdWithSignature ::= SEQUENCE { issuerSerial IssuerAndSerialNumber, tbsCertificateHash BIT STRING, certSignature CertSignature } CertSignature ::= SEQUENCE { signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } tbsCertificateHash SHALL be a hash value computed over the ASN.1 DER encoded tbsCertificate field from the certificate using the hash function identified in the signature algorithm from the signature. certSignature contains the signature fields from the certificate. Myers [Page 3] Internet Draft OCSP Core December 2002 4.4 Signed Requests Service definitions MAY require the use of digital signatures over requests. When required, signed requests SHALL be produced as follows: Signature ::= SEQUENCE { signatureAlgorithm AlgorithmIdentifier, signature BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL} Signed requests SHALL identify the requestor in the requestorName field of TBSRequest and MAY include the certs field of the Signature element. 4.5 Response Envelope Responses SHALL contain a responseStatus field. A value for the responseBytes field SHALL be included if the value for responseStatus is successful. A value for the responseBytes field MAY be included for responseStatus values other than successful. The responseBytes field SHALL be composed of an OID identifying the response type and the bytes of the actual response encoded as an OCTET STRING. OCSPResponse ::= SEQUENCE { responseStatus OCSPResponseStatus, responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } OCSPResponseStatus ::= ENUMERATED { successful (0), malformedRequest (1), internalError (2), tryLater (3), --(4) is not used for legacy reasons sigRequired (5), unauthorized (6) } ResponseBytes ::= SEQUENCE { responseType OBJECT IDENTIFIER, response OCTET STRING } 4.6 Certificate Content Certificate-producing entities SHALL be capable of including the AuthorityInfoAccess extension defined in [RFC3280]. Alternatively, the accessLocation for the OCSP provider MAY be configured locally at the client. Certificate-producing entities SHALL be capable of providing 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 responder and may contain other transport dependent information (e.g. a URL). Myers [Page 4] Internet Draft OCSP Core December 2002 4.7 Authorized Responders The key that signs a certificate's status information need not be the same key that signed the certificate. It is necessary however to ensure that the entity signing this information is authorized to do so. Therefore, a certificate's issuer SHALL either: a. sign the OCSPresponses itself using a private key under the control of the issuer; or b. explicitly delegate this authority to another entity. OCSP signing delegation SHALL be designated 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 that issued the certificate in question. Explicit delegation of OCSP signing authority SHALL be indicated by inclusion of the following value in the extendedKeyUsage extension of certificate needed to validate an OCSP response signature produced by such an entity: id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9} Systems or applications that rely on OCSP responses SHALL 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. They SHALL reject the response if the certificate required to validate the signature on the response fails to meet at least one of the following criteria: a. Matches a local configuration of OCSP signing authority for the certificate in question; b. is a certificate corresponding to a private key under control of the CA that issued the certificate in question; or c. includes a value of id-ad-ocspSigning in an ExtendedKeyUsage extension and is issued by the CA that issued the certificate. Additional acceptance or rejection criteria may apply to either the response itself or to the certificate used to validate the signature on the response. Since an Authorized Responder provides status information for one or more CAs, OCSP clients need to know how to validate an Authorized Responder's certificate. CAs may choose to deal with this problem in one of three ways: - A CA may specify that an OCSP client can trust an Authorized 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. Myers [Page 5] Internet Draft OCSP Core December 2002 The value of the extension is NULL. CAs issuing such a certificate should realize that a compromise of the Authorized 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. CAs 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 is to be checked for revocation. This can be done using CRL Distribution Points if the check should be done using CRLs or CRL Distribution Points, 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 [RFC3280]. - A CA may choose not to specify any method of checking 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. 4.8 Use of ASN.1 Syntax The ASN.1 syntax used in this document imports terms defined in [RFC3280] and [RFC2630]. 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 and IssuerAndSerialNumber. 4.9 Application to Attribute Certificates OCSP MAY be used without modification to provide status on attribute certificates (ACs) conforming to [ACPROF]. Note that since [ACPROF], section 4.2.3, mandates that the issuer field uses a single X.500 name to identify the AC issuer, and also ([ACPROF], section 4.5) mandates that an AC issuer cannot also be a PKC issuer (at least using the same name/key), there are no syntactic changes required to support ACs. An OCSP responder that only supports PKCs will treat a request for status on an AC in the same way as it would treat a request for an issuer/serial combination for which it had no information. That is, a conforming OCSP responder need not have any specific ability to handle ACs. 4.10 Mandatory and Optional Cryptographic Algorithms Clients and servers SHALL support the RSA signature algorithm in accordance with RFC 2437 [RFC2437] and the SHA1 hashing algorithm as defined in FIPS Pub 180-1 [SHA1]. DSA signature support MAY be provided. If provided, this algorithm SHALL be implemented in accordance with FIPS Pub 186 [DSS]. Myers [Page 6] Internet Draft OCSP Core December 2002 5. OCSP over HTTP This section describes the formatting that SHALL be used when HTTP is used to transport OCSP. 5.1 Request HTTP based OCSP requests MAY use either the GET or the POST method. 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}. {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. 5.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. 6. MIME registrations 6.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 Myers [Page 7] Internet Draft OCSP Core December 2002 Published specification: RFC 2560 - 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 ambarish@malpani.biz Intended usage: COMMON Author/Change controller: Ambarish Malpani 6.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 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 ambarish@malpani.biz Myers [Page 8] Internet Draft OCSP Core December 2002 7. Acknowledgments I am deeply indebted to the conversations I had with our colleague Rich Ankney in the formative stages of RFC 2560. Carlisle Adams, Stephen Farrell and Carlin Covey continue to provide superior technical advice and wise counsel. OCSP would not be the RFC it is today without the technical analysis and contributions of Ambarish Malpani. No PKI solution should be considered complete without the review and comment of Denis Pinkas. And special thanks to Peter Gutman. He actually writes code according to our rough consensus. A tough job, that. 8. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2437] Kaliski, B., "PKCS #1: RSA Encryption, Version 2.0", RFC 2437, October 1998. [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., Adams, C., "Online Certificate Status Protocol -- OCSP", RFC 2560, June 1999. [RFC3280] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, April 2002. [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). [ACPROF] Farrell, S., Housley, R., "An Internet Attribute Certificate Profile for Authorization", Internet Draft draft-ietf-pkix- ac509prof-xx.txt (work in progress). [SHA1] National Institute of Standards and Technology. FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. [DSS] National Institute of Standards and Technology. FIPS Pub 186: Digital Signature Standard. 19 May 1994. 9. Author Address Michael Myers TraceRoute Security, Inc. myers@coastside.net or mmyers@fastq.com +602.739.7744 10. OCSP over ASN.1 [TBSL] Myers [Page 9]