[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 draft-pala-odin

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/