Subject: RE: dissemination of public encryption certificates

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 14 Aug 2003 10:30:00 -0700

> 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

---

From: Michael Helm <[email-masked]>
Date: Thu, 14 Aug 2003 11:01:53 -0700

> software vendor, just the individuals in the working group.

Leaving aside who supports what and why, don't understand the
implied conflict between xkms and scvp.  They seem to do two 
different things -- I want to find a cert for [email-masked]
to send email to that entity; I have a cert from [email-masked] --
what is it good for?  I didn't think SCVP would help much with
the first, and I clearly don't see what XKMS would do with the
second question.  Would like a better understanding of this.

Thanks, ==mwh
Michael Helm
ESnet

---

From: [email-masked] (Julien Pierre)
Date: Thu, 14 Aug 2003 15:47:41 -0700

Philip,

 > servers. Of course at this point it is difficult to do anything about

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.

 > could and only with changes to make LDAP aware of PKI concepts like trust

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.

 > only care that an email came from Merril Lynch, not that it came from

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.

 > > there is no directory to look up from.   Global X.500/LDAP

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