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 December 31, 2012.

Copyright 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. 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
• 2. Introduction
• 3. Protocol Overview
• 4. OCSP-Related DNS URLs in Certificates
• 4.1. URL Definition
• 4.2. URL Processing
• 5. IANA Considerations
• 6. Security Considerations
• 7. Time Validity
• 8. References
• Authors' Addresses

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 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

  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 ("?")
						

  dns://somedomain?OID:1.2.840.113549.2.5
						

    dns://somedomain?SHA256
						

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]. [RFC3986].

The <algorithm> 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 <algorithm>, 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:

4.2. URL Processing

  4088439518ed222e9abf7555b954bd549b78325b.somedomain<base>
						

In order to process the OCSP DNS URLs in a certificate, clients have to extract the <base> 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 <base> 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:

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.

8. References

Authors' Addresses