Internet DRAFT - draft-hamilton-crlwhitelist

draft-hamilton-crlwhitelist



[intended: PKIX]                                            K. Hamilton
Internet Draft                                             Nov 22, 2011
Updates: 5280
Intended status: Standards-Track
Expires: May 2012


   Certificate Revocation List (CRL) Extensions for Backward-Compatible
                            Whitelist Provision
                    draft-hamilton-crlwhitelist-00.txt


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on May 10, 2012.







Hamilton                 Expires May 22, 2012                  [Page 1]

Internet-Draft      draft-hamilton-crlwhitelist-00             Oct 2011


Copyright Notice

   Copyright (c) 2011 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.

Abstract

   We describe two extensions to the Certificate Revocation List v2 to
   more strongly identify revoked and legitimately issued certificates.
   This creates a means for non-CA OCSP responders which are fed by CRL
   and can parse these extensions to presume that unlisted or non-
   matching certificates from that Issuer are REVOKED rather than
   UNKNOWN, as well as creating a means by which the Issuer can provide
   digest values for stronger certificate authentication.

   Placing issuance data within the CRL in some ways violates the
   original intent of the CRL, but CRLv2 has places for Extensions.  It
   is a logical extension to permit existing buildout to address newly-
   exploited vulnerabilities in the model.

   A new crlEntryExtension is defined to permit the optional provision
   of several hashes of each certificate on the list of revoked
   certificates.  In addition, a new crlExtension is defined to provide
   serial numbers and hashes of issued certificates.  Neither of these
   extensions needs to be marked critical, and the original semantics
   are preserved for existing clients.

   Notably, no data format or protocol of PKIX can currently utilize
   any extra hashes to provide any extra authentication or security.
   Nevertheless, until there is a standard way for the CA issuer to
   provide these digest values, it's impossible to build anything which
   uses them.

   The downside: Whitelist CRLs with strong certificate authentication
   data are *huge*.  The canonical 1MB CRL example would, if extended
   with this extra information, balloon to at a minimum 2.5MB
   (presuming random 20-byte serial numbers) to a single-digest maximum


Hamilton                 Expires May 22, 2012                  [Page 2]

Internet-Draft      draft-hamilton-crlwhitelist-00             Oct 2011


   of approximately 400MB.  CAs are encouraged not to alter their
   current CRL production, and produce these extensions only when
   needed by a certificate status server or consuming client.

Table of Contents

   1. Introduction...................................................3
   2. Conceptual Overview............................................4
   3. Formal Syntax..................................................4
   4. Security Considerations........................................6
   5. IANA Considerations............................................6
   6. References.....................................................6
      6.1. Normative References......................................6
      6.2. Informative References....................................7
   7. Acknowledgments................................................7

1. Introduction

   The use of Certificate Revocation Lists in PKIX derives from ITU-T
   recommendation X.509, and was intended to handle the situation where
   a CA must revoke an issued certificate.  A certificate is "issued"
   if all of the steps leading to the use of the CA's private key were
   followed, and "forged" if the CA's private key was used without
   those steps being followed.  Recent events suggest that regardless
   of the technical controls put in place, a CA's signature may indeed
   be forged.  There is also little apparent faith in existing
   revocation mechanisms, particularly regarding serial numbers and
   authentication of issued certificates.

   OCSP is supposed to help handle this situation, but there are two
   problems.  First, providing only revocation information (as opposed
   to issuance information) to the OCSP responder is weak against the
   reality of certificate forgery.  This becomes an issue when an RP
   attempts to run his own internal OCSP with the same information
   provision capacity that the CA's responder has, to eliminate
   reliance upon the CA's OCSP service.

   The second problem with OCSP is that there is no strong
   authentication of the certificates in question.  The only thing
   which can be provided in OCSP currently is the certificate serial
   number, which (in the face of forgery) is not robust.  As we move to
   defend against certificate forgery, in the face of near real-time
   hash collisions and non-robust digest algorithms, the only way to
   truly know what we're talking about is with multiple digest
   algorithms.




Hamilton                 Expires May 22, 2012                  [Page 3]

Internet-Draft      draft-hamilton-crlwhitelist-00             Oct 2011


   SCVP is also supposed to help handle this situation, but it depends
   upon the ability for the server to obtain current proof-of-validity
   information, relies upon serial numbers (since it relies on CRL and
   OCSP), and was intended to address one specific type of
   communication session.

   As a blacklist-based system, CRLs rely on the CA knowing that a
   particular certificate might, absent revocation data, validate
   within a compliant verifier before it knows that it must take action
   to invalidate or revoke it.  There is now evidence that many CA
   systems are not as incorruptible as they were thought to be, and can
   sometimes be induced to calculate signatures without retaining any
   record of the actions, which reduces the possibility that the
   certificate will be detected before it is used in an attack.

   To provide a deeper defense against these forged certificates
   (including the possibility of serial number collisions), the
   expected certificate digest values must be provided in a whitelist
   to local OCSP servers, SCVP servers, and consuming clients.  These
   extensions to CRLv2 provide this information.

