RE: dissemination of public encryption certificates

[[e-mail] (Julien Pierre)]

Philip,

Hallam-Baker, Phillip wrote on 08/14/2003, 10:30:
 >
 > 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.

I don't think there is any way around that problem, the client simply 
must have at least basic MIME support to support S/MIME signed messages.
Unfortunately, there are many e-mail clients that cannot be supported, 
eg. the very basic e-mail "clients" included in some devices such as 
older cell phones.
The best that we can do is ensure that new client software going forward 
has the proper MIME & S/MIME support.

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

I think you are overly pessimistic here about the ability of LDAP to 
solve the problem. I agree with you however that a proper schema needs 
to be in place, and that is certainly a problem that hasn't been solved.

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

S/MIME signing can be implemented transparently in the way you want as 
well. Merryl Lynch could have a certificate with regular expressions in 
it, matching all of its employees. The internal Merryl SMTP e-mail 
server, perhaps setup with SSL and some basic authentication of 
employees, could automatically sign each outgoing e-mail message with 
that certificate. This really is not end-to-end at all but I believe it 
can work today. You just have to be a little creative.

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

I find it really ironic that I can lookup phone numbers for anyone 
listed in the united states, knowing such sensitive information as their 
name and physical address, through a free service like 
www.switchboard.com, but I can't look-up their e-mail certificate 
knowing their e-mail address ?
I'm sure there is lots of politics involved, but surely the logistics of 
running this service shouldn't be so much of a problem ?

-- 
I am the dog in dogfood