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