Hi, PR#304 has been updated after some off-list discussion:
* No added restrictions to dNSName. It is stated in Section 3 "the certificate content is adhering to the restrictions given by [RFC5280<https://www.rfc-editor.org/rfc/rfc5280>]” and what this draft does is essentially to encode that as CBOR. * Update of IANA sections 9.17 and 9.18 based on proposals from Viktor Dukhovni [1] (while maintaining some changes made due to previous review comments). Let us know if there are still remaining issues. Göran [1] https://mailarchive.ietf.org/arch/msg/dane/MA_vM8wvaTrXrCExMQi4UiD2gRg/ From: Göran Selander <[email protected]> Date: Friday, 30 January 2026 at 09:12 To: Ted Lemon <[email protected]>, Paul Hoffman <[email protected]>, Last Call <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: [dnsdir] Re: [dane] draft-ietf-cose-cbor-encoded-cert-16 ietf last call Dnsdir review I tried to capture the points made here in this PR: https://github.com/cose-wg/CBOR-certificates/pull/304/changes Please let me know if I missed anything. Thanks! Göran From: Ted Lemon <[email protected]> Date: Thursday, 29 January 2026 at 18:59 To: Paul Hoffman <[email protected]>, Last Call <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: [dnsdir] Re: [dane] draft-ietf-cose-cbor-encoded-cert-16 ietf last call Dnsdir review 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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
