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]> 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]
https://www.ietf.org/mailman/listinfo/perpass
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
