Subject: RE: PKI and S/MIME

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

There are two ways the problem may be solved.

The simplest solution is that the domain owner appoints a single CA for the
entire zone and simply directs all XKMS requests to the XKMS server run by
the CA.

The second solution is that the domain owner runs a non-authoritative Locate
service locally. XKMS clients that register certificates with the CA of
their choice can then in turn register the certificate issued by the CA with
their local XKMS locate service.

In this second application the XKMS service may choose to impose some form
of validation constraint on the certs that it accepts. For example only
accepting certs from a limited number of CAs - or it may not.

Incidentaly XKMS may also be used to register PGP keys or keys in
alternative PKIs. It is a key centric PKI, not a token centric one.

Storing end-user certs or keys in the DNS is a lousy idea for several
reasons. First the DNS is a machine configuration infrastructure and not a
user configuration infrastructure. Storing user information in the DNS
requires an administrative interface with a new constituency. Ain't going to
happen. Moreover the DNSSEC spec itself is still not in a deployable state,
or at least the IETF version of it is not.

Storing certificates in LDAP is a lousy idea. LDAP is an internal enterprise
resource. Enterprises are not going to expose LDAP data in border
directories in significant numbers. It is not just the security issue, cost
plays a factor. LDAP is not a simple protocol, it is would be completely
overspecified for the job of a cert repository if the features LDAP provided
were relevant to the task.

We considered certs in the DNS and LDAP before designing XKMS and rejected
them. Both technologies have been available for at least 6 years with
negligible uptake. We needed a new protocol because there was no acceptable
existing solution. Sometimes designing a new protocol from scratch is better
than attempting to use an inappropriate one.

		Phill

> -----Original Message-----
> From: Anders Rundgren [mailto:[email-masked]]
> Sent: Wednesday, August 13, 2003 1:16 PM
> To: Blake Ramsdell; Simon Josefsson
> Cc: [email-masked]; 'Sean P. Turner'
> Subject: Re: PKI and S/MIME
> 
> 
> 
> Simon,
> I respect your work with DNS for location but is this really
> universal?  How about my [email-masked] cert
> issued by VeriSign?  Would it be appropriate to require ISPs
> like Telia to maintain a directory pointing to various TTP CAs?
> 
> Or should ever domain-owner become a CA?
> 
> Anders
> 
> ----- Original Message ----- 
> From: "Simon Josefsson" <[email-masked]>
> To: "Blake Ramsdell" <[email-masked]>
> Cc: <[email-masked]>; "'Sean P. Turner'" <[email-masked]>
> Sent: Wednesday, August 13, 2003 09:32
> Subject: Re: PKI and S/MIME
> 
> 
> 
> "Blake Ramsdell" <[email-masked]> writes:
> 
> > There have been a number of messages recently about the use 
> of PKI with
> > S/MIME, and the concerns about that.  I like to think that we're all
> > pretty much in agreement that we've established a consistent,
> > interoperable practice for the actual syntax and contents of S/MIME
> > messages, as well as a reasonable cut of a certificate 
> syntax profile
> > for end-entity certificates.
> >
> > Should there be a profile for certificate usage 
> (certificate repository,
> > distribution and revocation checking) that is specific for 
> our problem
> > domain?  That is, select relevant other work and profile it 
> for use in
> > the S/MIME interpersonal messaging domain?  I would imagine 
> that this
> > would be a new draft, start with a summary of the requirements, and
> > progress to profiles of relevant standards.
> >
> > It's also not clear if this is something to discuss in this working
> > group, or somewhere else.
> >
> > Comments?
> 
> Since in practice, addressing this problem would help in getting
> "opportunistic S/MIME" to work, I believe it would be useful to
> address it.  ("Opportunistic S/MIME" means to be able to encrypt
> messages to someone you don't have a prior trust relationship with,
> simply to provide encryption of data.  There is a man in the middle
> attack, of course, but in practice the result often isn't worse than
> not using S/MIME.)
> 
> A strawman at a requirement:
> 
> * Be able to locate a certificate for a Internet user given only her
>   email address.
> 
> I should mention that this has been discussed several times before, in
> various fora, for similar applications (e.g., OpenPGP, IPSEC, SSH), so
> there is prior work to look at how to design this.  To do even more
> self-promoting, I'd again like to mention the following draft:
> 
> http://josefsson.org/draft-josefsson-pkix-dns.txt
> 
> which do discuss it for S/MIME context as well.  I don't have an
> opinion on if this WG is the proper place for it.
> 
> Regards,
> Simon
>

---

From: Steve Hole <[email-masked]>
Date: Thu, 14 Aug 2003 11:09:47 -0700

On Thu, 14 Aug 2003 05:30:34 -0700 "Hallam-Baker, Phillip" 
<[email-masked]> wrote:

> negligible uptake. 

This is true for LDAP, but is it true for DNS?   What specific "deploy 
certs in DNS" technology are you talking about?

> We needed a new protocol because there was no acceptable

Fair enough.  Then you better figure out how, exactly, you are going to 
deploy your new protocol for use with S/MIME.   Specifically, you must do 
what Blake suggests and write a profile for use.    In particular, if I'm 
sitting in my Netscape client and I want to send an encrypted message to 
"Blake Ramsdell <[email-masked]>" without any prior contact, how
am I going to do that?

That profile must describe:

1.  The collection of services and publication points for accessing the 
information.

2.  The approach that a client must take to do the lookup and resolve the 
requested certificate.

I'm sure that you can do it.   I'm also sure that you are going to have to
do *something* with DNS because how are you ever going to find your xkms 
server?   If there is an external xkms global hierarchy planned, then 
pardon me if I'm dubious, but who is going to run the root?   (Hint: I'm 
unlikely to like *any* answer to that last question :-).

Chers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide

Email: [email-masked]
Phone: 780 424 4922

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 26 Aug 2003 17:53:27 +0200

Phill,

> accepting certs from a limited number of CAs - or it may not.

This specification does not provide this level of details.

I have read the XKMS document (I would not call it " a specification" - see 
later) and provided 35 comments during the last call period.

It would have been appropriate to provide these kinds of details but 
apparently the XKMS WG decided to be as general as possible, to provide 
*examples* instead of *specifications* and therefore the XKMS document is 
left open to many different interpretations.  :-(

This may be what some vendors are looking for: claiming *compatibility* with 
XKMS, while in reality each vendor will be non-interoperable with any other 
vendor and will have its own concept of trust (hidden and different from any 
other vendor).

Denis