On 26 September 2012 15:56, Paul Hoffman <[email protected]> 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? > >>>> 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? >>> >>> That's not content, that's the request you used to get the content. >>> >>> As Ben pointed out earlier, we need to make a few changes saying "where >>> DANE talks about a chain sent by the server, this document is talking about >>> a chain sent by the other party". But the contents are the same. >> >> You could argue that all RRs merely contain bytes, so their contents >> are "the same". > > No, you can't. The TLSA RR has particular fields with particular structure. > That structure is identical in SMIMEA. > >> If they mean different things, then they're not >> _really_ the same. > > Nor do they need to be _really_ the same, just have the same format. > >> It could be that TLSA could be redrafted to fix this problem. > > It sounds like that a new RFC can update the TLSA draft. That's exactly what > we are proposing. :-)
I am more than happy for our different brands of pendantry to coexist in this case :-) _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
