PKIX Working Group M. Pala Internet-Draft Polythecnic Institute of NYU Intended status: Standards Track S. Rea Expires: January 10, 2013 DigiCert, Inc July 9, 2012 OCSP over DNS draft-pala-rea-ocsp-over-dns-00 Abstract One of the most strategic problems for Internet Certification Authorities (ICAs) is the provisioning of revocation information in an efficient way. Current approaches for the distribution of OCSP responses over HTTP do not provide efficient solutions for the high volume of traffic that Internet CAs face when providing services for highly utilized websites. This document describes a new transport protocol for OCSP responses to efficiently provide revocation information about digital certificates. In particular, this specification defines how to distribute OCSP responses over DNS and how to define OCSP-over-DNS URLs in certificates. The use of the DNS system to distribute such information is meant to lower the costs of providing revocation services and increase the availability of revocation information by using the distributed nature of the DNS infrastructure. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 10, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the Pala & Rea Expires January 10, 2013 [Page 1] Internet-Draft OOD July 2012 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. 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. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 3 4. OCSP-Related DNS URLs in Certificates . . . . . . . . . . . . . 4 4.1. URL Definition . . . . . . . . . . . . . . . . . . . . . . 4 4.2. URL Processing . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. Time Validity . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Pala & Rea Expires January 10, 2013 [Page 2] Internet-Draft OOD July 2012 1. Requirements notation 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 [RFC2119]. 2. Introduction With the increasing number of highly available and highly utilized websites that require secure communications to protect the flow of information from the server to the client, the need for a low-cost efficient approach to revocation information availability is crucial. The OCSP-over-DNS approach allows clients to determine the status of digital certificates specifically for high-traffic Internet secure servers (i.e., SSL/TLS) by optimizing the delivery mechanism for revocation information distribution to the client. This transport protocol can be used in lieu of or in addition to other PKIX endorsed transport mechanisms such as HTTP. This specification addresses the problem of providing a low-latency highly-available distributed system for OCSP responses availability. In particular, OCSP-over-DNS is meant to be used in conjunction with pre-computed OCSP responses. This document defines the DNS records to be used for OCSP data publication and the definition of additional URLs for the AuthorityInfoAccess (AIA) extension in certificates. 3. Protocol Overview In order to validate a certificate using OCSP-over-DNS, the client should check the certificate for a DNS-based OCSP base URI, construct the URI for the specific certificate, and then retrieve the OCSP response from the DNS. After this point, all procedures are to be performed according to the OCSP protocol as defined in [RFC5019]. In particular, clients using OCSP-over-DNS, SHOULD: 1. Lookup the OCSP URI provided in the AIA of the certificate to be checked. The format of the URI comprises the id-ad-ocsp identifier and a base URL where the scheme is dns://. The format of the full URI is discussed in the next section. 2. Build the OCSP query for the certificate to be checked. This is done by pre-pending the hex representation of the digest of the certificate to the base domain provided in the OCSP DNS URI. 3. Retrieve the DNS record carrying the required OCSP response. The Client SHOULD retrieve the revocation information directly Pala & Rea Expires January 10, 2013 [Page 3] Internet-Draft OOD July 2012 through the DNS system. The distributed nature of DNS will allow for automatic load distribution. References to the suggested configurations for the transport and distribution protocols and servers is provided in the Appendix of this document. 4. OCSP-Related DNS URLs in Certificates As described in [RFC2560], in order to convey to OCSP clients a well- known point of information access, CAs SHALL provide the capability to include the AuthorityInfoAccess extension in certificates that can be checked using OCSP. In addition to the HTTP transport protocol defined in [RFC2560], this document defines an additional transport protocol for OCSP Responses, i.e. DNS records. This transport mechanism is useful only in environments where OCSP responses are pre-computed (common in Internet CAs). The accessMethod in the AccessDescription SEQUENCE of the URI should use id-ad-ocsp as its value as usual. However, if DNS records are used for distributing pre-computed OCSP responses [RFC5019], the value of the accessLocation field in the subject certificate SHOULD define 'dns' or 'dnssec' as the transport used to access the OCSP response data. Additionally the URL can optionally contain parameters to specify the digest algorithms to be used by clients to calculate the DNS query. The default digest algoritm is "SHA256". 4.1. URL Definition A DNS URL begins with the protocol prefix "dns" or "dnssec" and is defined by the following grammar, following the ABNF notation defined in [RFC4234]. Pala & Rea Expires January 10, 2013 [Page 4] Internet-Draft OOD July 2012 dnsurl = scheme COLON SLASH SLASH [base] [QUESTION [ algorithm / oid] ; base: is the base hostname for ; the lookup operation. ; algorithm: is the text representation ; of the algorithm to be used to calculate ; the hash of the certificate scheme = "dns" / "dnssec" algorithm = "SHA1" / "SHA256" / "SHA384" / "SHA512" oid = "OID" COLON oidvalue ; oidvalue is the string representation of ; the oid for the hash algorithm to be used ; to calculate the hash of the certificate SLASH = %x2F ; forward slash ("/") COLON = %x3A ; colon (":") QUESTION = %x3F ; question mark ("?") The "dns" prefix indicates an entry or entries accessible from the configured DNS server. The "dnssec" prefix indicates, instead, an entry or entries accessible via the DNSSEC protocol and verification of the returned data SHOULD be performed. Note that the may contain literal IPv6 addresses as specified in Section 3.2.2 of [RFC3986]. The construct is used to specify the digest algorithm that MUST be used to construct the final DNS query. The allowable values are "SHA1", "SHA256", "SHA384", or "SHA512". Alternatively, if a different hash algorithm is specified in the URL that is not covered by , the use of the string representation of the algorithm's OID SHOULD be used. For example, if MD5 is specified the resulting URL will look like the following: dns://somedomain?OID:1.2.840.113549.2.5 On the other hand, if one of the listed hash algorithm is to be used in the URL, the resulting value will look like the following: dns://somedomain?SHA256 At minimum, a conforming client SHOULD support SHA1 and SHA256 algorithms and MAY support additional ones. Pala & Rea Expires January 10, 2013 [Page 5] Internet-Draft OOD July 2012 4.2. URL Processing In order to process the OCSP DNS URLs in a certificate, clients have to extract the from the URL and pre-pend it with the hex representation of the digest value calculated over the DER representation of the certificate to be validated. The digest and the values SHOULD be separated by the dot "." character. The hash algorithm to be used is to be extracted from the AIA extension. If no value is specified, the SHA256 algorithm SHOULD be used to calculate the hash value. The client then constructs the query for the DNS as follows: 4088439518ed222e9abf7555b954bd549b78325b.somedomain At this point, the client has all the information to query the DNS for the OCSP response it is searching for. The client proceeds by querying the DNS for TXT records from the constructed query. The returned value SHOULD contain the value of the base64 encoded value of the OCSP response related to the certificate that needs to be validated. 5. IANA Considerations No special considerations are required for IANA. 6. Security Considerations It is only possible to provide pre-computed responses in the case where the NONCE is not provided by the client. This allows the Validation Authority (VA) or CA to generate off-line signatures for responses, an optimization used in OCSP. Moreover if an authenticated secure channel is used at the transport level between the client and the VA (e.g. HTTPS or SFTP) signatures in requests and responses can be safely omitted. 7. Time Validity The time validity should reflect the frequency of updates in revocation information. An interesting aspect to be considered is how often would users execute the protocol for a given set of data. Pala & Rea Expires January 10, 2013 [Page 6] Internet-Draft OOD July 2012 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments", RFC 5019, September 2007. Authors' Addresses Massimiliano Pala Polythecnic Institute of NYU 2 Metrotech Center Brooklyn, NY 10211 US Email: pala@nyu.edu URI: http://www.poly.edu/user/pala Scott A. Rea DigiCert, Inc 355 South 520 West Lindon, UT 84042 US Email: scott@DigiCert.com URI: http://www.digicert.com/news/bios-scott-rea.htm Pala & Rea Expires January 10, 2013 [Page 7]