2. Conceptual Overview

   The TBSCertList structure in RFC5280 specifies two locations for
   Extensions.  First, there is a per-entry Extension location
   (crlEntryExtension), within which we place a sequence of sequences
   of algorithm/value tuples. Second, there is a per-CRL Extension
   (crlExtension), within which we place a sequence containing
   sequences of each valid (non-forged) serial number and its expected
   digest values.

3. Formal Syntax

   Because this relies upon the Extension capacity of CRL [RFC5280],
   the CRL Version field MUST be set to 1 (v2).

   The MessageImprint is over the TBSCertificate, not the Certificate.
   This reduces the number of hash states which must be calculated by
   the consumer.

   Here is an ASN.1 module:

   CRLWhiteList DEFINITIONS AUTOMATIC TAGS ::= BEGIN

   EXPORTS ALL;
   IMPORTS


Hamilton                 Expires May 22, 2012                  [Page 4]

Internet-Draft      draft-hamilton-crlwhitelist-00             Oct 2011


     Extension, AlgorithmIdentifier
     FROM PKIX1Explicit88 { iso(1) identified-organization(3)
           dod(6) internet(1) security(5) mechanisms(5) pkix(7)
           id-mod(0) id-pkix1-explicit(18) }
     MessageImprint
       FROM PKIXTSP {iso(1) identified-organization(3) dod(6)
   internet(1)
             security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-
   tsp(13)} ;

   -- MessageImprint is a simple sequence of { AlgorithmIdentifier,
   digestvalue }
   -- For some reason, PKIXTSP is the only place it's independently
   defined.
   CrlWhitelistEntryExtension ::= SEQUENCE OF MessageImprint

   CrlWhitelistExtension ::= SEQUENCE OF CrlWhitelistExtensionClause

   CrlWhitelistExtensionClause ::= SEQUENCE {
     serialNumber INTEGER,
     messageImprints CrlWhitelistEntryExtension }

   -- not critical
   -- private-enterprise 22232 belongs to the author
   id-crlWhitelistEntryExtension OBJECT IDENTIFIER ::= { 1 3 6 1 4 1
   22232 9 1 }

   -- not critical
   id-crlWhitelistExtension OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 22232 9
   2 }

   END

   Generally, it is expected that CrlWhitelistEntryExtension within the
   main CRL body will be contained primarily for delta CRL entries for
   those certificates which are to be removed from the CRL (reasonCode
   removeFromCrl, 0x80).

   However, because it may be desirable in some environments to use
   clients, OCSP responders, and SCVP servers as an extended warning



Hamilton                 Expires May 22, 2012                  [Page 5]

Internet-Draft      draft-hamilton-crlwhitelist-00             Oct 2011


   net for CA security response,  this extension is valid in both
   periodic and delta CRLs, and for every serial number entry.

4. Security Considerations

   This memo specifies a mechanism to fortify Public Key Infrastructure
   security, by permitting local or hired OCSP servers to respond
   authoritatively that a certificate is REVOKED instead of UNKNOWN.
   This is an enhancement to current usage.

   The extensions described in this memo also fortify PKI security by
   providing much stronger certificate authentication in the face of
   potential certificate forgery and serial number collision.

   This format can easily lead to memory exhaustion, even in systems
   not normally prone to such.  As such, current CRL content,
   production and distribution SHOULD NOT be altered.  CRLs which
   contain these Extensions SHOULD be a supplemental production only.
   However, CRLs containing these Extensions will be processed
   correctly by clients which

   This memo also posits multiple hash algorithms being used to
   strongly identify certificates, to provide data relevant to multiple
   disjoint security policies and to hedge against future digest
   algorithm breakage.

5. IANA Considerations

   The author has used his private enterprise number (PEN) in the
   object identifiers in the ASN.1 module in this draft.

   There are two object identifiers that IANA has interest in.

   id-CrlWhitelistEntryExtension must be allocated.

   id-CrlWhitelistExtension must be allocated.

6. References

6.1. Normative References

   [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
             Housely, R., and Polk, W., "Internet X.509 Public Key
             Infrastructure Certificate and Certificate Revocation List
             (CRL) Profile", RFC 5280, The IETF Trust, May 2008.



Hamilton                 Expires May 22, 2012                  [Page 6]

Internet-Draft      draft-hamilton-crlwhitelist-00             Oct 2011


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

6.2. Informative References

   [ITUX509] International Telecommunications Union Telecommunication
             Sector, "Information technology - Open Systems
             Interconnection - The Directory: Public-key and attribute
             certificate frameworks", Recommendation X.509,
             International Telecommunications Union, Aug 2005.

   [EYNWTKX] Gutmann, Peter, "Everything You Never Wanted To Know About
             X.509 (But Were Forced To Find Out)",
             http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf
             , University of Auckland. Nov 2002.

   [X509SG]  Gutmann, Peter, "X.509 Style Guide",
             http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt,
             University of Auckland, Oct 2000.

7. Acknowledgments

   Thank you to every member of the IETF, for without you the Internet
   would not be.

   This document was prepared using 2-Word-v2.0.template.dot.

Authors' Addresses

   Kyle Hamilton
   530 Showers Dr #7/275
   Mountain View, CA  94040

   Email: kyanha@kyanha.net














Hamilton                 Expires May 22, 2012                  [Page 7]