Skip to main content

OCSP Digest Extension
draft-hallambaker-ocspdigest-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Phillip Hallam-Baker , Rob Stradling
Last updated 2012-05-03
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-hallambaker-ocspdigest-00
Internet Engineering Task Force                          P. Hallam-Baker
Internet-Draft                                         Comodo Group Inc.
Intended status: Standards Track                            R. Stradling
Expires: November 4, 2012                                 Comodo CA Ltd.
                                                             May 3, 2012

                         OCSP Digest Extension
                    draft-hallambaker-ocspdigest-00

Abstract

   The OCSP digest extension creates a strong cryptographic binding
   between an OCSP token and the certificate it asserts a status value
   for.  Support for the digest identifier extension permits a
   certificate issuer to employ a high assurance cryptographic digest
   function such as SHA2 to attest to the authenticity of their
   certificates in a fashion that is fully downwards compatible with
   legacy clients that only support SHA1.

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 November 4, 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

Hallam-Baker & Stradling  Expires November 4, 2012              [Page 1]
Internet-Draft               OCSP Extensions                    May 2012

   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.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.1.  Digest Agility  . . . . . . . . . . . . . . . . . . . . . . 3
     2.2.  Transparency Requirement  . . . . . . . . . . . . . . . . . 4
     2.3.  The Current OCSP Protocol . . . . . . . . . . . . . . . . . 5
   3.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     3.1.  OCSP Request  . . . . . . . . . . . . . . . . . . . . . . . 6
     3.2.  OCSP Response . . . . . . . . . . . . . . . . . . . . . . . 6
       3.2.1.  Transparency requirement  . . . . . . . . . . . . . . . 7
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
     5.1.  Disclosing non existence of certificates  . . . . . . . . . 7
     5.2.  Client disclosure of certificate digest identifier  . . . . 8
     5.3.  Client detection of service compromise  . . . . . . . . . . 8
     5.4.  Verifying service compliance  . . . . . . . . . . . . . . . 8
   6.  For discussion. . . . . . . . . . . . . . . . . . . . . . . . . 8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9

Hallam-Baker & Stradling  Expires November 4, 2012              [Page 2]
Internet-Draft               OCSP Extensions                    May 2012

1.  Definitions

1.1.  Requirements Language

   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 RFC 2119 [RFC2119].

2.  Purpose

   The OCSP digest identifier is provides a mechanism that permits a new
   cryptographic digest function to be used to authenticate an X.509v3
   certificate in a manner that is fully backwards compatible with
   deployed browsers.  This capability overcomes a 'deployment deadlock'
   condition that would otherwise make deployment of new cryptographic
   digest algorithms unacceptable to many certifcate users.

   A second advantage of the OCSP digest identifier is to provide an
   affirmative demonstration that the OCSP responder had actual
   knowledge of the existence of the certificate whose status is being
   queried.  This provides a transparency control on the operation of
   the Certificate Authority issuing the certificate.  A Certificate
   Authority that has lost track of which certificates have been
   legitimately issued will be unable to determine if a response MUST or
   MUST NOT contain the digest identifier extension.

2.1.  Digest Agility

   Although the SSL Certificate industry has successfully completed a
   transition from use of the MD5 digest algorithm to SHA-1, this
   transition was a straightforward one as every Web browser that
   supported MD5 also provided support for SHA-1.  Recent cryptanalytic
   work on the SHA-1 algorithm strongly suggest that while the use of
   SHA-1 in TLS should not be an immediate cause for concern it is
   prudent to ensure that there is a viable transition plan to use of
   SHA-2, preferbly a plan that can be put into effect at short notice.

   Although the X.509v3 certificate format has supported use of SHA-2 as
   a cryptographic digest since the algorithm was first published in
   2001, there is currently no viable transition plan that permits SHA-2
   to be deployed in a manner that will be acceptable to the operators
   of Web sites that use the certificates.

   The TLS protocol and X.509v3 certificates are widely used to ensure
   the accountability, authenticity and confidentiality of Web
   transactions.  One consequence of this widespead use is that the
   population of Web browsers has become highly hetrogeneous.  While

