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

On Feb 17, 2025, at 15:32, Eric Rescorla <[email protected]> wrote:
> 
> 
> 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.

I'm fine with adding this because I agree with it, but so far we've been hesitant to put words in the mouths of WGs about why they did a thing, particularly long ago. What do others think about this addition?


> 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?

This list has been concerned with keeping the document squarely in the "not prohibiting" lane, so repeating something from the introduction seems fine.

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

New wording coming in the next draft.

>    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?

Right. Will fix.


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

Ack.

> 
> 
>    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".

You will see lots of changes here in the next draft.

> 
> S 3.3.
>    Some IANA registries use a an allocation scheme that allows for
> 
> Nit: "a an"

Ack.


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

Yep, and others use different things as well. After we do the next draft, we need a separate thread on what some registries do now, what might be considered better by some WGs, and so on.

--Paul Hoffman

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