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
