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
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
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.
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.
Possibly this discussion has already occurred, but if so, I think the text in the document is a bit lacking. What is intended here?
A new option to choose from?
Do we anticipate that all DANE implementations will adopt this new format?
No - just like for adding new options in other IANA registries ?
What does it mean for there to be a CBOR-encoded certificate, but no X.509 encoded certificate?
For entities not supporting this, that there is no usable TLSA record for them. For entities supporting this, that there is a usable TLSA record for them. For clients not natively supporting C509, but supporting the conversation to X509, they should convert and then treat as a regular "full X509 certificate" selector. I guess this can all be spelled out, but seems fairly obvious to me?
Etc. I think this needs to be fleshed out before the document moves forward.
I will leave it up to the authors/WG to see if they think additional text is warranted. Paul _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
