A few comments on the draft: > DNSSEC Trust Anchor Publication for the Root Zone > draft-ietf-dnsop-rfc7958bis-03 ... >Abstract ... > The root zone of the Domain Name System (DNS) is cryptographically > signed using DNS Security Extensions (DNSSEC). “The root zone of the Domain Name System (DNS)” can be two things. One is the root zone at the top of the DNS instance in common use on the Internet. The other is the conceptual top of the namespace in any instantiation of the DNS protocol. My suggestion is to refer to the “global public DNS” at the beginning of the document as “this” trust anchor applies “only” to the Internet. This distinction is not often made, but it is significant when working on the protocol vs. working on the system. >2.2. XML Semantics > 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. UTC timezone ought to be explicitly mentioned. > The KeyTag element in the KeyDigest element contains the key tag for > the DNSKEY record represented in this KeyDigest. There should be a reference, as the key tag’s definition is part of the DNS security algorithm definition. > The Algorithm element in the KeyDigest element contains the signing > algorithm identifier for the DNSKEY record represented in this > KeyDigest. “algorithm” ought to be replaced by “DNS security algorithm”, defined in the "DNS Security Algorithm Numbers” registry. (The values are protocol-specific, not instance-specific, referring to the first comment above.) Probably ought to cite RFC 6014. > The DigestType element in the KeyDigest element contains the digest > algorithm identifier for the DNSKEY record represented in this > KeyDigest. The registry of values for this is simply titled "Digest Algorithms”, probably ought to be referenced, or its description RFC 9157. That document isn’t referenced in the draft, probably ought to be. > The Digest element in the KeyDigest element contains the hexadecimal > representation of the hash for the DNSKEY record represented in this > KeyDigest. (maybe add “as defined by the DNSKEY resource record’s DNS security algorithm definition"…) > The PublicKey element in the KeyDigest element contains the base64 > representation of the public key represented in this KeyDigest. The > PublicKey is optional and is new in this version of the > specification. It can be useful when IANA has a trust anchor that > has not yet been published in the DNS root. (maybe add “as defined by the DNSKEY resource record’s DNS security algorithm definition”…) A weak suggestion - include references that define the derivation of these fields. I say weaker suggestion as it would be fairly obvious to know where to look for this information, unlike the generic use of “algorithm” instead of DNS security algorithm, as opposed to the cryptographic algorithm of a key pair. Summary: I think it is important to 1) specify the timezone, 2) put an adjective on “algorithm” and 3) state that this is an operational parameter for the “Internet” (global public or whatever). Optionally - add pointers to help implementers find relevant definitions, if needed. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
