Subject: Re: Certificate requests for encryption keys

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 08 Jun 1999 11:21:30 -0600

Excellent question, and one we have been pondering as well,
since Novell's NICI strongly types keys and rigidly enforces the 
allowed operations.

Our working, temporary expedient, along the lines of your #1,
is to type the private key for both encryption and signature, but to 
only turn on the encryption bit in the certificate.  But that's an 
admittedly ugly hack.  Worse yet, it won't work at all with a 
DH encryption key.

The real question is what are existing CAs prepared to support
with respect to more advanced POP protocols?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

>>> Ilan Shacham <[email-masked]> 06/08/99 10:39AM >>>
There has been much talk lately of using dual key pairs - one key pair
for encryption, and one for signing.
The following question arises - how does one create a certificate request
for an encryption key pair? after all, the certificate request is signed by
the key inside it, but the key is an encryption key, so this is illegal.

I can think of two possible solutions to this problem -
1. For the purposes of certification requests, and for this purpose only,
the
encryption key could be used to sign.
2. First, a certificate is issued to the signing key, and then the signing
key
is used to sign the certification request for the encoding key. (But this
way
there is no Proof Of Posession of the encryption key).

It looks to me like the first option is better, but I couldn't find any
reference
to this problem in the PKIX drafts/RFC's. Is there such a reference? are
there any applications out there that confronted this problem?

Ilan

------------------------------------------------------------------------
Ilan Shacham				mailto:[email-masked] 
Algorithmic Research Ltd.		http://www.arx.com 
10 Nevatim St.,			phone:	972 - 3 - 9279540
Petach-Tikva, Israel			Fax:	972 - 3 - 9230864

---

From: Ben Laurie <[email-masked]>
Date: Tue, 08 Jun 1999 19:09:26 +0100

> admittedly ugly hack.  Worse yet, it won't work at all with a

I feel sure I'm going to regret asking, but why won't this work with a
DH key?

BTW, it seems to me that the more appropriate thing to do is to make it
legal to sign certificate requests (and only certificate requests) with
encryption-only keys rather than mark the private key for signing (which
then means it can be used for signing despite the certificate). In terms
of APIs, this means constructing and signing a cert request in a single
step, I presume (or marking a cert request as "signable by an encryption
key" - hmm, that might be a cool approach, too).

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi

---

From: Anne Anderson - Sun Microsystems <[email-masked]>
Date: Tue, 8 Jun 1999 14:23:44 -0400 (EDT)

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: [email-masked]
Sun Microsystems Laboratories   or: [email-masked]
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

---

From: Stephen Kent <[email-masked]>
Date: Tue, 8 Jun 1999 15:47:53 -0400

Anne,

Certs with keys used only for encryption, vs. signing, are still bound to
an identity in the X.509 world.  For exmaple, in S/MIME, one uses such a
key to encrypt a message (more precisely the CEK for the message) for a
specified recipient.  Thus, the sender relies on a CA to have verified the
subject name in that encryption-only cert.  So, I don't think your
characterization of when identity verification is important in signature
vs. encryption certs is a good one.

Steve

---

From: Bill Burr <[email-masked]>
Date: Tue, 08 Jun 1999 16:23:02 -0400

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

>"keyCertSign", but used only for End-Entities.
Regards,

Bill Burr

---

From: Michael Sierchio <[email-masked]>
Date: Tue, 08 Jun 1999 20:06:40 -0700

> out reasonable and useful models for the use of certificates.

Anne -

All very lucid and cogent.  Unfortunately,  most of the discussion here
has been analogous to the thinking articulated by Michelin when he
declared the automobile to be an accessory of the tire.  Here it is
that PKI is an accessory of the certificate.

I'm in complete agreement with your argument.

Michael Sierchio