Internet DRAFT - draft-hamilton-cmr
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)
draft-hamilton-cmr-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 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
(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
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
communications.
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
credential."
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)",
http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf
, 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",
http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt,
University of Auckland, Oct 2000.
[WIKIDIG] Wikipedia contributors, "DigiNotar," Wikipedia, The Free
Encyclopedia,
http://en.wikipedia.org/w/index.php?title=DigiNotar&oldid=
456225860 (accessed October 20, 2011).
7. Acknowledgments
Thank you to IETF and PKIX, for without you the Internet would not
be.
Thank you also to Mozilla for providing a forum for discussion.
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 Apr 14, 2012 [Page 6]
