Re: Certificate requests for encryption keys

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

Bill,

I believe your first sentence contains the answer:  what you want is
a "signed" encryption key, not a "certified" encryption key.

If there is a need for long-term encryption keys certified by a third
party, then an X.509 certificate is the appropriate structure to
represent them.  But if there is a need for rapidly updated public
key-establishment keys, or no need for a third party to be involved in
certifying a longer term key establishment key, then why would one
choose to use an X.509 certificate in the first place?

As Steve pointed out, IKE (the IPSEC Internet Key Exchange protocol)
supports PFS.  I would also point out that TLS defines an Ephemeral DH
exchange using (by definition) non-certified public keys.

CMS (S/MIME) requires X.509 certificates for encryption because there
is no requirement for an envelopedData structure to be wrapped within
a signedData structure, thus the certificates used with envelopedData
must support both encryption and authentication.  But a hypothetical
non-S/MIME protocol could profile a mandatory wrapping of CMS
envelopedData within a signedData, and define a publicKeyInfo attribute
to hold the naked encryption key, eliminating the need for
X.509 authenticated-encryption certificates.

I believe the lack of sympathetic response to the suggestion of
EE-issued X.509 encryption certificates is well deserved.  Using an
X.509 Certificate structure to represent a non-third-party-certified
EE-signed public key-establishment key is like driving a screw with a
hammer.  You could do it, but why would you want to?

Dave Kemp



> From: Bill Burr <william.burr@nist.gov>
> Subject: Re: Certificate requests for encryption keys
> 
> 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