On Jan 28, 2026, at 03:52, Paul Wouters <[email protected]> wrote: > On Tue, 27 Jan 2026, Ted Lemon via Datatracker wrote: > >> If subjectAltName contains exactly one dNSName, the array and the int are >> omitted and extensionValue is the dNSName encoded as a CBOR text string. >> >> I think the bouncyCaps here are wrong—should be dnsName or DNSName. > > No, see https://www.alvestrand.no/objectid/2.5.29.17.html
OK, that's odd, but obviously water under the bridge. >> 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. >> Possibly this is intended to refer to RFC1035 section 5.1, the bit on >> encoding >> on page 35. If so, you should say so explicitly. > > That section is about zone files, so I don't think it applies. I agree, however, the point is that a domain name can contain characters that would confound an attempt to parse the domain name from its string representation if copied blindly out into a string representation. E.g. if one of the labels includes a '.' character. I know that many DNS implementations, including those I've written, contain code to generate and parse a "presentation format" for the domain name that is roughly in line with that section of the RFC. Unfortunately I don't think there is a good RFC reference for this that is specific to domain names and explicitly describes the presentation format for domain names with non-ASCII or special characters in labels; the reference to RFC1035 is the best I can do, and I think could be made to work. But not describing this transformation at all seems like begging for interoperability issues down the line. >> 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. _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
