Paul Hoffman <paul.hoff...@icann.org> writes: > In specific, "Use for DNSSSEC Signing" and "Use for DNSSSEC > Delegation" do not make sense if there is more than one "MUST" in that > column. You cannot use two algorithms to sign or delegate at the same > time.
Thank you for the analysis. I think there are three (obvious) paths forward: 1. Define what MUST means in the context for the Use columns. 2. Use RECOMMENDED instead. 3. Only allow a single MUST in the Use column because that's what we want people to really use (which does sound more like a SHOULD). IE, if we believe ideally there should be one cryptographic algorithm deployed to simplify the deployed base, we could pick this route. I doubt it would be popular though, as we already have a fractured ecosystem and it is generally working. Feedback from the WG appreciated :-) > How can both 8 and 13 be "MUST use for signing" at the same time? Do note that this problem actually isn't new, technically. The values we pick basically mirror 8624 but 8624 really didn't talk about recommending *usage* which is what the discussion around this document clearly picked up. Note that 8624 has this to say as well: [RFC2119] considers the term SHOULD equivalent to RECOMMENDED, and SHOULD NOT equivalent to NOT RECOMMENDED. The authors of this document have chosen to use the terms RECOMMENDED and NOT RECOMMENDED, as this more clearly expresses the intent to implementers. > How can 14 and 16 be "MAY use for signing" if there are other values > that MUST be used instead? I think that switching to "RECOMMENDED" from "MUST" may solve your concerns? > Is 15 more recommended than 14 and 16 even though 14 and 16 are > currently obviously stronger? There is no intent to do algorithm comparisons by values encoded in the columns. I think that's more what Steve and Russ' document are likely targeting. More importantly, I don't think we should have comparison text and each row should stand alone. If you have specific concrete suggestions for value changes, it would be helpful but do note our goal was to do value changes generally in follow on documents. We had to break that a little bit because we doubled the number of recommended columns by adding the "Use" ones. -- Wes Hardaker USC/ISI _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org