Hi Karl,
I don't understand how this relates to TLS. S/MIME traffic is
self-protected and does not need to be transported over TLS. S/MIME is
also independent of SMTP.
But yes, if you can store a self-signed *CA* certificate in your DNS
zone, then you should be able to pull it off.
Thanks,
Yaron
On 09/16/2013 08:45 AM, Karl Malbrain wrote:
Yaron,
From what I've learned about DANE, domain owners can publish their own
self-signed server certificate through the DNS system. By using TLS
strong authentication, the S/MIME client doesn't need to have the
server's certificate checked against a CA. Rather the S/MIME layer
needs to match the DANE delivered certificate with the certificate sent
by the server during the TLS negotiation. This is a very small change to
the S/MIME to TLS protocol layer interface to query from TLS the server
certificate presented, and a similar change to the SMTP to S/MIME
interface to pass along the DANE delivered certificate along with the
server IP address.
Unfortunately, I'm not a TLS nor an S/MIME expert so I can't specify the
exact interface changes needed to utilize strong authentication in the
TLS interface to S/MIME, or the SMTP interface to S/MIME. Perhaps
someone who knows what they are talking about in this area can help.
Karl Malbrain
*From:* Yaron Sheffer <[email protected]>
*To:* James Cloos <[email protected]>
*Cc:* [email protected]; Stephen Farrell <[email protected]>
*Sent:* Sunday, September 15, 2013 11:08 AM
*Subject:* Re: [perpass] Why Yaron can't encrypt: S/MIME in the real world
Hi Jim,
I agree that storing users' public keys in DNS is weird.
But I also wonder about your proposal: it sounds like you're putting the
entire organization's list of employees on a public Web server.
Wouldn't the following be simpler and more natural than both proposals:
- The organization maintains its own CA, maybe just for S/MIME client certs.
- The CA cert is kept as a DNS record, signed by DANE.
- The CA cert is usage-limited, so it can be used for S/MIME only, and
only for addresses at this particular domain. [I suppose this is the
hard part. Is it allowed by X.509?]
Advantages:
- This would leave S/MIME unchanged.
- The cert validation code remains a combination of normal trust chain
processing plus DANE.
- No privacy issues: certificates are not published anywhere.
- Users are managed within the organization, with widely available tools.
Thanks,
Yaron
On 09/15/2013 07:58 PM, James Cloos wrote:
>>>>>> "YS" == Yaron Sheffer <[email protected]
<mailto:[email protected]>> writes:
>
> YS> S/MIME with DANE would alleviate this problem if organizations were
> YS> allowed to generate their own certificates, including email certs,
> YS> and have them chained to the DNS root of trust. I don't know if DANE
> YS> supports this usage scenario by default.
>
> draft-ietf-dane-smime-02.txt exists.
>
> Webfinger may be a better choice, though. It is defined in
> draft-ietf-appsawg-webfinger-18.txt.
>
> Details on how to store public keys in webfinger are not yet specified
> in any draft, afaics.
>
> Dane tlsa records of course can be used to secure the the webfinger uri.
>
> If one does that, the steps to find or verify an smime or pgp public key
> include:
>
> Convert the email address to a webfinger uri
>
> Do the a/aaaa and tlsa lookups on the hostname in that uri
>
> If those dnssec-verify, retrieve the uri
>
> Find the public key (or a link to the public key) in the json reply
>
> The trust path, then, is rooted with the DS record for the dns root,
> follows the dnssec path to the rrsigs for the a/aaaa and tlsa records
> for the webfinger uri and trusts the content of the data retrieved from
> the uri on the basis that it trusts the location of the uri.
>
> That seems a bit brittle, but not any worse than trusting a path from
> some random ca of which one has never heard. Or a path through a WoT
> involving names/identifiers with which one is not familiar.
>
> And http serves large blobs better than dns does.
>
> -JimC
>
_______________________________________________
perpass mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/perpass
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
