Re: dissemination of public encryption certificates

Anders,

Anders Rundgren wrote on 08/15/2003, 0:06:

> May I add some naive thought to the table?
>
> That the issuer is of great importance for signatures and authentication
> purposes is undoubtedly true.
>
> But I cannot really say that I see the same need for TPP-issued
> encryption
> certificates.  Is there even a need for encryption-certificates?  It
> seems sufficient
> that users in their e-mail client create key-pairs and publish the public
> key in the associated domain.  If you trust the lookup service like XKMS
> why should this not be enough?
Certificates establish a permanent, traceable link between the user's 
identity and the public key.

If I correctly understand what you propose, the XKMS service would 
provide a temporary link between the user's identity and the the public key.

One reason this link isn't enough is revocation. If the key gets 
compromised at some point, how do you indicate at a later time not to 
trust that key anymore ? And how do you do it retroactively ?

Correct me if I'm wrong, but most revocation systems today are based on 
CRLs rather than KRLs. The government was the only user of KRLs but even 
they are using CRLs now. Most software as a result primarily supports 
certificate-based revocation, not key-based revocation.

> Well you could actually create a
> self-signed
> certificate in your mail client and send a signed message (using
> a trusted signer cert/key) containg the generated encryption key or
> cert to
> encryptionregistry(_at_)yourdomain to get it automatically published.
> No apparent need for CAs and associated root and path validation
> for encryption certificates.
It should be a policy of the repository however to decide whether or not 
to apply path validations for certificates it stores. Certainly one 
could decide not to do any validation if they so chose.
However eventually, when an end user does a query, they most likely 
won't trust that self-signed certificate due to their trust domain 
configuration. So it would not be in the interest of the repository to 
have too lax of a policy on cert issuers.

> XKMS introduces an optional trust-anchor itself but that would not
> work (scale)with encryption certificates for a global Internet.  So no
> matter what you do, there will be lose ends on all lookup solutions.
> Only the hard transfer-the-globally-recognized-TTP-certificate-out-
> band will be "fully secure" and we already know that this does not
> support the more dynamic scenarious we are currently discussing.
It can work if there is a set of well-known accepted trusted roots. I 
don't think every single random root should be automatically trusted. 
What's missing is a way to easily replicate the trust domain - ie. let 
the repositories dynamically add roots once a new CA goes in business 
and gains acceptance.

> For enterprise usage I doubt that end-to-end encryption is of much value
> as lost keys create too much hassles.  Most business systems are likely
> to rather use HTTPS which is easier to handle than S/MIME encryption.
HTTPS and S/MIME have different uses and benefits. If you sign a 
contract over HTTPS there is no persistent proof, whereas there is with 
S/MIME.

The problem of lost encryption keys for enterprises is already solved 
with key escrow. All the necessary mechanisms are already in place 
today. Most businesses want to be able to access their employees' 
communications anyway, so there is another reason that they use key 
escrow for encryption keys. Signing keys are of course a different 
matter and should not be escrowed.

-- 
I am the dog in dogfood

smime.p7s
Description: S/MIME Cryptographic Signature