CoseHeader
Protected header of a CoseSigned.
See RFC 9052.
Properties
This header parameter is used to indicate the algorithm used for the security processing. This header parameter MUST be authenticated where the ability to do so exists. This support is provided by AEAD algorithms or construction (e.g., COSE_Sign and COSE_Mac0). This authentication can be done either by placing the header parameter in the protected-header-parameters bucket or as part of the externally supplied data (Section 4.3). The value is taken from the "COSE Algorithms" registry.
This header parameter contains an ordered array of X.509 certificates. The certificates are to be ordered starting with the certificate containing the end-entity key followed by the certificate that signed it, and so on. There is no requirement for the entire chain to be present in the element if there is reason to believe that the relying party already has, or can locate, the missing certificates. This means that the relying party is still required to do path building but that a candidate path is proposed in this header parameter.
This header parameter is used to indicate the content type of the data in the "payload" or "ciphertext" field. Integers are from the "CoAP Content-Formats" IANA registry table. Text values follow the syntax of "
This header parameter is used to indicate which protected header parameters an application that is processing a message is required to understand. Header parameters defined in this document do not need to be included, as they should be understood by all implementations. Additionally, the header parameter "counter signature" (label 7) defined by RFC8152 must be understood by new implementations, to remain compatible with senders that adhere to that document and assume all implementations will understand it. When present, the "crit" header parameter MUST be placed in the protected-header-parameters bucket. The array MUST have at least one value in it.
This header parameter holds the Initialization Vector (IV) value. For some symmetric encryption algorithms, this may be referred to as a nonce. The IV can be placed in the unprotected bucket, since for AE and AEAD algorithms, modifying the IV will cause the decryption to fail.
This header parameter identifies one piece of data that can be used as input to find the needed cryptographic key. The value of this header parameter can be matched against the "kid" member in a COSE_Key structure. Other methods of key distribution can define an equivalent field to be matched. Applications MUST NOT assume that "kid" values are unique. There may be more than one key with the same "kid" value, so all of the keys associated with this "kid" may need to be checked. The internal structure of "kid" values is not defined and cannot be relied on by applications. Key identifier values are hints about which key to use. This is not a security-critical field. For this reason, it can be placed in the unprotected-header-parameters bucket.
This header parameter holds a part of the IV value. When using the COSE_Encrypt0 structure, a portion of the IV can be part of the context associated with the key (Context IV), while a portion can be changed with each message (Partial IV). This field is used to carry a value that causes the IV to be changed for each message. The Partial IV can be placed in the unprotected bucket, as modifying the value will cause the decryption to yield plaintext that is readily detectable as garbled. The "Initialization Vector" and "Partial Initialization Vector" header parameters MUST NOT both be present in the same security layer.