Hallam-Baker & Stradling  Expires November 4, 2012              [Page 3]
Internet-Draft               OCSP Extensions                    May 2012

   many Web users only use the latest Web browsers with the most up to
   date security features, a significant proportion of Web users do not.
   In particular there remains a significant number of Web users whose
   browsers are ten or more years old.

   The use of older Web browsers has significant consequences for
   merchants using the Web to offer products and/or services.  A
   merchant whose Web site is not accessible to 5% of the population of
   Web browsers risks losing 5% of their sales.  Although most Web
   merchants are interested in offering their customers 'security',
   their motivation for doing so is to encourage them to do business
   with them.  Thus a security feature that causes the merchant to lose
   more customers than it gains will be unacceptable to them.

   Certificate Authorities will not issue certificates for which there
   is no market and browser providers cannot insist on the use of a
   credential format that no sites want and no Certificate Authority
   will issue.  Deployment of SHA-2 has thus reached a deadlock
   condition in which none of the parties involved can or will act until
   all the other parties have acted first.

   Although most Certificate issuers have the technical capability to
   offer digital certificates that use the SHA-2 algorithm, there is
   currently no demand for such certificates except for use in closed
   environments where the legacy browser constraints do not apply.

   The OCSP digest identifier extension permits an OCSP response to
   identify the certificate whose status it reports using a
   cryptographic digest of the certificate.  This provides a stronger
   binding between that OCSP token and the certificate to which it
   applies than the current protocol permits.

   In a typical deployment scenario, the certificate itself would be
   signed using a SHA-1 digest to ensure backwards compatibility with
   legacy browsers and the OCSP token would contain a digest identifier
   extension that uses the SHA-2 algorithm or better.  This approach

2.2.  Transparency Requirement

   A transparency requirement is a constraint on the operation of a
   service that may be verified by through access to public information
   alone.

   A transparency requirement is thus a stronger criteria than an audit
   requirement that may require privileged access to verify.

   The digest identifier extension MAY be used to enforce a transparency
   requirement that an OCSP responder mantain a complete and accurate

Hallam-Baker & Stradling  Expires November 4, 2012              [Page 4]
Internet-Draft               OCSP Extensions                    May 2012

   log of all certificates issued and accurately reports the existence
   status of the certificate(s) for which OCSP requests are made.

   Such a transparency requirement would typically be placed on an OCSP
   service that is operated by a Certification Authority to provide
   transparency with respect to compliance with a breach notification
   requirement.

2.3.  The Current OCSP Protocol

   The OCSP protocol defines an online service that reports the status
   of an issued X.509v3 certificate.  The original protocol permitted an
   OCSP response to specify the certificate it reported status of by
   means of a CertID structure specified as follows:

     CertID          ::=     SEQUENCE {
         hashAlgorithm       AlgorithmIdentifier,
         issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
         issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
         serialNumber        CertificateSerialNumber }

   While the issuerNameHash and serialNumber should be unique, this is a
   matter of convention rather than a cryptographic guarantee, a
   convention that an attacker might be able to subvert in the case that
   a CA was breached.

   The original justification made for only supporting a weak binding to
   the certificate in the CertID structure was that it should be
   possible to operate an OCSP service from information contained in
   CRLs alone

   This particular requirement is rejected.  A protocol specification
   should not attempt to enforce a lowest common denominator for
   security.  Services that have additional information available should
   not be unable to deliver it to clients merely because other services
   might not have that information.

   It is certainly legitimate for a relying party making use of an OCSP
   responder to consider a service that reports the status 'good' for a
   certificate that has never been issued to be defective.  An
   accomodation made in a specification to permit a certain level of
   service to be offered by constrained services should not prevent
   other services that are not limited from offering a greater degree of
   security.

   In this case a purpose of the specification is precisely to determine

Hallam-Baker & Stradling  Expires November 4, 2012              [Page 5]
Internet-Draft               OCSP Extensions                    May 2012

   whether the OCSP responder has actual knowledge of the certificates
   issued.

3.  Syntax

   The digest identifier extension MAY be used in CRLs or OCSP requests
   and responses.  The extension has the following format:

   cabf-ocsp-digest OBJECT IDENTIFIER ::=  { cabf 2 }

   DigestData ::= SEQUENCE {
          hashAlgorithm        AlgorithmIdentifier,
          CertHash             OCTET STRING}

   The CertHash contains the digest value of the certificate to which
   the enclosing status assertion or request applies.

3.1.  OCSP Request

   When specified in an OCSP request as a singleRequestExtensions entry,
   the Digest Identifier extension provides an additional means of
   identifying the certificate whose status is being queried rather than
   a replacement for the existing CertID structure.

   Should an OCSP responder detect an inconsistency between the contents
   of the CertID structure and the Digest Identifier extension, there
   are three possible explanations:

   o  The discrepancy is due to an unintentional software error in
      either the client software or the CA infrastructure

   o  The discrepancy is due to an OCSP request being intentionally
      misformed.

   o  The digest algorithm that was originally used to sign the digital
      certificate has been compromised and the OCSP request was made by
      client software that recieved a compromised certificate.

   An OCSP responder that is able to do so SHOULD take approrpiate steps
   to determine the cause of such discrepancies.

