Re: PKI and S/MIME

[Denis Pinkas <[e-mail]>]

Phill,

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

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

> 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:[e-mail]]
>>Sent: Wednesday, August 13, 2003 1:16 PM
>>To: Blake Ramsdell; Simon Josefsson
>>Cc: [e-mail]; '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 [e-mail] 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" <[e-mail]>
>>To: "Blake Ramsdell" <[e-mail]>
>>Cc: <[e-mail]>; "'Sean P. Turner'" <[e-mail]>
>>Sent: Wednesday, August 13, 2003 09:32
>>Subject: Re: PKI and S/MIME
>>
>>
>>
>>"Blake Ramsdell" <[e-mail]> 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
>>
> 
>