On Sep 24, 2012, at 7:32 PM, Tony Finch wrote: > * Would sharing an RRtype lead to useful code sharing between S/MIME and > TLS implementations? > >> Reuse of TLSA RR by a protocol means subscribing to supporting new >> entries in the above registries and even allowing new entries in there >> that only make sense in one context. > > TLS is about authenticating peers. S/MIME is about encryption as well as > verifying signatures. So I would expect TLS records to be more about > digests of certificates (for brevity) whereas S/MIME records to contain > public keys or entire certs.
As I've been reading this whole conversation I've been struggling with this last kind of point in my brain, mostly because I think of this not in terms of "Using DANE with S/MIME" but rather in terms of "Using DANE with $foo" where S/MIME is merely one of hopefully many different protocols that could work with DANE. (My own personal interest, coming from the VoIP space, is in seeing how it might someday work with SIP.) I keep coming to three questions: 1. What is the easiest option for developers creating applications? 2. What is the easiest option for infrastructure operators who may be barriers to having those applications work? 3. What is the easiest option for DNS hosting providers where DNS records may be entered? My worry with #2 is that if we have a proliferation of RRtypes for each value of $foo, we'll wind up with a situation where some infrastructure components (ex. aggressive firewalls) may need to be changed to allow each RRtype to be allowed through. Similarly for #3, a graphical user interface where people enter records would need to be changed to support each new RRtype. Some DNS hosting providers might do this quickly, some wouldn't. Either way it's work they have to do. Sticking with a single RRtype for any "DANE" usage would make these parts far simpler. Get them to support the "TLSA" record and they're done. Likewise, for application developers, the use of a single RRtype would potentially allow sharing of code between different $foo implementations. BUT... to Tony's last point, are we in fact making it *harder* for developers by overloading the TLSA RRtype with different types of content? Or is that adequately addressed by having the second left-most label in the domain name (ex. "_smimecert") be the way that a developer would know what is in the TLSA RR and therefore how it should be processed? Still pondering all this, Dan -- Dan York [email protected] http://www.danyork.me/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
