1.1. Conventions and Terminology

1.1. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

The terms "HTTP message", "HTTP request", "HTTP response", "target URI", "gateway", "header field", "intermediary", "request target", "trailer field", "sender", "method", and "recipient" are used as defined in [HTTP].

For brevity, the term "signature" on its own is used in this document to refer to both digital signatures (which use asymmetric cryptography) and keyed MACs (which use symmetric cryptography). Similarly, the verb "sign" refers to the generation of either a digital signature or keyed MAC over a given signature base. The qualified term "digital signature" refers specifically to the output of an asymmetric cryptographic signing operation.

This document uses the following terminology from Section 3 of [STRUCTURED-FIELDS] to specify data types: List, Inner List, Dictionary, Item, String, Integer, Byte Sequence, and Boolean.

This document defines several string constructions using ABNF [ABNF] and uses the following ABNF rules: VCHAR, SP, DQUOTE, and LF. This document uses the following ABNF rules from [STRUCTURED-FIELDS]: sf- string, inner-list, and parameters. This document uses the following ABNF rules from [HTTP] and [HTTP/1.1]: field-content, obs-fold, and obs-text.

In addition to those listed above, this document uses the following terms:

HTTP Message Signature: A digital signature or keyed MAC that covers one or more portions of an HTTP message. Note that a given HTTP message can contain multiple HTTP message signatures.

Signer: The entity that is generating or has generated an HTTP message signature. Note that multiple entities can act as signers and apply separate HTTP message signatures to a given HTTP message.

Verifier: An entity that is verifying or has verified an HTTP message signature against an HTTP message. Note that an HTTP message signature may be verified multiple times, potentially by different entities.

HTTP Message Component: A portion of an HTTP message that is capable of being covered by an HTTP message signature.

Derived Component: An HTTP message component derived from the HTTP message through the use of a specified algorithm or process. See Section 2.2.

HTTP Message Component Name: A String that identifies an HTTP message component's source, such as a field name or derived component name.

HTTP Message Component Identifier: The combination of an HTTP message component name and any parameters. This combination uniquely identifies a specific HTTP message component with respect to a particular HTTP message signature and the HTTP message it applies to.

HTTP Message Component Value: The value associated with a given component identifier within the context of a particular HTTP message. Component values are derived from the HTTP message and are usually subject to a canonicalization process.

Covered Components: An ordered set of HTTP message component identifiers for fields (Section 2.1) and derived components (Section 2.2) that indicates the set of message components covered by the signature, never including the @signature-params identifier itself. The order of this set is preserved and communicated between the signer and verifier to facilitate reconstruction of the signature base.

Signature Base: The sequence of bytes generated by the signer and verifier using the covered components set and the HTTP message. The signature base is processed by the cryptographic algorithm to produce or verify the HTTP message signature.

HTTP Message Signature Algorithm: A cryptographic algorithm that describes the signing and verification process for the signature, defined in terms of the HTTP_SIGN and HTTP_VERIFY primitives described in Section 3.3.

Key Material: The key material required to create or verify the signature. The key material is often identified with an explicit key identifier, allowing the signer to indicate to the verifier which key was used.

Creation Time: A timestamp representing the point in time that the signature was generated, as asserted by the signer.

Expiration Time: A timestamp representing the point in time after which the signature should no longer be accepted by the verifier, as asserted by the signer.

Target Message: The HTTP message to which an HTTP message signature is applied.

Signature Context: The data source from which the HTTP message component values are drawn. The context includes the target message and any additional information the signer or verifier might have, such as the full target URI of a request or the related request message for a response.

The term "UNIX timestamp" refers to what Section 4.16 of [POSIX.1] calls "seconds since the Epoch".

This document contains non-normative examples of partial and complete HTTP messages. Some examples use a single trailing backslash () to indicate line wrapping for long values, as per [RFC8792]. The
character and leading spaces on wrapped lines are not part of the value.