Hi Matt, Thanks for the review! I will add a note to the draft stating that the format given in the draft is purely for the convenience of implementors and that the canonical version remains that defined in RFC8659.
Q ------------------------------ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. Ar Sul, 5 Ion 2025 am 23:12 Matt Brown via Datatracker <nore...@ietf.org> ysgrifennodd: > Reviewer: Matt Brown > Review result: Ready with Nits > > Hi, > > I've reviewed the -05 revision of this draft, noting that the -02 and -04 > revisions were already reviewed by another DNSDIR member and were in good > shape. I consider this draft ready, with one nit discussed below. > > The draft specifies how subdomains of the ".onion" Special-Use Domain Name > are > to be treated by the ACME protocol, including defining a new ACME > verification > type. Given the existing special-use designation of the .onion. name I see > minimal DNS considerations from this draft. I have not given any particular > consideration to the overall security implications of impact on the ACME > specification of this draft - leaving that to other, more qualified > directorates and reviewers. > > The most DNS relevant consideration in this draft from my reading is the > re-use > of the CAA DNS RR presentation format in section 6 for the purposes of > allowing > the CAA data (up until now fetched via DNS only) to be provided to a CA > via the > TOR protocol. > > My nit here is the re-use of a DNS RR presentation format through > redefinition > using its constituent fields, rather than by reference to the existing > format > definition in RFC8659. > > Redefining the presentation format in this way creates a synchronization > risk > if/when any future updates to the CAA RR that modify its presentation > format > occur. > > It would be clearer if the draft simply referred to the use of the CAA RR > presentation format directly (leaving its definition in RFC8659 only) > thereby > allowing any future updates to it to flow through automatically; or if > that is > not desired, explicitly note why the presentation format is being redefined > here (and perhaps consider using a different presentation format in that > case > in order to avoid confusion). > > The consequences of a future change to the CAA RR not updating this draft > would > be felt only by .onion names and the CA ecosystem rather than the DNS, so > from > a DNSDIR perspective I list this as a nit rather than a blocking issue. > > >
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
