Great. Thanks for checking on both points! Paul Wouters, if the doc is updated to add the text you suggested with Paul Hoffman’s clarification, I will do a quick re-review to mark the document ready from the dns directorate’s perspective. Please don’t hesitate to ping me if for some reason you don’t get a timely update from me.
On Thu, Jan 29, 2026, at 6:49 PM, Paul Hoffman via dnsdir wrote: > On 28 Jan 2026, at 17:36, Paul Wouters wrote: > > > On Wed, 28 Jan 2026, Ted Lemon wrote: > > > >>>> But more > >>>> importantly, "encoded as a CBOR text string" is too vague to be > >>>> interoperable. > >>> > >>> See https://datatracker.ietf.org/doc/html/rfc8949#name-cbor-data-models > >> > >> This doesn't address the point I raised at all. I get that there is a > >> definition for "CBOR text string"; the problem is that the text does not > >> specify how to generate the contents of that string. > > > > Ok, so perhaps you mean something like "A CBOR text string containg a DNS > > presentation format FQDN, using A-label > > (punycode) as per RFC5890, without trailing dot" ? > > Something like that would be a good replacement. A more specific suggestion: > > "...encoded as a CBOR text string that contains an fully-qualified domain > name with no trailing dot, where each label is an A-label as defined in > [RFC5890]". > >>>> Section 9.18 adds a new TLSA selector type, but doesn't talk about the > >>>> implications of this addition. I think this has the potential to create > >>>> a lot > >>>> of confusion, and should probably be discussed with subject matter > >>>> experts > >>>> before moving forward with this document. > >>> > >>> What makes you think so? The existing selectors are "full X509 > >>> certificate" and "SubjectPublicKeyInfo". This basically adds "full C509 > >>> certificate". (the draft now uses "C509 Certificate", but possible it > >>> should match the name of the X509 version already there, so "full C509 > >>> certificate". The selector merely tells you what type the next blob is > >>> formatted in. > >> > >> Well, as I said, I'm not an expert here. The point of raising this as part > >> of the DNS directorate review is to call it to the attention of the DANE > >> working group and make sure that it has had (or gets!) review by actual > >> experts. It does seem weird to add this new TLSA selector type and not > >> talk about the implications of adding it. However, my main reason for > >> bringing this up was the hope that someone from the DANE working group > >> could weigh in on the question. If they think this is fine, I have no > >> further objection. > > > > Sure. As I said, I think it should say "full C509 certificate" to match > > the "full X509 certificate", but I don't think anything else is > > required. > > I agree with PaulW here: the extension to DANE in this draft seems completely > clear. > > --Paul Hoffman > > -- > dnsdir mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
