Subject: Re: Certificate requests for encryption keys

From: [email-masked] (Peter Gutmann)
Date: Thu, 10 Jun 1999 03:02:13 (NZST)

Bill Burr <[email-masked]> writes:

>Your line of reasoning has always made sense to me.  If you can validate my
>signature, why wouldn't you trust me to sign my own encryption key?
>
>Nevertheless, when I have mentioned the idea that end entities could
>self-sign encryption certificates, I don't think I've ever received a
>sympathetic response.

Given that there seem to be several people in this situation out there, is
there any interest in doing a profile for these certs?  It's pretty trivial
to implement given any existing toolkit, all we'd need is to achieve 
consensus on how the certs should be denoted.  Since there's no backwards-
compatibility issue, all you really need to do is convince enough people to
adopt the scheme.

Peter.

---

From: Bill Burr <[email-masked]>
Date: Wed, 09 Jun 1999 14:12:55 -0400

>compatibility issue, all you really need to do is convince enough people to

Peter,

As attractive as I find the idea of issuing my own encryption certificates,
I'm not sure that there is really a demand for self-issued encryption
certificates.  CA issued encryption certificates work well enough, and
folks are already set up to do that.  If I were able to start over and
build a PKI "right" I think I'd do a lot of things differently, but a lot
of water has passed under the dam already, and there probably is not much
desire for structural changes at this point.

I originally thought about self-signed encryption certificates in the
context of thinking about the old UK White paper that proposed to make CAs
that didn't escrow encryption or key management keys, more or less illegal.
 I decided that, if that were done, it would be, as you point out, pretty
easy to write some code that worked from self-signed encryption
certificates.  Once I had a signature certificate from an official licensed
CA, I could use that to prove my identity and sign my own encryption
certificate, getting the benefit of the licensed CA, but easily avoiding
any kind of key escrow. It would require a profoundly heavy handed and
oppressive police state to suppress such an approach.

But such mandatory schemes have largely disappeared.  Even the French seem
to have given up on them.    
Regards,

Bill Burr

---

From: Al Arsenault <[email-masked]>
Date: Wed, 09 Jun 1999 14:52:26 -0400

It's actually very straightforward.  In fact, we implemented it several years
ago.  You just do the following:

(1) start with an X.509 profile, such as RFC 2459;

(2) change the rules so that a certificate containing a key-management key only
(i.e., a key with the digitalsignature, non-repudiation, keyCertSign, and
CRLSign bits all OFF) is valid if:
    - the issuer is a CA (basicConstraints = TRUE and keyUsage = at least
keyCertSign);
or
    - the issuer is an end-entity (basicConstraints = FALSE) and the issuer's
name and subject's name are identical.  This case holds regardless of the fact
that the issuer's key has keyCertSign OFF.  (There may be some other conditions
here; I'm doing this off the top of my head.)

(3) then, you do a lot of software modifications. You provide the users the
software to generate and sign their own certificates.  You change the
application software so that it accepts these self-signed key management certs
under the rules given in (2).  You also change the application software to
handle revocation in one of three ways:

    (a) you don't revoke these certs, you just wait until they expire;
    (b) you revoke the key-management cert indirectly, by revoking the signature
cert containing the key used to sign it;
    (c) you deal with lots of very small CRLs or widely-scattered OCSP
responders

None of these is very pleasing to application developers, except maybe (a), but
that's not really pleasing to system designers who want a "secure" system.
Sure, you could have the certificates expire every hour, but now you've
introduced a load on your system with all of the certificate generation.

All of this assumes that the new self-generated key management certificate is
signed using a key from a certificate that is itself traceable back to a CA you
trust.  Otherwise, you're completely out of the PKIX realm.  (If I don't have to
provide a cert path back to a CA you trust, then if you don't know either of us
personally,  I suspect I wouldn't have much difficulty convincing you that I'm
Russ Housley and this is my key management certificate.)

But, after doing all of this, the question that arises is the one already posed
by Dave Kemp:  why do you want to do this?  Certainly, I can understand
financially-based desires - for security reasons, you want a new key management
certificate every month, or every day, and you don't want to pay $24.95 or
$159.95 everytime you get one. But that doesn't strike me as being a good reason
to change a technical system so dramatically.  (And, no, I have no personal
financial interest in selling certificates.  I'm not even allowed to own stock
in most of those companies. :-)

I guess my bottom line is this:  PKIX was designed for a specific set of
purposes.  It fulfills most of those purposes pretty well (IMNSHO).  However,
PKIX was never designed AND CAN NEVER BE a be-all and end-all of public-key
based security in the Internet.  Things like IKE without certificates, and
SSL/TLS without certificates will always have a place in Internet security.

                Al Arsenault

-- As usual, speaking for myself.  My opinions do not necessarily reflect those
of my employer or of any other organization with which I have a relationship.