Internet DRAFT - draft-pala-rea-ocsp-over-dns
draft-pala-rea-ocsp-over-dns
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 <base> may
contain literal IPv6 addresses as specified in Section 3.2.2 of
[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:
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 <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:
4088439518ed222e9abf7555b954bd549b78325b.somedomain<base>
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]
