Internet Draft Editor: Peter Gutmann
draft-ietf-pkix-autonomous-certs.txt University of Auckland
June 22, 1999
Expires December 1999
X.509 Profile for Autonomous Certificates
Status of this memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. 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.
Abstract
Current X.509 profiles assume the presence of an arbitrarily large and
all-encompassing PKI run by third parties in order to function. Unfortunately
this doesn't take into account common cases such as the situation where parties
have an existing trust relationship and want to share keys (without requiring
a third party to issue them certificates), or where an end entity has a signing
certificate and wants to issue their own confidentiality keys rather than
requiring the cooperation of a third party to do it for them, or where an end
entity wishes to distribute their keys via commonly-available mechanisms such
as web pages instead of waiting for a Directory capable of performing this task
to appear.
This profile presents a mechanism for identifying and working with end-entity
certificates which fulfil the above requirements. This use of end-entity
certified keys, combined with the distribution mechanism described below,
allows perfect forward (and backward) secrecy (keys can be rolled over hourly
if required) which can be made completely transparent to the user, as well as
doing away with the need for the (often unnecessary) reliance on a CA for
certification of keys, and with the need for a Directory or similar mechanism
for key distribution.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as
described in [RFC2119].
The format of the messages are described in ASN.1:1994 [ASN1].
This draft is being flamed on the "ietf-pkix" mailing list. To join the list,
send a message to with the single word "subscribe"
in the body of the message. Also, there is a Web site for the mailing list at
.
1. Introduction
1.1 Defining the Problem
Current X.509 profiles assume the presence of an arbitrarily large and
all-encompassing PKI run by third parties in order to function. Unfortunately
this doesn't take into account two very common cases:
1. Two parties who have an established trust relationship and want to share
keys. This is a common case for businesses who would typically have
existing bilateral trading arrangements and neither require, nor care for,
an external (or internal) CA. Keys for the other party would be held as
part of the standard account records maintained by both sides, which would
also contain information such as the account balance information maintained
as a standard business practice. Simply registering the other parties
public key in the account record represents the easiest and most reliable
way of managing the public key. In contrast, using a third-party
certificate requires complex (and often nonexistant) certificate handling
mechanisms, reliance on third-party CRLs, and the creation of an unnecessary
parallel trust infrastructure which adds nothing (apart from complexity) to
the existing trust mechanism.
A typical example of this would be users who are communicating with the tax
department. The tax department knows who its "customers" are, and
*everyone* knows who the tax department is. An external CA doesn't fit
into this model.
2. An end entity who has a CA (or otherwise) certified authentication cert and
wants to use it to issue their own confidentiality key certificates. If an
end entity has a signature cert then there is no need for CA-issued
confidentiality certs, especially since this grants the end entity a far
greater degree of control over their keys. For example the end entity might
wish to roll over their confidentiality keys once a month or once a week, a
prudent security precaution which could end up bankrupting them if it were
attempted with CA-certified keys.
Unfortunately both of these items, while perfectly sensible, represent a
paradox for X.509, since a certificate is incapable of representing them:
There's no way to create a standalone end-entity certificate containing a
public key, and there's no way for an end entity to create/certify their own
confidentiality keys. An unfortunate side-effect of this is that developers
and users are finding their own workarounds to the problem, typically by
creating X.509v1 self-signed certificates which are commonly treated as CA root
certificates by current software. The documentation provided by some software
vendors even encourages users to create their own (effective) CA root
certificates, and to aid the users in doing this the vendors provide software
tools which create these certificates automatically, including the ability to
specify any name the user wants (for example the name of a standard commercial
CA). As a result, anyone encountering one of these DIY certificates on the net
who uses the standard technique of clicking "OK" until the dialog boxes go away
will give the certificate the same weight as the certificate of a large
commercial CA.
1.2 Reasons for the Problem
The reason a standalone end entity certificate can't exist is that it has to be
signed by a CA, but an end entity is by definition not a CA and therefore can't
do this. A workaround is for the end entity to create a pseudo-CA certificate
whose only task is to sign other certificates, but all this does is add
unnecessary complexity.
The reason an end entity certified confidentiality key can't exist is again
because an end entity isn't a CA, and again because there is no way to specify
this in a certificate. Its possible to make the end entity a CA with a path
length of zero and a name constraint which only allows them to issue certs to
entities below them, but its unlikely that CAs will agree to turn each of their
users into mini-CAs, and in any case whats required is that they have the
ability to issue certificates only for themselves, not for anyone in the tree
below them. If this were to be handled through constraints, what would be
required is a purpose constraint, which isn't present in X.509.
The reason why people are resorting to measures such as creating (de facto) CA
root certificates for end users is because, until now, there was no way to
resolve these problems.
1.3 Further Issues
Related to the creation of autonomous certificates is the issue of certificate
distribution and revocation - creating a mechanism for autonomous certificates
is of little use if it relies on a (nonexistant) Directory to distribute them.
For this reason this profile recommends the use of web-based certificate
distribution and revocation as explained in section 3.
2. Certificate and CRL profile
This profile defines two types of certificates, an end entity self-signed
(EESS) certificate which is identical to a conventional end entity certificate
except that it is issued by an end-entity rather than a CA, and an end entity
confidentiality key (EECK) certificate which is identical to a conventional end
entity confidentiality certificate except that its intended usage is as a short
term certificate renewed frequently using the end entity's authentication
certificate. The three usage scenarios for these certificate types are:
EESS - Conventional certificate but issued by the end entity
EESS -> EECK - Long-term EESS signature certificate used to issue short-
term EECK certificates
CA -> EE -> EECK - Standard CA-issued long-term signature certificate used to
issue short-term EECK certificate
The third scenario allows legacy CA-issued signature certificates to be used
as a means for issuing EECK certificates.
2.1 Self-signed End Entity Certificates
To allow an end entity to issue certificates for themselves we require a means
of specifying that the certificate is a self-signed end entity (EESS)
certificate. Unfortunately this can't be done with X.509, the best we can do
is to add a special-purpose extKeyUsage field which notifies the relying party
of this.
An EESS certificate shall have the following values in the basicConstraints,
keyUsage, and extKeyUsage extensions:
basicConstraints
The cA field shall be set to FALSE
The pathLenConstraint field shall be absent
The cA field has a default value of FALSE, therefore the entire
basicConstraints extension shall be encoded as a zero-length sequence. This
zero-length sequence must be present in order to ensure that the certificate
is not treated as a CA root certificate; most current implementations will
treat a self-signed certificate with no basicConstraints as a CA root.
keyUsage
For standard EESS certificates the keyCertSign and crlSign bits shall not
be asserted. For EESS certificates which will be used to issue EECK
certificates (see section 2.2), the keyCertSign bit shall be asserted. For
EESS certificates which will be used to issue CRLs (see section 2.3), the
crlSign bit shall be asserted.
extKeyUsage
This extension shall include 'endEntitySelfSigned' as one of its extended
uses:
id-endEntitySelfSigned OBJECT IDENTIFIER ::= {1 3 6 1 4 1 3029 42 1}
-- Certificate is a self-signed end entity certificate
-- (OID is temporary until a proper one is assigned)
In addition EESS certificates must include a subjectKeyIdentifier for the
reasons given in section 2.2.
2.1.1 Rationale
The zero-length (empty) basicConstraints extension is required in order to
avoid having the certificate treated as a CA root certificate by existing
implementations.
The non-asserted keyCertSign and crlSign bits are used in order to avert other
potential problems with existing implementations which may become confused if
they see a non-CA certificate with CA keyUsage bits asserted, and to emphasize
the fact that the certificate is not usable for certifying other certificates.
The extKeyUsage extension is the one which defines the semantics for the
certificate. Its presence ensures that implementations which do not conform to
this profile will not process the certificate.
2.2 Self-issued End Entity Confidentiality Key Certificates
To allow an end entity with an existing signature certificate to issue and
manage their own confidentiality certificates, we require a means of specifying
that a certificate is an end entity confidentiality-key (EECK) certificate.
This certificate may be signed either by an EESS certificate as described in
section 2.1, or a standard certificate issued by a third-party CA.
A EECK certificate shall have the following value in the extKeyUsage extension:
extKeyUsage
This extension shall include 'endEntityConfidentialityKey' as one of its
extended
uses:
id-endEntityConfidentialityKey OBJECT IDENTIFIER ::= {1 3 6 1 4 1 3029 42 2}
-- Certificate is an end entity confidentiality-key certificate
-- (OID is temporary until a proper one is assigned)
EECK certificates must include an authorityKeyIdentifier extension identifying
the CA-issued or EESS certificate which used to issue them.
A certificate with this type of extended key usage has an implicit name
constraint which requires that the subject and issuer DN of the EECK
certificate be the same as the subject DN of the issuing certificate and the
subject and issuer altName of the EECK certificate be the same as the subject
altName of the issuing certificate. This is required in order to prevent the
EECK issuer from being able to act as a general-purpose CA. Conforming
implementations must verify that both the subject and issuer DN of the EECK
match the subject DN of the issuing certificate and that the subject and issuer
altName of the EECK match the subejct altName of the issuing certificate.
2.2.1 Rationale
The zero-length basicConstraints extension is required in order to avoid having
the certificate treated as a CA root certificate by some existing
implementations.
The extKeyUsage extension is required to indicate that the certifiate follows
the EECK semantics, and if the issuing certificate is a standard CA-issued
signature certificate to indicate that the issuing certificate (which won't
have the keyCertSign bit asserted) is in fact allowed to sign the EECK
certificate.
[Note that this pushes different semantics back onto the CA-issued signature
cert, but it's the only way to ensure that conventional certificates can be
used to issue EECK certificates]
The authorityKeyIdentifier is required because the implicit name constraint has
the potential to result in the existence of large numbers of EECK certificates
with the same subject DN, in which case the authorityKeyIdentifier will be
required to determine the correct issuing certificate.
The implicit name constraint is required in order to prevent the EECK cert
issuer from acting as a general-purpose CA. Although this would normally be
specified through an explicit name constraint, these are not permitted in end
entity certificates, and even if they were permitted are only capable of
constraining a subtree, not a fixed name. Although this could be further
kludged with path length constraints, most current implementations probably
won't handle this properly, making relying on it an uncertain proposition.
2.3 CRLs
To allow an end entity with a EESS certificate to explicitly revoke it, a CRL
may be used, although this profile recommends instead the use of implicit
validity checking via HTTP distribution of certificates or alternatively
methods such as implicit revocation through the use of short-lived certificates
(this being one of the reasons for having EECK certificates) or revocation
through out-of-band means (for example managing it through the accounting
system mentioned in the introduction). For EECK certificates it is strongly
recommended that revocation be handled implicitly either through the HTTP
mechanism described in section 3 or by limiting the validity time of the
certificate.
If explicit revocations via CRLs is to be used then a prudent practice to
follow when creating an EESS certificate is to simultaneously create a "suicide
note" CRL to revoke it when required and to store it in a safe place for later
use. This can be published when it becomes necessary to revoke the certificate
without requiring access to the private key used to create it. The semantics
for a EESS CRL differ somewhat from conventional CRLs in that the appearance of
the revocation indicates that relying parties should cease using the
certificate immediately. The thisUpdate field is meaningless (only one
revocation is ever issued) and the revocationDate field can't be determined at
the time the CRL is created. It is recommended that these fields be set to the
CRL creation date, and that relying parties attach no particular significance
to the contents of the fields.
2.3.1 Revocation Issues
The original X.509 revocation mechanism relied on CRLs which were intended to
be employed in a manner similar to the credit card blacklists used in the
1970's before they were superseded by the use of online validity checks. As
with credit card blacklists, the use of CRL's for validity checking involves a
two-phase process:
1. Obtain a certificate of unknown validity
2. Obtain a CRL to determine whether the certificate can be relied upon
(fans of the Black Adder TV series may recall this protocol being used in the
"Here is a purse of money... which I'm not going to give to you" transaction
which occurs in the first episode of season 2).
In the presence of online checking this two-phase check becomes unnecessary,
since it can be simplified to a single step:
1. Obtain a currently valid certificate.
The fact that a certificate is available online indicates that it is currently
valid; failure to obtain a certificate indicates that there are no valid
certificates available. Since publication is controlled by the certificate
owner (see section 3), the owner also has full control over certificate usage
by relying parties.
A variant with a somewhat larger margin of error involves the use of short-term
certificates:
1. Obtain a certificate which will be valid for the next hour.
This variant is still no worse than the CRL version since CRL's are typically
not issued more than once an hour, and is still only a single-step process.
3. Certificate Management
In the absence of any other convenient distribution mechanism such as personal
contact, trusted courier, or (if a CA-certified signature certificate is being
used) PKI-based trust mechanisms, a recommended means of certificate
distribution and management is through the world-wide web. This means of
certificate publication is almost universally available, and provides a
convenient and (relatively) reliable way to publish certificates, perform
validity checking, and optionally publish CRLs if they are to be used.
It is recommended that certificates be published via the users home page
using the following naming scheme:
http://www.homepage.com/eesscert.der -- Issuing certificate
http://www.homepage.com/eesscrl.der -- Suicide note for EESS cert
http://www.homepage.com/eeckcert.der -- EECK certificate
http://www.homepage.com/eeckcrl.der -- Suicide note for EECK cert
This allows relying parties who wish to obtain the users certificate to fetch
it directly from a known location using a single HTTP GET, which can be
implemented using a read and write on a socket (it does not require spawning a
web browser and having the user cut and paste data across).
If CRL's are to be used then the CRL would be created at the same time as the
self-issued certificate, acting as a "suicide certificate" for the actual
certificate as discussed in section 2.3. When it becomes necessary to revoke
the certificate, the pre-generated CRL is published at the location indicated
in the certificate.
Since the certificate publication mechanism makes it extremely easy to generate
new certificates, it is recommended that confidentiality keys be rolled over
frequently both for security reasons (frequent key changes limit the exposure
of any one key) and as a simple key revocation mechanism - a key with a
lifetime measured in days needs very little extra support in terms of an
infrastructure for revocation.
In the most extreme case a new key can be generated for every message, with the
server serving a new eeckcert.der for each HTTP GET request. Note that while
this option provides a high level of security (since a new key is used for each
message), it imposes an extra load on the server, which needs to generate new
keys in response to HTTP requests (possibly leading to a denial-of-service
attack) and needs to dynamically update the content rather than simply serving
a static file (leading to a need for server-side scripting rather than simply
placing a file in the appropriate directory). This option therefore provides a
high level of security at the expense of requiring extra work to be performed
by the server.
3.1 Identifying EESS Certificates to Relying Parties
The problem of distributing current CA root certificates is typically addressed
by hardcoding them into web browsers and mail programs and decreeing them to be
implicitly trusted, unfortunately this luxury isn't available to holders of
EESS certificates. Where these certificates are distributed through personal
contact (for example by exchange of business cards) it is recommended that the
information specified include the URL of the web page containing the
certificate(s) (from which the full URL of the certificates and CRL's can be
trivially constructed), and the fingerprint (SHA-1 hash) of the EESS
certificate at that location, truncated to fit the space available if required.
Where a truncated hash is used, the truncation is performed to the right, in
other words the leftmost bytes of the hash are retained and an appropriate
quantity of rightmost bytes are discarded. It is recommended that the hash not
be truncated to less than 64 bits.
This method provides an out-of-band identification mechanism similar to the one
which has been in wide use for PGP for a number of years. As an illustration,
the previously-used sample certificates might be identified on a business card
with:
Cert location: http://www.homepage.com/
Cert fingerprint: 07 2C BD 10 24 37 0F 1D
3.2 Rationale
Since virtually everyone seems to have a home page somewhere, certificate
publication via the web provides a convenient key distribution mechanism while
users wait for a Directory to appear. The online certificate fetch ensures
that the latest certificate will always be used and that the certificate will
be a currently valid one. Updating or revoking a key managed in this way is a
relatively simple matter and doesn't require the cooperation of third parties
to perform.
In terms of centralised vs distributed PKIs, one way to break a conventional
Directory-based PKI is to perform a denial-of-service (DOS) attack on the
server through which the CRL is published to ensure that the CRL is never
delivered. The typical workaround for this is a complicated timestamp-based
one which is intended to indicate that some sort of revocation information
should have been made available at some point but wasn't, like a number of
other esoteric PKI aspects this has very little implementation support. In
contrast performing a DOS attack on the server will simply make the certificate
itself unavailable, indicating to the relying party that something is wrong.
4. Usage Example
4.1 Scenario 1
Alice wants to communicate with Bob without Mallet being able to intercept
their communications. She obtains a free certificate from a commercial CA and
uses it to create an EECK certificate with a validity of one week which she
puts on her home page.
When Bob wants to send Alice mail, he fetches her certificate from her home
page with an HTTP GET.
Once a week, Alice generates a new EECK certificate and uses it to replace the
existing one on her home page.
If she suspects her EECK key has been compromised, she rolls over the EECK
certificate before the week is up. Explicit revocation is unnecessary and not
used.
4.2 Scenario 2
Alice wants to communicate with Bob as before. She creates an EESS certificate
and puts the URL and fingerprint on her business card. She also creates an
EECK certificate and puts both certificates on her home page. When she and Bob
next meet, she hands him her card, which Bob can use to verify her EESS
certifcate.
When Bob wants to send Alice mail, he fetches her certificate from her home
page with an HTTP GET.
Once a week, Alice generates a new EECK certificate and uses it to replace the
existing one on her home page.
If she suspects her EECK key has been compromised, she rolls over the EECK
certificate before the week is up. Explicit revocation is unnecessary and not
used.
5. Security Considerations
The security of autonomous certificates rest on the security of the mechanisms
used to authenticate them. Relying parties should ensure that the certificates
they are working with meet their requirements in terms of assurance of
authenticity.
Author Address
Peter Gutmann
University of Auckland
Private Bag 92019
Auckland, New Zealand
pgut001@cs.auckland.ac.nz
References
ASN1 Recommendation X.680: Specification of Abstract Syntax Notation
One (ASN.1), 1994.
RFC2119 Key Words for Use in RFCs to Indicate Requirement Levels, S.Bradner,
March 1997.
Full Copyright Statement
Copyright (C) The Internet Society 1999. All Rights Reserved.
This document and translations of it may be copied and furnished to others, and
derivative works that comment on or otherwise explain it or assist in its
implementation may be prepared, copied, published and distributed, in whole or
in part, without restriction of any kind, provided that the above copyright
notice and this paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing Internet
standards in which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be revoked by
the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS"
basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.