I've been away for a couple of weeks so I've read with great interest all
the discussion on this subject. I'd like to add my comments, starting with
what Bob Jueneman wrote:
This thread has engendered several interesting subthreads, but let's dispatch
the first one, first.
I did not understand Bob's answer to what he called "the first one". I
thought what started this thread was that Ilan Shacham wrote:
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'm assuming Ilan is talking about about the "Simple Enrollment Request"
from <draft-ietf-pkix-cmc-xx.txt> which based on a PKCS#10 message. PKCS#10
requires that "the certificate request is signed by the key inside it" and
thus his question. The "Full PKI Request" allows the request to "be signed
either by the private key material of the signature certification request,
or by a pre-existing signature key and certificate." I believe this
corresponds to Ilan's second solution. Ilan stated that this solution
provides "no Proof Of Posession of the encryption key". If I cannot attest
that a certificate request has my encryption public key with my signature,
of what use are digital signatures?
Also, I'm assuming that Ilan is talking about encryption keys used for key
management (key exchange, key wrapping, etc.) and not for encrypting data.
Hence Anne Anderson's comments about end-entities needing "to change
encryption keys frequently" does not make sense. The reason S/MIME uses
EnvelopedData is that is allows for a new *data encryption key* for every
message with a longer term *key management key*.
I agree with Bob Jueneman's position of having POP for the private key, but
I also agree with Terry Hayes' statement that even though Bob's suggestion
"is rather awkward", we should "Fix the operational level protocols
instead".
With respect to self-signed certificates, no matter what format (X.509, PGP,
SDSI, etc), whether it's from an end-entity or a CA, you have to verify it
out-of-band.
Regards,
Aram Perez