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.
Glad you like it...
The reason is simple, S/MIME is not transparent to end users.
1) Signature
Signature is only possible by changingthe message format.
Unfortunately there are still a lot of people out there with broken, non
S/MIME capable email clients. Probably more of those than have broken email
servers. Of course at this point it is difficult to do anything about this.
2) Encryption
Encryption is a big problem for end users, it is simply not
transparent. We need to link PKI to the DNS in some way, the SRV service
looks the best choice. LDAP is not going to be the answer here, even if you
find the right LDAP server the schema issues still have to be solved. Sure
LDAP could address the problem - but only to the extent a Turing machine
could and only with changes to make LDAP aware of PKI concepts like trust
paths.
3) The end to end obsession
One of the major reasons the IETF has failled in the security space
is that the end to end principle alone does not address security issues.
Perimeter security is a major concern for enterprises.
As I have been digging into this issue I have discovered that
'end-to-end security' is actually a shiboleth. Go look at the RFCs with
security architecture design discussions and you will not find it. Clark
never applied it to security either in the naive form that has become the
received version.
What we need to do is to build specs that address multi-layer
security concerns. It should not be necessary for everyone to have a
certificate just to be able to do security. It should be possible to sign
outgoing messages at either the end user level OR the domain name level - I
only care that an email came from Merril Lynch, not that it came from Freddy
Bloggs in accounts.
4) Feature support discovery
An extension of #2. Clients should be able to advertise their
capabilities. Perhaps this is NAPTR, but I doubt it. I see NAPTR as being a
server level feature.
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.
Amen brother, Amen.
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!.
Again, I designed XKMS to allow enterprises to define their own trust
evaluations. One of the main considerations was how to support the Federal
Bridge CA, both today and in the future when there are perhaps a thousand
significant bridge CAs in operation.
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.
Also, obtain buy-in from the principal stakeholders whose help is required
to achieve deployment.
That is why the answer is XKMS and not SCVP. SCVP does not have the public
support of any of the major stakeholders. I spent a lot of time and effort
getting buy-in from Microsoft and RSA before we announced XKMS. I worked
with Entrust and Baltimore so that we could produce a specification that
they could also support.
Contrast this to what the IETF mechanism achieves, OK everyone can say what
they like. But at the end of the day you do not have the support of a major
software vendor, just the individuals in the working group.
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.
Substitute cheap. Clearly certification becomes a lot cheaper in volume.
Why could we not have organizations issue certificates
distributed via
DNS, with a trust relationship provided by DNS-SEC?
Because the working group deliberately sabotaged the spec by refusing
changes to make it possible to deploy in .com and .net.
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:
Not a good choice, very few DNS administrators deal with end users. The TTL
constants in DNS are also completely inappropriate to the problem.
Phill