>>>>> "YS" == Yaron Sheffer <[email protected]> writes:
YS> I agree that storing users' public keys in DNS is weird. YS> But I also wonder about your proposal: it sounds like you're putting YS> the entire organization's list of employees on a public Web server. It wasn't my proposal; just another which was posted on the dane list. YS> Wouldn't the following be simpler and more natural than both proposals: YS> - The organization maintains its own CA, maybe just for S/MIME client certs. YS> - The CA cert is kept as a DNS record, signed by DANE. YS> - The CA cert is usage-limited, so it can be used for S/MIME only, and YS> only for addresses at this particular domain. [I suppose this is the YS> hard part. Is it allowed by X.509?] For orgs which can manage a local CA, doing so is a good idea. And I'd suggest they use it for everything which is dane-compatible. Not just s/mime. But it doesn't address the question of how correspondents can find a given address' cert or the org's ca cert. They'll need the former to send encrypted mail to the org's users, and the latter to verify sigs. Well know mappings from an email address to either a dns lookup or to the web can provide that. The dane smime draft (like rfc 2538) tries to the the former. Webfinger is an example of the latter. YS> Advantages: YS> - This would leave S/MIME unchanged. YS> - The cert validation code remains a combination of normal trust chain YS> processing plus DANE. YS> - No privacy issues: certificates are not published anywhere. YS> - Users are managed within the organization, with widely available tools. Not publishing certs means that they are unavailable for encrypting incoming mail or verifying outgoing sigs w/o some prior out of band exchange. That is reasonable for some usages, but precludes other reasonable ones. -JimC -- James Cloos <[email protected]> OpenPGP: 1024D/ED7DAEA6 _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
