[saag] Re: [Ext] Re: draft-paulwh-crypto-components-02

Simon Josefsson <[email protected]> Fri, 14 Feb 2025 11:47:45 +0100

Newsgroups	gmane.ietf.saag
Message-ID	<[email protected]>

Paul Hoffman <[email protected]> writes:

>> The distinction I am trying to draw here is that if you have an
>> Informational document describing a protocol it's reasonable for it
>> to use normative language that applies to those who implement the
>> protocol. However, I would prefer we not have Informational
>> documents that impose normative requirements on other protocols,
>> etc.
>
> Is there wording in the current draft that feels like it imposes
> normative requirements on other protocols. We tried to suggest rather
> than demand, but if we missed, it would be good to fix.

The way I read the paragraph below is that you intend a normative
requirement but you re-worded it to actually not say so overtly.  I also
think the broad generic argument below that "too many algorithms is
harmful" plays too strongly in the hands of those who want to make
non-NIST crypto hard to deploy.

 3.4. Recommendations in IANA Registries
 ...
  Working groups setting up such registries should strongly consider
  mandating that decisions on setting the values in these columns to
  anything other than "MAY" require a standards track RFC. That is,
  Independent Stream and IRTF RFCs would not be able to set or change
  the values in such a table in an IANA registry.
...
  Having too many algorithms with a "recommended" status is harmful
  because it complicates implementations, deployments, and migrations to
  newer algorithms.

/Simon

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]

signature.asc (application/pgp-signature, 1.2 KB)