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 _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
