Re: [dane] Reusing TLSA

[Ben Laurie <[e-mail]>]

On 26 September 2012 15:56, Paul Hoffman <[e-mail]> wrote:
> On Sep 26, 2012, at 1:46 AM, Ben Laurie <[e-mail]> wrote:
>
>> On 25 September 2012 23:32, Paul Hoffman <[e-mail]> wrote:
>>> On Sep 25, 2012, at 12:06 PM, Dan York <[e-mail]> 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 :-)