3.2.  OCSP Response

   When specified in an OCSP request as a singleExtensions entry, the
   Digest Identifier extension provides an additional means of

Hallam-Baker & Stradling  Expires November 4, 2012              [Page 6]
Internet-Draft               OCSP Extensions                    May 2012

   identifying the certificate whose status is being reported.

   If the contents of either the CertID or the Digest Identifier
   extension are inconsistent with the certificate being querried, the
   response entry SHOULD be rejected as not matching the specified
   certificate.

   If no matching response entries are present in a response, a client
   SHOULD consider the status of the certificate to be unknown.

3.2.1.  Transparency requirement

   An OCSP responder MUST NOT present a digest identifier extension as a
   singleExtensions entry unless it has actual knowledge that the
   corresponding certificate exists.

   An external policy MAY verify compliance with the transparency
   requirement by generating a sequence of queries for certificates that
   are known to exist and dummy queries for certificates that are known
   not to exist.

   to pass the transparency requirement, an OCSP responder MUST return
   the appropriate response to each type of query:

   o  If the certificate exists: A response with a digest identifier
      extension.

   o  Otherwise: A response that indicates an invalid status for the
      certificate and does not contain a digest identifier extension.

   Note that it is possible for a third party to determine compliance
   with the transparency requirement on a statistical basis even if the
   OCSP request discloses the digest identifier of the corresponding
   certificate in some way.

4.  Acknowledgements

   [List of CABForum and PKIX contributors]

5.  Security Considerations

5.1.  Disclosing non existence of certificates

   The deployed OCSP infrastructure only permits a client to determine
   that a certificate has not been revoked.  Some OCSP responders return
   the OCSP status 'good' in cases where the status of the certificate

Hallam-Baker & Stradling  Expires November 4, 2012              [Page 7]
Internet-Draft               OCSP Extensions                    May 2012

   is not known.  Some OCSP clients have identical behavior in the case
   that the returned status is 'good' and 'unknown'.

   Consistent use of the digest identifier permits a client to
   distinguish these cases.

5.2.  Client disclosure of certificate digest identifier

   A client may disclose the digest identifier of an issued certificate
   in an OCSP request, thus providing the service with the information
   necessary to form a response in the case that it is not entitled to
   do so by reason of not having actual knowledge of the existence of
   the certificate.

5.3.  Client detection of service compromise

   Steps that a client should take in the event that a service
   compromise is detected are outside the scope of this document.

5.4.  Verifying service compliance

   A third party may verify the compliance of an OCSP service with the
   transparency requirement by following the process specified in
   section Section 3.2.1.

6.  For discussion.

   [RFC EDITOR: DELETE PRIOR TO PUBLICATION]

   Does the OCSP Request use make any sense at all?  It does provide the
   starting point for an early detection system for bad crypto but that
   is all.  Also it is quite possible that TLS OCSP stapling will render
   the need for the request moot by the time a digest breach occurs.

   If the request extension use was removed it would mean that the
   responder was providing an effective proof that the status source had
   specific knowledge of the certificate whose status was being queried.
   (This proof would be further strengthened by use of a MAC)

   Such proof would be relevant in determining if a responder had actual
   knowledge of the certificates it reported the status of.  If a query
   is made for a certificate that is known does not or should not exist,
   the responder should respond with a generic 'unknown' error response.
   If the responder attempts to return a digest value in such cases, the
   responses are clearly spurious.

   This scheme could be further strengthened by adding an extension OID

Hallam-Baker & Stradling  Expires November 4, 2012              [Page 8]
Internet-Draft               OCSP Extensions                    May 2012

   to the certificate to specify that the OCSP responder will always
   return the digest identifier extension.  This enables a relying
   application to reject any non conformant responses as spurious.

7.  IANA Considerations

   No action by IANA is required.

8.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, April 2006.

   [X.509]    International Telecommunication Union, "ITU-T
              Recommendation X.509 (11/2008): Information technology -
              Open systems interconnection - The Directory: Public-key
              and attribute certificate frameworks", ITU-T
              Recommendation X.509, November 2008.

   [X.680]    International Telecommunication Union, "ITU-T
              Recommendation X.680 (11/2008): Information technology -
              Abstract Syntax Notation One (ASN.1): Specification of
              basic notation", ITU-T Recommendation X.680,
              November 2008.

Authors' Addresses

   Phillip Hallam-Baker
   Comodo Group Inc.

   Email: philliph@comodo.com

   Rob Stradling
   Comodo CA Ltd.

   Email: rob.stradling@comodo.com

Hallam-Baker & Stradling  Expires November 4, 2012              [Page 9]