[DNSOP] Re: [Ext] Working Group Last Call for draft-ietf-dnsop-rfc7958bis

[Paul Hoffman <[e-mail]>]

Thanks for the comments. They are all addressed in the revised draft coming out shortly.

--Paul Hoffman

> On Jun 26, 2024, at 13:31, James Mitchell <[e-mail]> wrote:
> 
> 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