3. Contresignatures version 2

Une contresignature est normalement définie comme une seconde signature qui confirme une signature principale. Un exemple normal de contresignature est la signature qu'un notaire appose sur un document pour attester que vous avez signé le document. Un notaire inclut généralement un horodatage pour indiquer quand la notarisation a lieu ; cependant, un tel horodatage n'a pas encore été défini pour COSE. Un horodatage, une fois défini dans un futur document, pourrait être inclus en tant que paramètre d'en-tête protégé. Ainsi, l'application d'une contresignature aux objets COSE_Signature ou COSE_Sign1 correspond à cette définition traditionnelle. Ce document étend le contexte d'une contresignature pour permettre son application à toutes les structures de sécurité définies. La contresignature doit être traitée comme une opération distincte de l'opération initiale, même si elle est appliquée par le même utilisateur, comme cela est fait dans [GROUP-OSCORE].

COSE prend en charge deux formes différentes de contresignatures. Les contresignatures complètes utilisent la structure COSE_Countersignature, qui a la même structure que COSE_Signature. Ainsi, les contresignatures complètes peuvent avoir des attributs protégés et non protégés, y compris des contresignatures chaînées. Les contresignatures abrégées utilisent la structure COSE_Countersignature0. Cette structure ne contient que la valeur de la signature et rien d'autre. Les structures ne peuvent pas être converties entre elles ; comme le calcul de la signature inclut un paramètre identifiant la structure utilisée, la structure convertie échouera à la validation de la signature.

La contresignature version 2 modifie l'algorithme utilisé pour calculer la signature par rapport à la version originale spécifiée dans la section 4.5 de la [RFC8152]. La nouvelle version inclut désormais le matériel cryptographique généré pour toutes les structures plutôt que juste pour un sous-ensemble.

COSE a été conçu pour l'uniformité dans la spécification des structures de données. L'un des résultats est que pour COSE, on peut étendre le concept de contresignatures au-delà de la simple idée de signer une signature pour pouvoir signer la plupart des structures sans avoir à créer une nouvelle couche de signature. Lors de la création d'une contresignature, il faut être clair sur les propriétés de sécurité qui en résultent. Lorsqu'elle est effectuée sur une COSE_Signature ou COSE_Sign1, la sémantique normale de la contresignature est préservée. C'est-à-dire que la contresignature fait une déclaration sur l'existence d'une signature et, lorsqu'elle est utilisée avec un horodatage encore à spécifier, un moment où la signature existe. Lorsqu'elle est effectuée sur un COSE_Mac ou COSE_Mac0, la charge utile est incluse ainsi que la valeur MAC. Lorsqu'elle est effectuée sur un COSE_Encrypt ou COSE_Encrypt0, l'existence des données chiffrées est attestée. Il convient de noter qu'il existe une distinction entre attester les données chiffrées par opposition à attester les données non chiffrées. Si c'est ce dernier qui est souhaité, il faut alors appliquer une signature aux données, puis chiffrer cela. Il est toujours possible de construire des cas où l'utilisation de deux clés différentes entraîne un déchiffrement réussi, où la vérification de l'étiquette réussit, mais où deux textes clairs complètement différents sont produits. Cette situation n'est pas détectable par une contresignature sur les données chiffrées.

3.1. Contresignatures complètes

La structure COSE_Countersignature permet le même ensemble de capacités qu'une COSE_Signature. Cela signifie que toutes les capacités d'une signature sont dupliquées avec cette structure. Plus précisément, le contresignataire n'a pas besoin d'être lié au producteur de ce qui est contresigné, car l'identification de la clé et de l'algorithme peut être placée dans les attributs de la contresignature. Cela signifie également que la contresignature peut elle-même être contresignée. Il s'agit d'une fonctionnalité requise par des protocoles tels que les services d'archivage à long terme. Plus d'informations sur la façon dont les contresignatures sont utilisées peuvent être trouvées dans la syntaxe d'enregistrement de preuve décrite dans la [RFC4998].

La structure complète de contresignature peut être encodée comme étiquetée ou non étiquetée, selon le contexte. Une structure COSE_Countersignature étiquetée est identifiée par la balise CBOR 19. La structure de contresignature est la même que celle utilisée pour un signataire sur un objet signé. Le fragment CDDL pour les contresignatures complètes est :

COSE_Countersignature_Tagged = #6.19(COSE_Countersignature)
COSE_Countersignature = COSE_Signature

Les détails des champs d'une contresignature se trouvent dans la section 4.1 de la [RFC9052].

Un exemple de contresignature sur une signature se trouve à l'annexe A.1.1. Un exemple de contresignature dans un objet de chiffrement se trouve à l'annexe A.3.1.

Il convient de noter que seul un algorithme de signature avec annexe (voir la section 8.1 de la [RFC9052]) peut être utilisé pour les contresignatures. En effet, le corps doit pouvoir être traité sans avoir à évaluer la contresignature, ce qui n'est pas possible pour les schémas de signature avec récupération de message.

3.2. Contresignatures abrégées

