CBOR Object Signing and Encryption (COSE): Countersignatures
Extracted elements (18)
Abbreviated countersignatures are intended for encrypted group messaging where identification of the message originator is required but minimizing countersignature size is important. They carry no protected attributes; all parameters come from the outer encryption/MAC context.
The original countersignature algorithm in RFC 8152 was flawed because the cryptographically computed value was not always included in the signature input. For MAC structures this was not initially deemed an issue, but for COSE_Sign1 the security properties were incorrect. The V2 algorithm defined in this document requires inclusion of all cryptographic material across all structures.
The V2 algorithm is designed to produce the same countersignature value as the old algorithm in cases where the computed cryptographic value was already included. This means that for those structures only the header parameter label needs to change, easing migration.
Full and abbreviated countersignature structures cannot be converted to each other: the signature computation includes a context string that identifies which structure is used ('CounterSignatureV2' vs 'CounterSignature0V2'), so a converted structure will always fail signature validation.
New implementations MUST support verification of the old 'CounterSignature' (label 7) to remain compatible with senders adhering to RFC 8152. Verification of 'CounterSignature0' (label 9) MAY be supported for further compatibility. New uses should migrate to CounterSignatureV2 (label 11) and CounterSignature0V2 (label 12).
Only signature algorithms with appendix (not signature schemes with message recovery) may be used for countersignatures, because the body must be processable without evaluating the countersignature.
The narrowed deterministic encoding rules from RFC 9052 Section 9 (which further constrain RFC 8949 Section 4.2) MUST be used when encoding the Countersign_structure to ensure all implementations produce identical ToBeSigned byte strings.
The target structure of the countersignature must have all of its cryptographic functions finalized before computing the countersignature. The ToBeSigned value is produced by encoding the Countersign_structure to a byte string using deterministic CBOR encoding.
The other_fields element of Countersign_structure captures all bstr fields after the second in the target structure. For COSE_Sign1 this is an array of one element containing the signature value. This field is omitted only when the target structure has at most two bstr fields.
The V2 abbreviated countersignature header parameter has label 12 and carries a single COSE_Countersignature0 value (a bare byte string containing only the signature value). It may appear in the same COSE structures as the full countersignature.
The V2 full countersignature header parameter has label 11 and carries one or more COSE_Countersignature values. It may appear as an unprotected attribute in COSE_Sign1, COSE_Signature, COSE_Encrypt, COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0 structures.
CBOR tag 19 is assigned in the IANA 'CBOR Tags' registry for the COSE_Countersignature data item, representing a standalone V2 COSE countersignature.
Two entries are added to the IANA 'COSE Header Parameters' registry: label 11 ('Countersignature version 2') with value type COSE_Countersignature / [+ COSE_Countersignature], and label 12 ('Countersignature0 version 2') with value type COSE_Countersignature0. Existing labels 7 and 9 are deprecated by RFC 9338.
All security considerations from RFC 9052 apply to this document, especially the need for implementations to protect private key material used in countersignature operations.
When COSE_Encrypt or COSE_Mac is used and more than two parties share the key, data origin authentication is not provided. A countersignature on the encrypted data attests only to the existence of encrypted data, not to the plaintext — two different keys can yield successful decryption with different plaintexts, undetectable by the countersignature.
When countersigning COSE_Encrypt or COSE_Mac with short authentication tags, the security level is limited by the tag length, not the countersignature algorithm. To provide 128-bit security against collision attacks, the authentication tag length MUST be at least 256 bits. A countersignature over AES-MAC provides at most 64 bits, and over AES-CCM-16-64-128 at most 32 bits of integrity protection.
COSE_Countersignature has the same CDDL structure as COSE_Signature (protected headers bstr, unprotected header map, signature bstr). Tagged form uses CBOR tag 19. COSE_Countersignature0 is simply a bstr containing only the raw signature value.
The Countersign_structure is a CBOR array with fields: context (text string: 'CounterSignature', 'CounterSignature0', 'CounterSignatureV2', or 'CounterSignature0V2'), body_protected (bstr), optional sign_protected (bstr, omitted for Countersignature0V2), external_aad (bstr), payload (bstr), and optional other_fields (array of bstr for fields beyond the second in the target structure).