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(_at_)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" <steve(_dot_)hole(_at_)messagingdirect(_dot_)com>
To: "Julien Pierre" <jpierre(_at_)netscape(_dot_)com>
Cc: <ietf-smime(_at_)imc(_dot_)org>
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
<jpierre(_at_)netscape(_dot_)com>
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
joe(_at_)foobar(_dot_)com 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: holes(_at_)aciworldwide(_dot_)com
Phone: 780 424 4922