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]
