6.2. HTTP Signature Algorithms Registry

6.2. HTTP Signature Algorithms Registry

This document defines HTTP signature algorithms, for which IANA has created and now maintains a new registry titled "HTTP Signature Algorithms". Initial values for this registry are given in Section 6.2.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy [RFC8126].

The algorithms listed in this registry identify some possible cryptographic algorithms for applications to use with this specification, but the entries neither represent an exhaustive list of possible algorithms nor indicate fitness for purpose with any particular application of this specification. An application is free to implement any algorithm that suits its needs, provided the signer and verifier can agree to the parameters of that algorithm in a secure and deterministic fashion. When an application needs to signal the use of a particular algorithm at runtime using the alg signature parameter, this registry provides a mapping between the value of that parameter and a particular algorithm. However, the use of the alg parameter needs to be treated with caution to avoid various forms of algorithm confusion and substitution attacks, as discussed in Section 7.

The Status value should reflect standardization status and the broad opinion of relevant interest groups such as the IETF or security- related Standards Development Organizations (SDOs). When an algorithm is first registered, the designated expert (DE) should set the Status field to "Active" if there is consensus for the algorithm to be generally recommended as secure or "Provisional" if the algorithm has not reached that consensus, e.g., for an experimental algorithm. A status of "Provisional" does not mean that the algorithm is known to be insecure but instead indicates that the algorithm has not reached consensus regarding its properties. If at a future time the algorithm as registered is found to have flaws, the registry entry can be updated and the algorithm can be marked as "Deprecated" to indicate that the algorithm has been found to have problems. This status does not preclude an application from using a particular algorithm; rather, it serves to provide a warning regarding possible known issues with an algorithm that need to be considered by the application. The DE can further ensure that the registration includes an explanation and reference for the Status value; this is particularly important for deprecated algorithms.

The DE is expected to do the following:

• Ensure that the algorithms referenced by a registered algorithm identifier are fully defined with all parameters (e.g., salt, hash, required key length) fixed by the defining text.

• Ensure that the algorithm definition fully specifies the HTTP_SIGN and HTTP_VERIFY primitive functions, including how all defined inputs and outputs map to the underlying cryptographic algorithm.

• Reject any registrations that are aliases of existing registrations.

• Ensure that all registrations follow the template presented in Section 6.2.1; this includes ensuring that the length of the name is not excessive while still being unique and recognizable.

This specification creates algorithm identifiers by including major parameters in the identifier String in order to make the algorithm name unique and recognizable by developers. However, algorithm identifiers in this registry are to be interpreted as whole String values and not as a combination of parts. That is to say, it is expected that implementors understand rsa-pss-sha512 as referring to one specific algorithm with its hash, mask, and salt values set as defined in the defining text that establishes the identifier in question. Implementors do not parse out the rsa, pss, and sha512 portions of the identifier to determine parameters of the signing algorithm from the String, and the registration of one combination of parameters does not imply the registration of other combinations.