Hi all, Nice document. Some comments/nits:
Section 2.2 ----------- OLD The Zone element in the TrustAnchor element states to which DNS zone this container applies. The root zone is indicated by a single period (.) character without any quotation marks. This is underspecified w.r.t. to format, for labels containing dots. But, the whole document is about the root (it's even in the title), and I wonder why the Zone element is there in the first place. Instead of fixing the Zone element format, why not just drop the whole Zone element? OLD The TrustAnchor element contains one or more KeyDigest elements. Each KeyDigest element represents the digest of a DNSKEY record in the zone defined in the Zone element. This appears to imply that a digest appearing here is always of a DNSKEY record that is present in the root zone. This does not seem to necessarily apply to retired keys. Also, on page 24 of the recent Root Zone Algorithm Rollover Study [1], it is noted that
The design team expects that IANA will follow a similar process for an algorithm rollover; that is, to prepublish the new key as a trust anchor on the IANA website before publishing the DNSKEY in the DNS
This also seems to be at odds with the above quote from the draft. So, how about the following: NEW The TrustAnchor element contains one or more KeyDigest elements. Each KeyDigest element represents the digest of a past, current, or potentially future DNSKEY record ofthe zone defined in the Zone element. [1]: https://www.icann.org/en/system/files/files/root-zone-algorithm-rollover-study-23may24-en.pdf OLD The id attribute in the KeyDigest element is an opaque string that identifies the hash. Is the id attribute expected to be unique within the XML file? If so, does this also apply if the same digest is re-published with an added validUntil attribute, or even published twice with different validity ranges? Also, if two digests (of different hash type) are published for the same key, do those KeyDigests share an id? This aspect uncovers a structural issue, because the public key is not really an attribute of the key digest; rather, they are in a 1:n relationship. I am wondering if it would be better to move the PublicKey element out of the KeyDigest element, by allowing any number of them to be direct children of TrustAnchor, with the relevant key identified by its keytag and/or validFrom attribute. This would require the schema to be updated as follows: start = element TrustAnchor { attribute id { xsd:string }, attribute source { xsd:string }, element Zone { xsd:string }, keydigest+ publickey* } keydigest = element KeyDigest ... publickey = element PublicKey { attribute id { xsd:string }, attribute keytag { xsd:nonNegativeInteger { maxInclusive = "65535" } }, // or validFrom xsd:base64Binary } The uniqueness concern is simplest addressed by adding "uniquely within the XML file" or something. Howeve, it's surprising then that two digests that relate to the same key have different IDs, and I think the structural change would be cleaner. (This would then require no two keys to be published for the root with the same keytag and/or validFrom). OLD 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 agree with James' comments on this one. Specifically, I don't know what "DNSKEY element" means here. Mostly, I stumbled over "it can change". Who changes it? - IANA, as explained in Section 5? Then, why is the sentence qualified with "If the relying party is using ..."? - Or is the relying party making some change? In that case, the restriction ("as long as ...") conflicts with Section 3.2, which says: "A validator operator can choose whether or not to accept the trust anchors described in this document using whatever policy they want." Section 2.5 ----------- OLD <!-- Note that these trust anchors are fictitious. --> I like that the comments have made it into examples! I believe this was also a suggestion that came up while developing [1]. For the still-valid key, even if it's just an example example, I suggest not to use any signing and digest algorithm that are no longer fully recommended by RFC 8624. (This applies to both algorithm 5 and digest type 1.) Section 3.2 ----------- Like John, I'm not sure about the CMS mechanism, but I don't feel strongly. Perhaps some more about bootstrapping that trust could be said, or declared out of scope? At least a link to something that talks about that CA would be useful. OLD If a system retrieving the trust anchors trusts the CA that IANA uses for the "data.iana.org" web server, HTTPS SHOULD be used instead of HTTP in order to have assurance of data origin. Does this really mean that if I don't trust the CA, then I should be using HTTP? How does that make things any better? Section 4 --------- "IANA- issued" --> "IANA-issued" Thanks, Peter On 6/19/24 18:32, Tim Wicinski wrote:
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 <https://author-tools.ietf.org/iddiff?url1=rfc7958&url2=draft-ietf-dnsop-rfc7958bis-02&difftype=--html> 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/ <https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7958bis/> 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
-- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
