Paul, On Sep 26, 2012, at 10:56 AM, Paul Hoffman wrote:
> On Sep 26, 2012, at 1:46 AM, Ben Laurie <[email protected]> wrote: > >> On 25 September 2012 23:32, Paul Hoffman <[email protected]> wrote: >>> On Sep 25, 2012, at 12:06 PM, Dan York <[email protected]> wrote: >>> >>>> 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? >>> >>> No, because the types of content are identical. >> >> They are not, as I just pointed out in the other thread. > > Unless I missed it (certainly a possibility), what you pointed out was > different semantics for identical content. That is, where the RFC talks about > the trust anchor for the server, and chains sent by the server, we need to > change that to trust anchors used by, and chains sent by, the sending party. > No bits on the wire change, right? My comments were reacting largely to Tony's comment about the content of the TLSA record: > 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. To me it just seemed that there could be app developer confusion if in the one case the TLSA record is a digest of a certificate and in another case the TLSA record might be a full certificate. Having said that, I've now gone back and re-read RFC 6698 and seen clearly that this is all covered with the Matching Type field in section 2.1.3 and so any "DANE implementation" needs to be able to understand both the digest and the full certificate. So consider my comments withdrawn.... and thanks for the replies that forced me to deepen my understanding of the DANE protocol. :-) 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
