Skip to main content

3.1. Creating a Signature

3.1. Creating a Signature​

Creation of an HTTP message signature is a process that takes as its input the signature context (including the target message) and the requirements for the application. The output is a signature value and set of signature parameters that can be communicated to the verifier by adding them to the message.

In order to create a signature, a signer MUST apply the following algorithm:

  1. The signer chooses an HTTP signature algorithm and key material for signing from the set of potential signing algorithms. The set of potential algorithms is determined by the application and is out of scope for this document. The signer MUST choose key material that is appropriate for the signature's algorithm and that conforms to any requirements defined by the algorithm, such as key size or format. The mechanism by which the signer chooses the algorithm and key material is out of scope for this document.

  2. The signer sets the signature's creation time to the current time.

  3. If applicable, the signer sets the signature's expiration time property to the time at which the signature is to expire. The expiration is a hint to the verifier, expressing the time at which the signer is no longer willing to vouch for the signature. An appropriate expiration length, and the processing requirements of this parameter, are application specific.

  4. The signer creates an ordered set of component identifiers representing the message components to be covered by the signature and attaches signature metadata parameters to this set. The serialized value of this set is later used as the value of the Signature-Input field as described in Section 4.1.

    • Once an order of covered components is chosen, the order MUST NOT change for the life of the signature.

    • Each covered component identifier MUST be either (1) an HTTP field (Section 2.1) in the signature context or (2) a derived component listed in Section 2.2 or in the "HTTP Signature Derived Component Names" registry.

    • Signers of a request SHOULD include some or all of the message control data in the covered components, such as the @method, @authority, @target-uri, or some combination thereof.

    • Signers SHOULD include the created signature metadata parameter to indicate when the signature was created.

    • The @signature-params derived component identifier MUST NOT be present in the list of covered component identifiers. The derived component is required to always be the last line in the signature base, ensuring that a signature always covers its own metadata and the metadata cannot be substituted.

    • Further guidance on what to include in this set and in what order is out of scope for this document.

  5. The signer creates the signature base using these parameters and the signature base creation algorithm (Section 2.5).

  6. The signer uses the HTTP_SIGN primitive function to sign the signature base with the chosen signing algorithm using the key material chosen by the signer. The HTTP_SIGN primitive and several concrete applications of signing algorithms are defined in Section 3.3.

  7. The byte array output of the signature function is the HTTP message signature output value to be included in the Signature field as defined in Section 4.2.

For example, given the HTTP message and signature parameters in the example in Section 2.5, the example signature base is signed with the test-key-rsa-pss key (see Appendix B.1.2) and the RSASSA-PSS algorithm described in Section 3.3.1, giving the following message signature output value, encoded in Base64:

NOTE: '' line wrapping per RFC 8792

HIbjHC5rS0BYaa9v4QfD4193TORw7u9edguPh0AW3dMq9WImrlFrCGUDih47vAxi4L2
YRZ3XMJc1uOKk/J0ZmZ+wcta4nKIgBkKq0rM9hs3CQyxXGxHLMCy8uqK488o+9jrptQ
+xFPHK7a9sRL1IXNaagCNN3ZxJsYapFj+JXbmaI5rtAdSfSvzPuBCh+ARHBmWuNo1Uz
VVdHXrl8ePL4cccqlazIJdC4QEjrF+Sn4IxBQzTZsL9y9TP5FsZYzHvDqbInkTNigBc
E9cKOYNFCn4D/WM7F6TNuZO9EgtzepLWcjTymlHzK7aXq6Am6sfOrpIC49yXjj3ae6H
RalVc/g==

       Figure 2: Non-normative Example Signature Value

Note that the RSA-PSS algorithm in use here is non-deterministic, meaning that a different signature value will be created every time the algorithm is run. The signature value provided here can be validated against the given keys, but newly generated signature values are not expected to match the example. See Section 7.3.5.

Last updated on