Internet DRAFT - draft-hamilton-cmr


Internet Draft                                              K. Hamilton
Updates: 5280                                              Oct 20, 2011
Intended status: Standards-Track
Expires: April 2012

      Certificate Manifest Register (Certificate Revocation List v4)

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on Apr 13, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors. All rights reserved.

Hamilton                 Expires Apr 20, 2012                  [Page 1]
Internet-Draft          draft-hamilton-cmr-00                  Oct 2011

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( 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.


   In the spirit of simple, incremental improvement, we describe a
   whitelist-based revocation mechanism called the "Certificate
   Manifest Register".  This is a list of all potentially-valid
   certificates which are (as of the date of production) known to have
   been legitimately issued by the CA and how they are to be treated by
   the client.  This permits certificates which are checked against it
   to be presumed invalid unless listed.

   Several recent events have cast doubt on the sufficiency of
   blacklist-based PKIX certificate revocation mechanisms.  At least
   one publicly-trusted Certification Authority was recently found to
   have been penetrated by a state-backed attacker, which issued itself
   several certificates valid for a particular global web search and
   email provider and then removed the records that it had done so.  In
   effect, the attacker was able to cause the CA to sleepwalk.  There
   was nothing that the client software developers could do to protect
   their users and themselves except remove the trust in that CA's
   root.  This event directly caused that particular CA's insolvency.

   The Certificate Revocation List format and definitions (X.509v2 as
   described in RFC 5280, its predecessors, and possibly its
   successors) are used and adapted whole-hog, with no data format
   changes and the alteration of one rule and one semantic to support
   whitelist-based processing.  CMR is defined to use version integer 3
   (v4) to differentiate its processing path from v2 CRL.  The changes
   from the CRL Profile are so minor, though, that they potentially
   might be implemented without a version bump, without disruption to
   current v2 CRL consumers.

Table of Contents

   1. Introduction...................................................3
   2. Conceptual Overview............................................3
      2.1. From the viewpoint of the CMR issuer......................3
      2.2. From the viewpoint of the CMR verifier....................4

Hamilton                 Expires Apr 14, 2012                  [Page 2]
Internet-Draft          draft-hamilton-cmr-00                  Oct 2011

   3. Formal Syntax..................................................4
   4. Security Considerations........................................4
   5. IANA Considerations............................................5
   6. References.....................................................5
      6.1. Normative References......................................5
      6.2. Informative References....................................5
   7. Acknowledgments................................................6

1. Introduction

   ITU-T (International Telecommunications Union, Telecommunications
   Division) created the X.509 data format and semantics.  As an arm of
   United Nations, it grew from a peculiar "state is god, and we manage
   communications between gods" viewpoint.  It was never designed for
   anything other than state-to-state and telco-to-telco

   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 a previously-issued certificate.  As a blacklist-
   based system, CRLs rely on the CA knowing that a particular
   certificate might be valid before it knows that it must take action
   to invalidate or revoke it.  There is now evidence that many CA
   systems are not incorruptible, and can sometimes be induced to
   calculate signatures without retaining any record of the actions.

   To provide a deeper defense against this sleepwalking CA threat, the
   CRL (a blacklist-based system) must be replaced with a whitelist-
   based system such as proposed in this Internet-Draft.

2. Conceptual Overview

   To ease implementation, this protocol is simply CRLv2.  Known-valid
   certificates are added to the main CRL with the reasonCode
   removeFromCrl, and the default processing path changes to INVALID.

2.1. From the viewpoint of the CMR issuer

   Import CRL and delta CRL v2 semantics from [RFC5280].  Change the
   SEQUENCE identifier from integer 1 to integer 3.  Then, add every
   certificate which is known to be potentially valid (though not
   necessarily those which have expired) to the CRL structure.  For
   certificates which have been revoked by the issuer, the reasonCode
   should be set appropriately.  For certificates which have not been
   revoked, the reasonCode should be set to removeFromCrl.

Hamilton                 Expires Apr 14, 2012                  [Page 3]
Internet-Draft          draft-hamilton-cmr-00                  Oct 2011

   After generating this list, sign and distribute it as usual, using a
   newly-defined extension which has precisely the same semantic as the
   CrlIssuers extension except for CmrIssuers.

2.2. From the viewpoint of the CMR verifier

   Nominate a certificate.  Import the CRL and delta CRL v2 semantics
   from [RFC5280], and validate the CMR as described there.  Expect
   integer 3 instead of integer 1, but otherwise the same structure.
   Check that the serial number of the nominated certificate is found
   on the CMR, and that the reasonCode indicates that the certificate
   is not revoked (removeFromCrl).  Expect that expired certificates
   are not on the CMR.

3. Formal Syntax

   Deferred, to gauge reaction to this proposal.

   It can be summed up as "place the serial numbers of valid
   certificates on non-delta CRLs with reasonCode removeFromCrl, and
   change the semantic of being unlisted to presumption of a forged

4. Security Considerations

   This memo specifies a mechanism to fortify the end-user security of
   the relying parties of the Public Key Infrastructure.  It is
   specified to use a different DER tag from classic CRLs so that old-
   format consumers will safely fail to process it.  The semantics are
   well-documented, and implementations can all but reuse their
   existing code.

   Realistically, it is necessary for many Certification Authorities to
   exist.  There are nearly seven billion people currently living on
   this planet.  With 100 CAs, it works out that each one must handle
   approximately 70 million natural people plus 1% of however many
   corporations exist.  It is simply inevitable that flaws in their
   controls will surface, and it does no good to simply slash and burn
   any processor for a workload which will only have to be picked up by
   the remainder of the industry.  These organizations are critical to
   the success of the Internet PKI, and must be protected from human
   and institutional imperfections.

   Following this, it must not be possible for any individual
   penetration to cause havoc for the other clients of the CA (such as
   happens when trust is removed).  It must not be possible for any
   individual penetration to compromise the perceived security of the

Hamilton                 Expires Apr 14, 2012                  [Page 4]
Internet-Draft          draft-hamilton-cmr-00                  Oct 2011

   entire infrastructure (such as when trust is removed from any
   portion thereof).  Most importantly, it must not be possible for any
   individual penetration to cause a CA to go out of business.

   The approach taken here is quick and dirty, designed for incremental
   improvement and ease of implementation.  It must not be the final
   word on the matter.

   There are numerous improvements which could be made to the
   revocation system, such as adding the hash of the Certificate (or
   perhaps the TBSCertificate, to reduce the number of hash states
   which must be calculated) to be expected with the given serial
   number.  The author strongly recommends that these improvements be
   explored as additional incremental changes.

5. IANA Considerations

   The allocation of the ASN.1 sequence-identification object for the
   CMR (here suggested as integer 3 (v4)) should be up to IANA.  As an
   alternative, a new object identifier (OID) could be allocated to
   take the place of the integer object.

   A new certificate extension (CmrIssuers) is described in this memo.
   Its extension identifier will also eventually need to be allocated
   by IANA.

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.

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)",
             , University of Auckland. Nov 2002.

Hamilton                 Expires Apr 14, 2012                  [Page 5]
Internet-Draft          draft-hamilton-cmr-00                  Oct 2011

   [X509SG]  Gutmann, Peter, "X.509 Style Guide",
             University of Auckland, Oct 2000.

   [WIKIDIG] Wikipedia contributors, "DigiNotar," Wikipedia, The Free
             456225860 (accessed October 20, 2011).

7. Acknowledgments

   Thank you to IETF and PKIX, for without you the Internet would not

   Thank you also to Mozilla for providing a forum for discussion.

   This document was prepared using

Authors' Addresses

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


Hamilton                 Expires Apr 14, 2012                  [Page 6]