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

Reply via email to