All, Please find my comments below.
The draft introduces a new optional field PublicKey without providing a versioning mechanism - both current and new formats are retrieved from the same path. I have reviewed a few publicly available parsers and did not identify any obvious issues that could arise following the addition of the PublicKey element (implementations appear to key of element/tag names, concerns if any, could be memory management with the larger and unused PublicKey CDATA). I do not believe versioning is required on the understanding that IANA may revert to the previous version if necessary - there appear to be a few clients with operational dependencies on the file. Looking ahead to the addition of the PublicKey element, we discussed whether to publish the PublicKey element for historical TAs and whether we would remove the PublicKey for future-historical TAs. While we have not formalized plans, can we assume these are operational decisions to be made by IANA? If so, does the draft require text to clarify that the PublicKey may be present for some KeyDigests and that the element may be removed if previously present? A few editorial comments: The introduction says: This document describes the formats and distribution methods of DNSSEC trust anchors that have been used by IANA for the root zone of the DNS since 2010. This is not quite true given a format with the publicKey element was not possible back in 2010. The following sentence is difficult to read: If the relying party is using a trust anchor that has a KeyDigest element that does not have a validUntil attribute, it can change to a trust anchor with a KeyDigest element that does have a validUntil attribute, as long as that trust anchor's validUntil attribute is in the future and the DNSKEY elements of the KeyDigest are the same as the previous trust anchor. I think it can be removed entirely - text regarding duration of use is covered in a prior sentence - and I'm not sure what it adds. My problems with this are: 1) one does not "change to a trust anchor" following the addition of a (future?) validUntil attribute - it is the same trust anchor; 2) the "it" in "it can change" is difficult to understand, in part because of the prior issue and because it is the validUntil that is changing; 3) DNSKEY elements is not defined - it should not be the (optional) PublicKey which is most definitely a DNSKEY element. Section 2.4 Converting to DNSKEY records - A DNSKEY constructed from the KeyDigest will fail to match a published DNSKEY when the REVOKE bit is set - this doesn't create an issue for this protocol but may cause confusion during a rollover. It might be clearer to say something to the effect of the file does not provide values for DNSKEY protocol or flags - for the purpose of this mechanism, clients can assume valid trust anchors will be for protocol 3 and that the ZONE and SEP flag bits will be set. Thanks, James Mitchell Director IANA Technical Services From: Tim Wicinski <tjw.i...@gmail.com> Date: Wednesday, June 19, 2024 at 9:34 AM To: dnsop <dnsop@ietf.org> Cc: dnsop-chairs <dnsop-cha...@ietf.org> Subject: [Ext] [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc7958bis All The authors have updated the document based on some early reviews. Since this is an update from the original RFC7958, I urge folks to take a look at the diff from the original: https://author-tools.ietf.org/iddiff?url1=rfc7958&url2=draft-ietf-dnsop-rfc7958bis-02&difftype=--html [author-tools.ietf.org]<https://urldefense.com/v3/__https:/author-tools.ietf.org/iddiff?url1=rfc7958&url2=draft-ietf-dnsop-rfc7958bis-02&difftype=--html__;!!PtGJab4!-2_NDARJKP32eDL1vVFs5XXCAM9r8FoSOQvGTWqEgZO2-MrAcn2mKA-1O1nu3UJgSeAoYSvJyIIL8HJ0J_VJGUcACAA$> This starts a Working Group Last Call for: draft-ietf-dnsop-rfc7958bis "DNSSEC Trust Anchor Publication for the Root Zone" Current versions of the draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7958bis/ [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7958bis/__;!!PtGJab4!-2_NDARJKP32eDL1vVFs5XXCAM9r8FoSOQvGTWqEgZO2-MrAcn2mKA-1O1nu3UJgSeAoYSvJyIIL8HJ0J_VJ2oggHbI$> The Current Intended Status of this document is: Informational Benno will be the document shepherd Please review the draft and offer relevant comments. For WGLC, we need positive support and constructive comments; lack of objection is not enough. So if you think this draft should be published as an RFC, please say so. If you feel the document is *not* ready for publication, please speak out with your reasons. This starts a two week Working Group Last Call process, and ends on: July 3rd, 2024 thanks tim
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
