[saag] Re: draft-paulwh-crypto-components-01

I think this is a good start. One thing I would like to see is some
discussion of the reasons why many registries have gone to permissive
policies, namely concerns about code point squatting, the inadequacy
of controlling the registry as a mechanism of influencing implementor
behavior, and the cost to the WG of evaluating new mechanisms.


S 1.
   This document explicitly does not prohibit exceptions from the
   current practices.  Given the wide variety of historical practices,
   the difficulty of differentiating what is a base primitive and what
   is a cryptographic component, and the variety of needs in IETF
   working groups, the guidance in this document gives leeway for future
   specifications.

This first sentence seems redundant in view of the text in S 3
that says:

   This
   document does not define any new policies, but instead describes the
   many practices that have been used, particularly the practices that
   are considered best current practices today.

If we don't define new policies, how could we prohibit exceptions?


S 3.
   Although a proliferation of cryptographic components is a barrier to
   interoperability,

I am not a fan of the wide proliferation of cryptographic components
(though some redundancy is good), but I'm less sure the reason is
interoperability but rather the burden on implementors who get asked
to add new algorithms and then the security risk of having many
poorly-reviewed primitives.


   the IETF encourages experimenting with new
   cryptographic components.  Identifiers used in IETF protocols are
   meant to be easy to obtain, as the IETF encourages experimentation
   and operational testing.  These identifiers are often called "code
   points" when they are listed in IANA registries, but might also be
   object identifiers (OIDs).  OIDs are covered in Section 3.5.

Isn't an OID a kind of code point?

3.1.  Per-Registry Requirements for Adding Code Points

   In the past, some working groups had set the ability to add
   cryptographic component code points to IANA registries for their
   protocols be very strict, by requiring an RFC.  Recently, the rules

Nit: "ability" isn't "strict". Rather, the rules were strict.


   points in order to allow for experimentation.  Where possible, the
   rules for cryptographic component registries should have an open
   registration policy (such as "Expert Review" or "Specification
   Required").  These do not need to be RFCs, but should be stable
   references.

I think it would be helpful to clarify that this isn't retconning
what "Specification Required" or "Expert Review" mean. Perhaps:

   While the specific registration conditions for "Expert Review"
   and "Specification Required" are a matter for the WG, overall
   IETF policies do not require that these specifications be RFCs;
   they should, however, be stable references.

I think this leaves room for the WGs to do their own thing while
not affecting existing registries (though I personally wish
those registries would adopt a more permissive view).

   Although there is no IETF-wide consensus at the time of this writing
   as to whether specific versions of an Internet Drafts are appropriate
   for all registries as stable references, they have been used in the
   past for cryptographic purposes.  Until further guidance is
   developed, the decision about whether a draft is acceptable can
   continue to be addressed on a case-by-case basis by the designated
   expert for the specific registry.

Perhaps "within the policies set by the RFCs that specify the registry".

S 3.3.
   Some IANA registries use a an allocation scheme that allows for

Nit: "a an"


S 3.4.
   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.

As separately observed, TLS, at least, uses Y, N, and D.


-Ekr



On Mon, Feb 3, 2025 at 9:00 AM Paul Hoffman <[email protected]> wrote:

> Greetings again. PaulW and I have updated the draft based on the SAAG list
> discussion from the past few weeks. Please see the revised version,
> particularly the new text about the use of Internet Drafts for code point
> references.
>
> There were a few proposed changes that we didn't do:
>
> - Michael Richardson proposed that we add current examples of protocols in
> Section 3. This seems like a bad idea because WGs sometimes change the way
> that their codepoint registries are managed, including what is or is not
> allowed for future codepoints. It would be bad if we listed one that later
> got changed.
>
> - Watson Ladd said "I would appreciate clarifying the scope to be things
> like (but not limited to) signatures, ciphers etc. It's not clear to me how
> this draft is meant to apply to something like PPM." It's not clear at this
> point if this document has such a scope limitation.
>
> Thanks for all the list input; more is appreciated. Please start new
> threads for each topic, given that this document covers many diverse topics.
>
> --Paul Hoffman
>
> =====
>
> A new version of Internet-Draft draft-paulwh-crypto-components-01.txt has
> been
> successfully submitted by Paul Hoffman and posted to the
> IETF repository.
>
> Name:     draft-paulwh-crypto-components
> Revision: 01
> Title:    Documenting and Referencing Cryptographic Components in IETF
> Documents
> Date:     2025-02-03
> Group:    Individual Submission
> Pages:    8
> URL:
> https://www.ietf.org/archive/id/draft-paulwh-crypto-components-01.txt
> Status:   https://datatracker.ietf.org/doc/draft-paulwh-crypto-components/
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-paulwh-crypto-components
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-paulwh-crypto-components-01
>
>
> _______________________________________________
> saag mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

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