Re: Certificate requests for encryption keys

[Bill Burr <william.burr@xxxxxxxx>]

Anne,

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.  I think I've heard 3 arguments against self-signed
encryption certificates:

1. How can I revoke my self-signed encryption certificate except by
revoking my signature certificate?  Relatively short lifetime encryption
certificates would be at least a partial answer.

2. How can the relying party know I truly have the private key?   But why
do we need POP in this case?  I at least have never understood what the
danger is to a relying party if I claim to own an encryption key I don't have.

3. Such a system would make it hard to enforce a systematic data recovery
discipline.   

Of course a practical objection is that X.509 type systems today just
aren't set up to do it. In particular, the validation software would have
to ensure that an end entity could only sign an encryption certificate for
the same name.  We're really talking about something that goes a bit beyond
X.509, I suppose.  I think the model of a self-signed encryption
certificate is a fairly good one, but it's not quite what X.509 apparently
contemplates.

Bill Burr

At 02:23 PM 6/8/99 -0400, Anne Anderson - Sun Microsystems wrote:
>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).
>
>Justification:
>
>1. CAs have the task of certifying identity.  There does not need to
>   be a new identity certification in certifying keys other than
>   those used for certifying or verifying identity.
>
>2. End-Entities may need to change encryption keys frequently.  Many 
>   CAs are not designed for frequent updates.
>
>3. A CA can still have a policy of not signing end-entity
>   certificates that allow certification of non-identity keys, if
>   that CA wants to certify all end-entity keys.
>
>4. A verifier can still have a policy of not accepting end-entity
>   certificates that are used to certify non-identity keys, if that
>   verifying wants a "CA" to verify all keys.
>
>5. It is generally simpler for an End-Entity to manage the
>   certificates used for purposes other than identity.
>
>So REQUIRING non-identity keys to be certified by a CA seems to rule 
>out reasonable and useful models for the use of certificates.
>
>Supporting this model will require agreement on what combination of
>BasicConstraints values and KeyUsage values are permitted in
>certification paths.
>
>One way to do this follows:
>
>End-Entities could be issued certificates by a CA for keys with
>KeyUsage of keyCertSign, but certification paths would accept these
>keys only when used to sign certificates for the same End-Entity
>where keyUsage is digitalSignature, nonRepudiation?,
>keyEncipherment, dataEncipherment, or keyAgreement.
>
>Example:
>
>Certificate 1:
>   Issuer:  X
>   Subject: Y
>   SubjectPublicKey: <Y's keyCertSign key>
>   BasicConstraints: CA
>   KeyUsage: keyCertSign
>   Signed by: <X's keyCertSign key>
>
>Certificate 2:
>   Issuer: Y
>   Subject: Z
>   SubjectPublicKey: <Z's keyCertSign key>
>   BasicConstraints: EE
>   KeyUsage: keyCertSign
>   Signed by: <Y's keyCertSign key>
>
>Certificate 3:
>   Issuer: Z
>   Subject: Z
>   SubjectPublicKey: <Z's keyEncipherment key>
>   KeyUsage: keyEncipherment
>   Signed by: <Z's keyCertSign key>
>
>Other solutions include a new KeyUsage type corresponding to
>"keyCertSign", but used only for End-Entities.
>
>Anne Anderson
>-- 
>Anne H. Anderson  ECI#712-KC Email: aha@acm.org
>Sun Microsystems Laboratories   or: aha@east.sun.com
>1 Network Drive,UBUR02-311     Tel: 781/442-0928
>Burlington, MA 01803-0902 USA  Fax: 781/442-1692
>
>
Regards,

Bill Burr