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]