Re: dissemination of public encryption certificates

[[e-mail] (Julien Pierre)]

Steve,

Steve Hole wrote on 08/14/2003, 10:30:

 > 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.

Yes, that's exactly the problem that prompted my questions. And it's 
coming soon to an AOL mail program near you ... Some of you may have 
heard of this new "AOL Communicator" mail program that was released in 
the last week to the masses. In fact this program already includes 
S/MIME support.
Hopefully, solving this problem doesn't necessitate new specs and 
completely new services and products, but only minor tweaks and 
clarifications of how to use the existing technology.

 > On Wed, 13 Aug 2003 19:29:53 -0700 Julien Pierre <[e-mail]>
 > wrote:
 >
 > 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.

This is supported today in Mozilla mail, Netscape 7.x mail, and AOL 
Communicator.
In fact, in our internal PKI deployment we use different keys for 
encryption and signing. This results in the issuance of two different 
certificates, one for signing and another for encryption.
The digital signature can be configured to include a different 
certificate for encryption. Look at my signature in this message and see 
if you get confused : I signed it with my corporate certificate, but I 
included a recipient Thawte encryption certificate.

 > 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.

That's right, and it's the whole problem I have been asking about. 
Exchanging unencrypted messages first, in my opinion, is not a solution.

 > 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.

Why ?

 > 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.

Can you summarize why ?

 > 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).

I think other people have pointed out that DNS itself is not suited as 
the repository for the certificates.
Since the query starts with only the e-mail address, which contains a 
userid and domain, I think it is appropriate to start the lookup in the 
DNS. There should be a standard schema to get to the appropriate LDAP 
server from the user's e-mail domain. The certificate would then be 
looked up from it. The client application could also fall back to a 
"default" LDAP server if the DNS query fails to find the appropriate 
directory.

 > > "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.

I didn't say it wasn't, I just have reservations on how it's done (see 
above).

 > 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?

Sounds good, but we have to make sure this is deployable for a lot of 
people. I don't really see how it would be.

If LDAP is used to store the certs, perhaps all a domain owner might 
have to do would be do add an entry in the DNS, either with a new record 
type, or even simpler for quicker deployment, a standard name, eg 
pki-public-ldap . This entry could be pointed to some free public 
directory if the ISP doesn't want to run it itself.

 > 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.

I think you have it backwards, cost of certification is way down on the 
list of obstacles to mass deployment of S/MIME right now. Let me mention 
some other important barriers  :

1) the general public is completely unaware that certification even 
exists. I think this is the #1 issue by far.
Many companies have been trying to raise awareness for PKI, but none 
have succeeded in getting the masses to adopt it yet.

2) the value of certification is low today because there are so few 
certified users, and encryption only works between certified people. 
This is like being one of the first one to have a telephone.

(Even worse than that, without even having a directory in existence to 
find out who else you could communicate with - this is the problem at 
stake).

3) S/MIME is too complex to use

I don't believe the first issue can be solved by any specifications or 
talk in this group, but several companies will continue to work on it. 
Hopefully they will succeed.

The first two issues are related. As more people become aware of 
certification and certified, the value of being certified will increase. 
I believe the cost of the certification will be much less of an issue 
once people realize they are paying for a something useful.

IMO, the certificate dissemination issue remains a major obstacle. Even 
if lots of people were certified today, it would still be very hard to 
know who they are and communicate with them.

The complexity of S/MIME usability is also something the group has 
impact on. The specifications heavily impact the implementation and 
usability of S/MIME client software.

 > 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.

Yes, vendors have to ship a certain set of roots. We can't just 
automagically trust every self-signed root there is. We ship with about 
a hundred roots already though. It is true Netscape has charged in the 
past for including it. Microsoft requests that your root goes through an 
independent certification process. Either way, the process costs a lot 
of money.

You aren't limited to using the roots that are shipped.
You can add your own roots if you want to trust it. All it takes is a 
couple of clicks in the client application.
If you don't like your users having to click, you can pull a Mozilla 
source tree, and add your very own root certificates and mark them 
trusted if you like. It is a simple process and I'll be happy to show 
anyone how to do it, as I have been the one checking in the roots to the 
official tree. Any ISP could do it. Any CA could do it. Any corporation 
could do that.

 > 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 :-).

All the client vendors do is provide a default trust domain, which is a 
list of well-known root certificates with trust settings. What do you 
want them to do ? Ship with no roots at all ? Automatically trust every 
single self-signed root under the sun ?

The default trust domain that ships with client software is not static. 
Like any other software setting, it can be configured. Any user is free 
to add another root and mark it trusted.
If the trust domain was static then you would have a point, but as I see 
it, you miss the point.

 > 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.

At least we agree it needs to be easy.

 > 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.)

The price figure you cite is absurdly low. Do you really, seriously 
think $250,000 to enable secure services matters much to a company with 
25 million customers ? Certainly it wouldn't matter much to a bank, 
especially since it would probably reduce certain mailing costs. I'd 
guess that even one bulk USPS communication is going to cost more than 1 
cent per recipient. I only know one ISP with 25 million customers or 
more, and I happen to work for it, but I'm not at liberty to comment 
further on the costs.

The bottom line is, running a CA is a service, and it costs money, 
probably far, far more than $0.01 per cert per year. Whether an ISP runs 
it itself or outsources it, the service is going to cost some money 
somewhere

Anyway, I think we are getting quite off-topic here. If people want to 
run a loss-leader cert service they are welcome to do so, just as 
Thawte/Verisign does. I don't know how much relevance this has to the 
mailing list. Or do you want to codify the prices of certificates into 
the RFCs  ?

 > 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.

What you are proposing is a new policy to automatically trust the 
certificate because of the security of the channel it traveled through.
But there has to be some prior trust somehow for the channel itself. I'm 
not familiar with DNS-SEC. Does it involve SSL/TLS in any way ? If so 
there would have to be prior trust on the DNS server certificate too.
All in all, I think the implicit trust is very dangerous. It is one 
thing to accept information through that channel while it is open, but 
to continue to use it after it is closed, by automatically trusting the 
certificate that was transferred, is another.
You may argue that it is better than nothing, however, a false sense of 
security may be worse than knowledge of the lack of security.

 > 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.

I don't see why the lookup has to be a 1-part lookup. It could - and 
probably should, given the size of the problem - take more than one step.

-- 
I am the dog in dogfood