RE: dissemination of public encryption certificates

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

smime.p7s
Description: S/MIME Cryptographic Signature