Re: dissemination of public encryption certificates

["Anders Rundgren" <[e-mail]>]

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?  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@yourdomain to get it automatically published.
No apparent need for CAs and associated root and path validation
for encryption certificates.

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.

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.

Anders

----- Original Message ----- 
From: "Steve Hole" <[e-mail]>
To: "Julien Pierre" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, August 14, 2003 19:30
Subject: Re: dissemination of public encryption certificates




Well, for the first time in a long time my interest is up on this 
list :-).    What a wonderful topic!   General purpose use of 
S/MIME by the masses on the Internet.   Why hasn't it happened and what 
can we do about it.

Before you read on, be assured that it is the large scale use of S/MIME 
that the following diatribe is focused on.

On Wed, 13 Aug 2003 19:29:53 -0700 Julien Pierre <[e-mail]> 
wrote:

> If you send an email today, you can simply sign it and include your 
> certificate in the signature. If you just sign all your mail, then all 
> you always disseminate your certificate. So in what situations does this 
> new MIME extension certificate lookup help ? I suppose this extension 
> would be shorter than a digital signature. However it would also be much 
> less secure.

This highlights one of the key issues.   It is easy enough to exchange 
keys simply by sending a signed message, but there are some significant 
barriers:

1.  What if your encryption key is separate from your signing key.   This 
is not only common but considered good security practice.   How does one 
go about exchanging/discovering the encryption key for the new party you 
want to exchange mail with.

2.  Timeliness of the key exchange.   The problem with mutual signing 
exchange is that the other person has to respond to you.  What if you just
want to send them an encrypted load right off the start.   You can't 
really do it.

The solution is (and always has been) to do a lookup.  The problem is that
there is no directory to look up from.   Global X.500/LDAP directories are 
*never* going to happen.

There is only one choice -- DNS.   I (and Steve Kille and others) have 
been flogging LDAP directories and working on LDAP/X.500 interconnects for
a decade.   Global X.500/LDAP isn't going to happen in our lifetime.

> The case I originally asked about is :
> neither party has exchanged any e-mail yet, but they know each other's 
> e-mail address. They want to communicate securely. How do they avoid or 
> bypass the initial insecure e-mail exchange ?

Precisely.   They must be able to do a DNS lookup for the information 
either as a direct data return or a reference to a secondary storage 
service, which absolutely could and probably should be LDAP.   To 
work in practice I think that it should be possible to get a direct pull 
from the DNS so that organizations are not required to deploy an LDAP 
directory and all that goes along with it (much as that pains me).
 
>  > In summary I think that a certificate-independent configuration
>  > of e-mail clients would be more universal than "fishing" in
>  > domains as the user domain and issuer domain may be entirely
>  > disjunct.
> 
> "Fishing" in domains as you say would be independent of e-mail client 
> configuration for the most part (it could just be turned on or off).

Actually, I think that "fishing" is an entirely appropriate thing to do.  
The worst that can happen is that don't find the cert your looking for.   
Trust issues MUST be dealt with, but certificate trust chains and 
approaches are both well understood. 

The best that can happen is that suddenly I can go and find a cert for 
[e-mail] with a simple DNS query.  BEAUTIFUL!   Why wouldn't I want 
to do that?

This does lead very nicely into my second (and quite separate) issue in 
this area -- the "trusted ROOT certificate".   Julien has provided superp 
leading commentary here.
  
> You correctly point out that in most cases the user's domain and cert 
> issuer domain are disjoint. This is especially true of e-mail users 
> whose ISP isn't a CA (99.9% of them right now). 

Exactly.   Why?   Because it costs TOO MUCH.   The only acceptable cost 
for most ISP's is zero because of the volume of users.   Cost of 
certification is, pure and simple, the primary barrier to the general use 
and deployment of S/MIME on the Internet.

The reason for the cost is that the mechanism for establishing root trust 
is determined solely by the set of ROOT certificates distributed by the 
client vendor -- of all things!.   Thus only those organizations that can 
afford to pay the client vendor -- of all things! -- to be included in 
their "special trusted root certificate club" get to have "trust".   Which 
means that you MUST buy certs from one of the club members.  Doesn't THAT 
just suck.   Nice business if you can get it.

<qualification>
Yes I know about free thawte certs.   I know that any root issuer must be 
secure and provide good protection from having roots keys compromised etc. 
I agree that anyone who issues certificates should be required to be 
secure. I understand that there is risk to the client vendor if they 
report trust in a cert that has been compromised at the root.

Regardless, to have this power rest in the hands of the client vendor is 
ludicrous.   Why should I trust that Microsoft can evaluate the security 
and trustworthiness of "Joe's CA Service" to be a valid issuer.   I'm not 
saying they are unqualified to do so, but I'm a lot more likely to trust a
self signed "Bank of America" certificate issued on it's own behalf and 
obtained from a reliable source, than I am a third party software vendor 
or CA Verisign (not that there's anything wrong with either Microsoft or 
Verisign :-).
</qualification>

The issue comes down to trust brokering.   I just don't think that it is 
working for the *general* mass consumer Internet.   It clearly does work 
for closed communities within the Internet, but it isn't scaling.   
Period.  If we want generalized S/MIME usage throughout the Internet we 
need to think of some mechanism that is:

1.  Easy to deploy.   The track record for the Internet stongly indicates 
that this means that there are freeware versions of software that will 
support the deployment.   This includes both the key management and 
publication software and the usage (client) software. 

2.  Free.   Those who "own" the vast majoritiy of the user population on 
the Internet are ISP's.   They have almost no margin and simply cannot 
afford to pay for certification.  Also (and more importantly IMHO) is the 
desired for businesses to touch their customers.   These are HUGE volume 
relationships in which there are virtually no economically viable ways of
establishing bidirectional trust.   A cert price of $0.01 a year is too 
much if your customer population is 25 million people (banks, utilities, 
etc.)

Why could we not have organizations issue certificates distributed via 
DNS, with a trust relationship provided by DNS-SEC?  That is, you can 
trust that the DNS node your are dealing with is legitimate because they 
have deployed DNS-SEC (which everyone should do anyway for a host of other
security reasons) and the keys that are located within the DNS hierachy 
are legitimate.

I can then lookup certs based on mail address (duh!), where the mail 
domain source is trusted because of DNS-SEC.   This trust relationship 
could be either:

implicit -- the issuer domain location is trusted therefore any keys 
published there are trusted,

explict -- the issuer provides a root signing key which is in turn signed 
by their DNS-SEC key.

There are a number of observations that can be made about this approach:

1.  The security provided by the approach is probably not as strong as the
full commercial CA approach.   I contend "so what".   It's better than 
nothing and Pretty Good (pun intended).  The average user doesn't need 
military grade security.   The average bill issued by the local telephone 
utility doesn't need military grade security.   Think of the vast number 
of paper documents that need only Pretty Good security and trust to be 
useful (292 Trillion a year in the US -- it's my business and I happen to 
know).  All we need is some security to make that paper go away forever.

2.  Some extensions to bind and a new CSP for Windows would get a large 
number people going in a hurry.   Openssl with an HSM card and some 
reasonable security policy has an organization running pretty quickly.

> The only solution for 
> these users is some sort of universal registration service. 

Yup.

> This implies 
> the existence of some sort of free worldwide directory service (LDAP) 
> that would resolve e-mail addresses to certificates ... And clients 
> would need to be (automatically?) configured to do look ups in it.

Well, even though I would love it if it was LDAP, it isn't going to 
happen.   DNS is the only game in town for global directory service.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide

Email: [e-mail]
Phone: [phone]