Thanks for the edit on our document. Here are my notes on the visible changes, then answers to your questions. The other authors will chime in on their own.
--Paul Hoffman On Jan 6, 2025, at 15:46, [email protected] wrote: > 1) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on https://www.rfc-editor.org/search. --> KSK > 2) <!-- [rfced] The following sentence appeared in RFC 7958, but we question > if > "can be used by [RFC5011]" could be improved. Please review. > > Original: > This document describes one way to establish an > initial trust anchor that can be used by [RFC5011]. > > Perhaps: > This document describes one way to establish an > initial trust anchor that can be used by the mechanism defined > in [RFC5011]. > --> Thanks, that's better. > 3) <!-- [rfced] How may we update the text starting with "but the basic > idea.." > to improve clarity? > > Original: > The format of the entity differs in different systems, but > the basic idea, the decision to trust this entity is made outside of > the system that relies on it, is common to all the common uses of the > term "trust anchor". > > Perhaps: > The format of the entity differs in different systems, but > the basic idea that the decision to trust this entity is made outside of > the system that relies on it is shared by all the common uses of the > term "trust anchor". > > Or: > The format of the entity differs in different systems, but > all common uses of the term "trust anchor" share the basic idea that > the decision to trust this entity is made outside of the system that > relies on it. > --> The second option ("Or:") is much better. > 4) <!-- [rfced] In the second sentence below, would it be helpful to specify > which element is in presentation format? The first sentence mentions two > elements (Zone and TrustAnchor). > > Original: > The Zone element in the TrustAnchor element states to which DNS zone > this container applies. The element is in presentation format as > specified in [RFC1035], including the trailing dot. The root zone is > indicated by a single period (.) character without any quotation > marks. > --> Good catch. The second sentence should start "The Zone element is in...". > 5) <!-- [rfced] We have a couple of questions about this text: > > Original: > Each KeyDigest element represents the digest of a past, current, or > potential future DNSKEY record of the zone defined in the Zone > element. The values for the elements in the KeyDigest element are > defined in [RFC4034]. The IANA registries for these values are > described in [RFC9157]. > > a) Second sentence above - RFC 4034 mentions "DNSKEY", and we see a number of > values mentioned throughout that document; however, we do not see > "KeyDigest". Will readers know which values/elements in the KeyDigest element > are defined in RFC 4034? Would it be helpful to specify these or point to a > specific section in RFC 4034? KeyDigest is a term in this document, not in RFC 4034. I think readers will understand that the values in KeyDigest comes from the definition of the DNSKEY in RFC 4034. I don't see a way to make this clearer without making it much longer. > b) Last sentence above - We see several registries mentioned in RFC 9157 (see > notes below). Would it be helpful to specify which registries this sentence > refers to? We see references to RFC 4034 in some of these registries but not > all. > > These registry groups are mentioned in Section 4 of RFC 9157: > > - "Domain Name System Security (DNSSEC) NextSECure3 (NSEC3) Parameters" > (https://www.iana.org/assignments/dnssec-nsec3-parameters) > - "DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" > (https://www.iana.org/assignments/ds-rr-types/) > > These registries within the above registry groups are also mentioned: > > - DNSSEC NSEC3 Flags > - DNSSEC NSEC3 Hash Algorithms > - DNSSEC NSEC3PARAM Flags > - Digest Algorithms > > We also see that Section 3 of RFC 9157 includes a citation to the following > registry in the OLD/NEW text, but we had to look at RFC 8624 to see the name > of the registry: > > - [DNSKEY-IANA] - "Domain Name System Security (DNSSEC) Algorithm Numbers" > (http://www.iana.org/assignments/dns-sec-alg-numbers) > --> We only mean the Digest Algorithms registry. No reader would be confused about this, but you can specify it anyway. > 6) <!-- [rfced] FYI - A normative reference to the XML specification has been > added because this document contains XML. We placed the citation in the > following sentence in Section 2.3. Please review and let us know if you > prefer a different phrasing or placement. > > Original: > The following is an example of what the trust anchor file might look > like. > > Updated: > The following is an example of what an XML [W3C.REC-xml11-20060816] document > for a trust anchor might look like. > > Note: For more information, please see the IESG statement on "Guidelines for > the Use of Formal Languages in IETF Specifications" > (https://ietf.org/blog/guidelines-use-formal-languages-ietf-specifications/, > specifically, the following: "The use of a language requires a reference to > the specification for that language. This reference is normative, and needs to > fulfil the usual requirements for normative references (Section 7 of RFC > 2026)." > --> Shouldn't that reference be at the first use of "XML", namely the first paragraph of section 2? > 7) <!-- [rfced] Please confirm that "ttime" (rather than "time") is correct > here. > > Original: > The full public key is only given for the trust anchor that > does not have a validFrom ttime in the past. > --> That was a typo on our part. It should indeed be "time". > 8) <!-- [rfced] FYI - We updated "the one that would have" as follows in these > sentences. Let us know any concerns. > > Original: > The potential > third record, the one that would have included the key tag 19036, is > already invalid based on the validUntil attribute's value and is thus > not part of the trust anchor set. > ... > One potential > second record, the one that would have been based on the key tag > 19036, is already invalid based on the validUntil attribute's value > and is thus not part of the trust anchor set. > ... > The other potential > second record, the one that would have been based on the key tag > 38696, does not contain the optional publickeyinfo named pattern and > therefore the DNSKEY record for it cannot be calculated. > > Updated: > A potential > third record, one that includes the key tag 19036, is > already invalid based on the validUntil attribute's value and is thus > not part of the trust anchor set. > ... > A potential > second record, one based on the key tag > 19036, is already invalid based on the validUntil attribute's value > and is thus not part of the trust anchor set. > ... > Another potential > second record, one based on the key tag > 38696, does not contain the optional publickeyinfo named pattern; > therefore, the DNSKEY record for it cannot be calculated. > --> Those are fine and easier to read than what we had. > 9) <!-- [rfced] FYI - We added <eref> to the URLs in the following sentences, > which means that they are now hyperlinked in the html and pdf outputs. Please > let us know any concerns. > > Original: > The URL for retrieving the set of hashes in the XML file described in > Section 2 is <https://data.iana.org/root-anchors/root-anchors.xml>. > ... > The URL for a detached CMS signature for the XML file is > <https://data.iana.org/root-anchors/root-anchors.p7s>. > --> Those are OK. However, I still hate the fact that the URLs get split across lines in the text output. Windmill-tilting, I know. > 10) <!-- [rfced] In these sentences, "data.iana.org" appears both with and > without > quotation marks. We updated to use quotation marks for both > instances. Also, should "data.iana.org" be a hyperlink (i.e., use > <eref>)? We see that it resolves to https://www.iana.org/. > > Original: > Currently, the CA used for data.iana.org is well known, > that is, one that is a WebTrust-accredited CA. 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. > > Updated: > Currently, the CA used for "data.iana.org" is well known, > that is, one that is a WebTrust-accredited CA. 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. > --> Quotation marks are fine. It **absolutely must not** be changed to a URL. Certificates are given for domain names, not for URLs. > 11) <!-- [rfced] Please verify that no IANA actions are needed. For example, > confirm that no action is needed per the following text (e.g., listing > this document as an additional reference for id-mod-dns-resource-record > or marking the registration as obsolete). > > Original: > [RFC7958] defined id-mod-dns-resource-record, value 70, which was > added to the the "SMI Security for PKIX Module Identifier" registry. > This document no longer uses that identifier. > --> This question is confusing. There is a long IANA Considerations section that lists IANA actions. No action is needed for the fifth paragraph because, as it says, the document no longer uses that identifier. > 12) <!-- [rfced] For the following reference entry, would it be helpful to > include > the direct URL and date for the practice statement? > > Original: > [DPS] Root Zone KSK Operator Policy Management Authority, > "DNSSEC Practice Statement for the Root Zone KSK > Operator", n.d., <https://www.iana.org/dnssec/procedures>. > > Perhaps: > [DPS] Root Zone KSK Operator Policy Management Authority, > "DNSSEC Practice Statement for the Root Zone KSK > Operator", March 2024, > <https://www.iana.org/dnssec/procedures/ksk-operator/ksk- > dps-20240315.html>. > --> No, please don't. The DPS is updated regularly, and giving a date could make a reader think that the information is no longer valid in newer versions of the DPS. > 13) <!-- [rfced] FYI - We made a few changes to the list in Appendix A > ("Changes > from RFC 7958") to create parallel structure. Let us know any concerns. > --> Yep, those were great, thanks. > 14) <!-- [rfced] Sourcecode > > a) We see that type="Zone" is used for some sourcecode > elements. This type does not appear on the current list of preferred > values for the type attribute: > > https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types > > Would you like to remove type="Zone"? It is acceptable to leave the "type" > attribute not set. Alternately, would you like to suggest type="Zone" be > considered as as addition to the list? If so, we can submit it for review by > the RPC team. This came up during the IETF discussion of the draft. We would like type="Zone" to be added to the list, given that there are many RFCs that show the contents of DNS zones. > b) For the RELAX NG schema in Section 2.1, we updated <artwork> to > <sourcecode> > with type="rnc". Note that this was used for the RELAX NG schema in RFC 9457. > Let us know any concerns. > --> That seems fine. > 15) <!-- [rfced] The following terms are enclosed in <tt> in this document. > > id > source > TrustAnchor > validFrom > validUntil > > Some of these appear both with and without <tt>. For example, we see both > "TrustAnchor element" (no <tt>) and "<tt>TrustAnchor</tt> element" (with > <tt>). > > Also, some elements are enclosed in <tt> (e.g., "<tt>id</tt> element"), but > other elements are not (e.g., "KeyDigest element" and "Zone element"). > > Please review to ensure the usage of <tt> is correct and consistent. Let us > know if any updates are needed. > --> Choosing when to use <tt> is a personal decision, one that is rarely done consistently in the IETF. In looking back, all element names and attribute names should be in <tt> to be consistent. I doubt anyone will care much about inconsistencies here. > 16) <!-- [rfced] The following forms used in the document. Would you like to > update to one form, or is the current okay? > > trust anchor document vs. trust anchor file > > XML document vs. XML file > --> Good catch! It should always be "trust anchor file" (change one instance of "document"), but it should always be "XML document" (change four instances of "XML file"). > 17) <!-- [rfced] FYI - We have added expansions for the following > abbreviations > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > expansion in the document carefully to ensure correctness. > > Pretty Good Privacy (PGP) > Key Signing Key (KSK) > --> Yes to both. > 18) <!-- [rfced] Please review the "Inclusive Language" portion of the online > Style Guide https://www.rfc-editor.org/styleguide/part2/*inclusive_language > and let us know if any changes are needed. Updates of this nature typically > result in more precise language, which is helpful for readers. > > Note that our script did not flag any words in particular, but this should > still be reviewed as a best practice. > --> No changes here. -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
