RE: PKI and S/MIME

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:anders(_dot_)rundgren(_at_)telia(_dot_)com]
> Sent: Wednesday, August 13, 2003 1:16 PM
> To: Blake Ramsdell; Simon Josefsson
> Cc: ietf-smime(_at_)imc(_dot_)org; '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 anders(_dot_)rundgren(_at_)telia(_dot_)com 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" <jas(_at_)extundo(_dot_)com>
> To: "Blake Ramsdell" <blake(_at_)brutesquadlabs(_dot_)com>
> Cc: <ietf-smime(_at_)imc(_dot_)org>; "'Sean P. Turner'" 
> <turners(_at_)ieca(_dot_)com>
> Sent: Wednesday, August 13, 2003 09:32
> Subject: Re: PKI and S/MIME
>
>
>
> "Blake Ramsdell" <blake(_at_)brutesquadlabs(_dot_)com> 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