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 <james.mitch...@iana.org> 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 _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
