Code change:
5. <del> The "Hash Algorithms for HTTP Digest Fields", maintained by IANA at https://www.iana.org/assignments/http-dig-alg/ [1], registers algorithms for use with the Integrity and Integrity preference fields defined in this document. </del> <ins> There are a wide variety of hashing algorithms that can be used for the purposes of integrity.  The choice of algorithm depends on several factors such as the integrity use case, implementation needs or constraints, or application design and workflows. An initial set of algorithms will be registered with IANA in the "Hash Algorithms for HTTP Digest Fields" registry; see establish- hash-algorithm-registry.  Additional algorithms can be registered in accordance with the policies set out in this section. Each algorithm has a status field, which is intended to provide an aid to implementation selection. Algorithms with a status value of "standard" are suitable for many purposes, including adversarial situations where hash functions might need to provide resistance to collision, first-preimage and second- preimage attacks.  For adversarial situations, selecting which of the "standard" algorithms are acceptable will depend on the level of protection the circumstances demand.  As there is no negotiation, endpoints that depend on a digest for security will be vulnerable to attacks on the weakest algorithm they are willing to accept. Algorithms with a status value of "insecure" either provide none of these properties, or are known to be weak (see NO-MD5 and NO-SHA). These algorithms MAY be used to preserve integrity against corruption, but MUST NOT be used in a potentially adversarial setting; for example, when signing Integrity fields' values for authenticity. </ins> <del> This registry uses the Specification Required policy (RFC8126). </del> <ins> Discussion of algorithm agility is presented in sec-agility. </ins> <del> Registrations MUST include the following fields: </del> <ins> Registration requests for the "Hash Algorithms for HTTP Digest Fields" registry use the Specification Required policy (RFC8126). Requests should use the following template: </ins> Algorithm Key: the Structured Fields key value used in "Content- Digest", "Repr-Digest", "Want-Content-Digest", or "Want-Repr- Digest" field Dictionary member keys <del> Status: the status of the algorithm.  Use "standard" for standardized algorithms without known problems; "experimental" or some other appropriate value </del> <ins> Status: the status of the algorithm.  The options are: "standard" - for standardized algorithms without known problems, </ins> <del> e.g. according to the type and status of the primary document in which the algorithm is defined; "insecure" when the algorithm is insecure; "reserved" when the algorithm references a reserved token value </del> <ins> "provisional" - for non-standard or unproven algorithms, "insecure" - for insecure algorithms, "reserved" - for algorithms that use a reserved token value that cannot be expressed in Structured Fields </ins> Description: a short description of the algorithm <del> Reference(s): a set of pointers to the primary documents defining the algorithm and key </del> <ins> Reference(s): pointer(s) to the primary document(s) defining the technical details of the algorithm, and optionally the key </ins> <del> Insecure hashing algorithms MAY be used to preserve integrity against corruption, but MUST NOT be used in a potentially adversarial setting; for example, when signing Integrity fields' values for authenticity. </del> <ins> When reviewing registration requests, the designated expert(s) should pay attention to the requested status.  The status value should reflect standardization status and the broad opinion of relevant interest groups such as the IETF or security-related SDOs.  The "standard" status is not suitable for an algorithm that is known to be weak, broken or experimental.  If a registration request attempts to register such an algorithm as "standard", the designated expert(s) should suggest an alternative status of "insecure" or "provisional". </ins> <del> The entries in iana-hash-algorithm-table are registered by this document. </del> <ins> When reviewing registration requests, the designated expert(s) cannot use a status of "insecure" or "provisional" as grounds for rejection. Requests to update or change the fields in an existing registration are permitted.  For example, this could allow for the transition of an algorithm status from "standard" to "insecure" as the security environment evolves. </ins> 6.

Related discussion:
text: Murray suggested some things that we could change about the way new IANA registry was being handled. This change: tries to make it clearer that this document uses a new registry that we will need IANA to create moves rote IANA instructions to the IANA considerations better highlights interesting hash algorithm considerations for implmenters clarifies the registration procedure and expands on the expectations for the Designated Expert(s)