On 8/29/2024 4:24 PM, Paul Hoffman wrote:
On Aug 27, 2024, at 16:46, Warren Kumari<war...@kumari.net> wrote:
Thank you very much for your comments. We've had some discussions, and the
authors will be publishing a new version in the next few days addressing these.
As you can see, we have turned in -05. We think this deals with the comments
from Petr and Mike. In the diff, you can see that we moved all things that said
what a relying party who accepts the trust anchor file MUST/SHOULD do to the
Security Considerations; this puts them in one place and gives the context for
them. We also added some text about how to do the comparison for the two fields
(referring to the specific part of RFC 4034 that they need).
Given that this is still in your (Warren's) two hands, not the WG's many hands,
let us know if you need any more changes before the assigned telegchat.
--Paul Hoffman (for the authors)
_______________________________________________
DNSOP mailing list --dnsop@ietf.org
To unsubscribe send an email todnsop-le...@ietf.org
Hi -
Took a brief look at -05. Still problems unaddressed. Section 2.2 6th
paragraph:
The validFrom and validUntil attributes in the KeyDigest element
specify the range of times that the KeyDigest element can be used as
a trust anchor.
"can be used as a trust anchor" is problematic as it appears to be
directive on the recipient. As I've said - now at least three times -
please change this language so it represents what the IANA is doing, not
what the recipient should do. Among other things, specifying a
"validUntil" date on a trust anchor and then NOT ceasing to use that
trust anchor and not "replacing" it is problematic.
Instead replace this paragraph with:
"The validFrom attribute in the KeyDigest element indicates the first
planned date that the IANA intends to start signing the root DNSKEY
RRSet with this key. Likewise, the validUntil attribute indicates the
last planned date of such signing. However, these are for planning
purposes only and relying parties should not automatically invoke a
state change on a trust anchor based on these dates as operational
considerations may result in a delay past these dates."
Section 4 - nit - generally we don't have single entry subsections.
Delete section 4.1.1 - continues to be a problem if IANA fails to
supercede a trust anchor on the planned schedule. It is directive on the
relying party in a way that could cause operational difficulties - to
wit - iana actually continuing to sign with the set of trust anchors
past their validUntil dates. There is also no such thing as "change to
a trust anchor" in DNSSEC. All trust anchors are equally valid until
revoked or removed.
Delete the third paragraph of section 5.
In section 5, replace the first sentence with:
"The intent is for the IANA to publish trust anchors using this format
at least <6> months before the first use of a new trust anchor. The
intent is also that the published document will include all DNSSEC trust
anchors for the root zone that are currently under management (e.g.
generated and loaded for use within a key signing ceremony but not
revoked) by the IANA at the time of publication."
Second paragraph - lower case the "may" - people are mostly not protocol
elements, although the DNS crowd seems to think so. Also, add "Also for
operational reasons, IANA may delay taking any trust anchor key out of
service past the dates indicated in the most recent publication of the
trust anchor file."
Please - can we avoid moving the deck chairs around again without
actually fixing anything?
Thanks - Mike
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
