3.2.1. Enforcing Application Requirements

3.2.1. Enforcing Application Requirements

The verification requirements specified in this document are intended as a baseline set of restrictions that are generally applicable to all use cases. Applications using HTTP message signatures MAY impose requirements above and beyond those specified by this document, as appropriate for their use case.

Some non-normative examples of additional requirements an application might define are:

• Requiring a specific set of header fields to be signed (e.g., Authorization, Content-Digest).

• Enforcing a maximum signature age from the time of the created timestamp.

• Rejecting signatures past the expiration time in the expires timestamp. Note that the expiration time is a hint from the signer and that a verifier can always reject a signature ahead of its expiration time.

• Prohibiting certain signature metadata parameters, such as runtime algorithm signaling with the alg parameter when the algorithm is determined from the key information.

• Ensuring successful dereferencing of the keyid parameter to valid and appropriate key material.

• Prohibiting the use of certain algorithms or mandating the use of a specific algorithm.

• Requiring keys to be of a certain size (e.g., 2048 bits vs. 1024 bits).

• Enforcing uniqueness of the nonce parameter.

• Requiring an application-specific value for the tag parameter.

Application-specific requirements are expected and encouraged. When an application defines additional requirements, it MUST enforce them during the signature verification process, and signature verification MUST fail if the signature does not conform to the application's requirements.

Applications MUST enforce the requirements defined in this document. Regardless of use case, applications MUST NOT accept signatures that do not conform to these requirements.