Re: Certificate requests for encryption keys

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

Anne Anderson - Sun Microsystems <aha@East.Sun.COM> writes:

>I would like to see any Subject, including an End-Entity, be able to issue
>certificates for encryption keys (and possibly other types as well).

I proposed this some time ago, but there didn't seem to be any interest in it.
Here's the message from last time...

Peter.

-- Snip --

Current X.509 profiles all require the presence of an arbitrarily large and
all-encompassing PKI to function properly.  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 very 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 account balance information required for
   standard business practices).  Simply registering the other parties public
   key in the account record represents the easiest and most reliable way of
   managing the public key, whereas using a third-party certificate requires
   complex certificate handling, reliance on a third-party CRL, 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 submitting electronic tax
   returns: The tax department knows who its "customers" are, and *everyone*
   knows who the tax department is.  A CA doesn't even fit into this model.

2. An end entity who has a CA-certified authentication cert and wants to use it
   to issue their own confidentiality keys.  If an end entity has an
   authentication cert then there's no real 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, 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.

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's no way to specify
this in a certificate.  It's 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 this isn't what's required, and it's unlikely that
current CA's will agree to turn each of their users into mini-CA's.

To solve the first problem, we require a means of specifying that the
certificate is a standalone self-signed end-entity certificate.  Unfortunately
this can't be done with X.509, the best we can do is add a special-purpose
extKeyUsage which notifies the relying party of this.  The certificate has the
usage-related attributes set as follows:

  basicConstraints.cA = FALSE
  keyUsage = as usual, cert/crlSign bits not set
  extKeyUsage = selfSignedEndEntity

A problem with this is that certificates with the issuerName = subjectName are
regarded by a lot of software as self-signed CA root certs, so in addition to
this the issuer CN must be set to 'Owner-issued certificate'.  This isn't used
for identification purposes but to ensure that the certificate can't be
mistaken for a conventional self-signed one, which would be treated as a CA
root cert.

To solve the second problem we require two things, a means of specifying that
the certificate is an end-entity confidentiality-key-issuing cert, and a means
of handling confidentiality key rollover.  The confidentiality-key-issuing cert
has the usage-related attributes set as follows:

  basicConstraints.cA = FALSE
  keyUsage = certSign set, others set as required
  extKeyUsage = endEntityIssuingCert

A cert with this key usage has an implicit name constraint which requires that
the subject/issuer DN of the confidentiality cert be the same as the subject DN
of the c-k-i cert.  This is required in order to avoid the c-k-i cert being
able to act as a general-purpose CA.  We can't use an explicit name constraint
because they're not allowed in end-entity certs, and in any case all we can
constrain with this is a subtree, not a fixed name.

The key rollover problem is solved by having a 'supersedes' extension in the
confidentiality cert which contains a unique identifier.  The sender takes the
most recent certificate containing this identifier and uses it to communicate
with the cert owner.  Note that the identifier can't be something like the
authorityKeyIdentifier, since (a) this could change over time, and (b) these
again aren't allowed to be present in end-entity certificates.

The intended application of confidentiality key rollover is as follows:

The cert owner communicates the c-k-i cert and confidentiality key cert to the
other party in the usual manner (eg as part of an S/MIME cert chain).  The
other parties softwware records the supersedes identifier and, when it wants to
communicate with the cert owner, takes the most recent cert with that identifer
and uses it for the confidentiality key.  The cert owner can roll over their
key by including a new confidentiality cert in their mail to the other party at
any time.

If the two parties don't communicate very often, it may occur that the other
party only has expired confidentiality certs.  In this case they can use a
long-term fallback cert for the first exchanged message to bootstrap
communications, after which they'll obtain the latest confidentiality cert in
the reply to their mail.

This use of end-entity certified confidentiality keys allows perfect forward
(and backward) secrecy (keys can be rolled over on a per-message basis if
required) which is completely transparent to the user, as well as doing away
with the need for the (unnecessary) reliance on a CA for certification of
confidentiality keys.  Note that this doesn't diminish the CA's business, since
they're still required to issue the authentication certificate, which will
expire after a set time and require renewal as usual.  It makes no difference
to their bottom line whether the CA issues a single long term cert or a
single-long term cert with the ability to issue many short-term certs, in both
cases they get paid for the one cert.