Re: PKI and S/MIME

[Simon Josefsson <[e-mail]>]

Anders, you are right, it doesn't solve all problems.  However, in
some situations all you have is the email address of the recipient,
and in those situations locating the certificate through DNS is
simpler than many alternatives.  The certificate can be located
directly, like RFC 2538, or indirectly using SRV pointers to LDAP or
XKMS servers.  In either case, your ISP could add those DNS records as
yet another step in setting up an email account.

One potential advantage of storing certificates directly in DNS a'la
RFC 2538 would be that if we ever get DNSSEC, the certificate you
receive would be integrity protected.  (Whereas a SRV would only
provide you with a integrity protected name of the LDAP host.)

Regards,
Simon

"Anders Rundgren" <[e-mail]> writes:

> 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