Thanks for the quick responses! On Jul 8, 2024, at 11:21, Peter Thomassen <pe...@desec.io> wrote: > > On 7/8/24 20:08, Paul Hoffman wrote: >>> 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? >> The zone element is there in case someone other than the root operator wants >> to use the format. Dropping it might cause some current users of the format >> to fail, so we are leaving it in. > > So it remains underspecified for labels containing dots. (I'm OK with that, > just spelling it out.)
It is indeed unspecified, which seems fine because we also haven't seen any strong use case for it. > >>> 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? > [...] >> The spec says it is "an opaque string". Your proposal is to extend that and >> make it unique. This could cause a serious problem in the future if IANA >> does not change the id string for some reason. We are leaving it as just >> opaque. > > That's fine. However, the attribute name "id" suggests uniqueness, Without any definition of uniqueness in the document, it shouldn't. For example, in your earlier message, you suggested a few different ways this could be unique. Without such a definition, a reader can't assume they know what kind of uniqueness to infer. > because that's how IDs usually work. I suggest something like "opaque (but > not necessarily unique)", or renaming it to something else, to prevent this > misinterpretation. Changing the name of an attribute for a widely-used protocol seems incredibly dangerous. Adding "(but not necessarily unique)" doesn't make sense because "opaque" doesn't imply uniqueness. > >>> 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? >> Yes. >>> How does that make things any better? >> It does not, but the text doesn't indicate that it makes anything better. > > I wonder then why we need the "if" clause in that sentence. I'd remove it, > but I don't feel strongly. Without the clause, it sounds like the document is telling the reader they SHOULD trust the CA that IANA uses. Given that IANA gets to choose its CA based on its own risk assessment, and even large CAs seem to become untrusted for other reasons, I wouldn't want to do that. --Paul Hoffman _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