Les contresignatures abrégées prennent en charge la messagerie de groupe chiffrée où l'identification de l'auteur du message est requise mais où l'on souhaite garder la contresignature aussi petite que possible. Pour les contresignatures abrégées, aucune disposition n'est prévue pour les attributs protégés liés à l'opération de signature. C'est-à-dire que les paramètres pour calculer ou vérifier la contresignature abrégée sont fournis par le même contexte utilisé pour décrire le chiffrement, la signature ou le traitement MAC.

Le fragment CDDL pour les contresignatures abrégées est :

COSE_Countersignature0 = bstr

La chaîne d'octets représentant la valeur de la signature est placée dans l'attribut Countersignature0. Cet attribut est ensuite encodé en tant que paramètre d'en-tête non protégé.

3.3. Processus de signature et de vérification

Afin de créer une signature, une chaîne d'octets bien définie est nécessaire. La Countersign_structure est utilisée pour créer la forme canonique. Ce processus de signature et de vérification prend en entrée la structure cible de la contresignature (COSE_Signature, COSE_Sign1, COSE_Sign, COSE_Mac, COSE_Mac0, COSE_Encrypt ou COSE_Encrypt0), les informations du signataire (COSE_Signature) et les données d'application (source externe). Une Countersign_structure est un tableau CBOR. La structure cible de la contresignature doit avoir toutes ses fonctions cryptographiques finalisées avant de calculer la signature. Les champs de la Countersign_structure, dans l'ordre, sont :

context : Une chaîne de texte contextuelle identifiant le contexte de la signature. La chaîne de texte contextuelle est l'une des suivantes :

• "CounterSignature" pour les contresignatures utilisant la structure COSE_Countersignature lorsque other_fields est absent.

• "CounterSignature0" pour les contresignatures utilisant la structure COSE_Countersignature0 lorsque other_fields est absent.

• "CounterSignatureV2" pour les contresignatures utilisant la structure COSE_Countersignature lorsque other_fields est présent.

• "CounterSignature0V2" pour les contresignatures utilisant la structure COSE_Countersignature0 lorsque other_fields est présent.

body_protected : Les attributs protégés sérialisés de la structure cible, encodés dans un type bstr. S'il n'y a pas d'attributs protégés, une chaîne d'octets de longueur nulle est utilisée.

sign_protected : Les attributs protégés sérialisés de la structure du signataire, encodés dans un type bstr. S'il n'y a pas d'attributs protégés, une chaîne d'octets de longueur nulle est utilisée. Ce champ est omis pour l'attribut Countersignature0V2.

external_aad : Les données authentifiées supplémentaires (AAD) fournies de manière externe par l'application, encodées dans un type bstr. Si ce champ n'est pas fourni, il s'agit par défaut d'une chaîne d'octets de longueur nulle. (Voir la section 4.4 de la [RFC9052] pour les conseils d'application sur la construction de ce champ.)

payload : La charge utile à signer, encodée dans un type bstr. La charge utile est placée ici indépendamment de la façon dont elle est transportée.

other_fields : Omis s'il n'y a que deux champs bstr dans la structure cible. Ce champ est un tableau de tous les champs bstr après le second. À titre d'exemple, ce serait un tableau d'un élément pour la structure COSE_Sign1 contenant la valeur de la signature.

Le fragment CDDL qui décrit le texte ci-dessus est :

Countersign_structure = [
  context : "CounterSignature" / "CounterSignature0" /
            "CounterSignatureV2" / "CounterSignature0V2" /,
  body_protected : empty_or_serialized_map,
  ? sign_protected : empty_or_serialized_map,
  external_aad : bstr,
  payload : bstr,
  ? other_fields : [+ bstr ]
]

Comment calculer une contresignature :

1. Créez une Countersign_structure et remplissez-la avec les champs appropriés.

2. Créez la valeur ToBeSigned en encodant la Countersign_structure en une chaîne d'octets, en utilisant l'encodage décrit dans la section 4.

3. Appelez l'algorithme de création de signature en passant K (la clé pour signer), alg (l'algorithme pour signer) et ToBeSigned (la valeur à signer).

4. Placez la valeur de signature résultante à l'emplacement correct. C'est le champ « signature » de la structure COSE_Countersignature pour les contresignatures complètes (voir section 3.1). C'est la valeur de l'attribut Countersignature0 pour les contresignatures abrégées (voir section 3.2).

Les étapes de vérification d'une contresignature :

1. Créez une Countersign_structure et remplissez-la avec les champs appropriés.

2. Créez la valeur ToBeSigned en encodant la Countersign_structure en une chaîne d'octets, en utilisant l'encodage décrit dans la section 4.

3. Appelez l'algorithme de vérification de signature en passant K (la clé pour vérifier), alg (l'algorithme utilisé pour signer), ToBeSigned (la valeur à signer) et sig (la signature à vérifier).

En plus d'effectuer la vérification de la signature, l'application effectue les vérifications appropriées pour s'assurer que la clé est correctement couplée avec l'identité de signature et que l'identité de signature est autorisée avant d'effectuer des actions.