1. Introduction
L'attention s'est accrue sur les petits dispositifs contraints qui constituent l'Internet des objets (IdO). L'une des normes issues de ce processus est la « représentation concise d'objets binaires (CBOR) » [RFC8949]. CBOR a étendu le modèle de données de la notation d'objet JavaScript (JSON) [STD90] en permettant les données binaires, entre autres changements. CBOR a été adopté par plusieurs groupes de travail de l'IETF traitant du monde de l'IdO comme méthode d'encodage des structures de données. CBOR a été conçu spécifiquement pour être petit en termes de messages transportés et de taille d'implémentation et pour avoir un décodeur sans schéma. Il est nécessaire de fournir des services de sécurité des messages pour l'IdO, et l'utilisation de CBOR comme format d'encodage des messages est logique.
Une contresignature est une seconde signature qui confirme la signature principale. Au cours du processus d'avancement de la signature et du chiffrement d'objets CBOR (COSE) vers la norme Internet, il a été remarqué que la description des propriétés de sécurité des contresignatures était incorrecte pour la structure COSE_Sign1 mentionnée dans la section 4.5 de la [RFC8152]. Pour remédier à cette situation, le groupe de travail COSE a décidé de supprimer tout le texte sur les contresignatures de la [RFC9052], qui remplace la [RFC8152]. Ce document définit une nouvelle contresignature avec les propriétés de sécurité souhaitées.
Le problème avec l'algorithme de contresignature précédent était que la valeur calculée cryptographiquement n'était pas toujours incluse. L'hypothèse initiale selon laquelle la valeur cryptographique se trouvait dans le troisième emplacement du tableau était connue pour ne pas être vraie à l'époque, mais dans le cas des structures de code d'authentification de message (MAC), cela n'a pas été jugé problématique. Le nouvel algorithme défini dans ce document exige l'inclusion de plus de valeurs pour le calcul de la contresignature. L'exception à cela est la structure COSE_Signature où il n'y a pas de valeur calculée cryptographiquement.
Le nouvel algorithme défini dans ce document est conçu pour produire la même valeur de contresignature dans les cas où la valeur cryptographique calculée était déjà incluse. Cela signifie que pour ces structures, la seule chose à faire est de changer la valeur du paramètre d'en-tête.
Avec la publication de ce document, les implémenteurs sont encouragés à migrer les utilisations de l'algorithme de contresignature précédent vers celui spécifié dans ce document. En particulier, les utilisations de « CounterSignature » migreront vers « CounterSignatureV2 », et les utilisations de « CounterSignature0 » migreront vers « CounterSignature0V2 ». De plus, la vérification de « CounterSignature » doit être prise en charge par les nouvelles implémentations pour rester compatibles avec les expéditeurs qui adhèrent à la [RFC8152], qui suppose que toutes les implémentations comprendront « CounterSignature » comme l'étiquette de paramètre d'en-tête 7. De même, la vérification de « CounterSignature0 » peut être prise en charge pour une compatibilité ultérieure.
1.1. Terminologie des exigences
Les mots clés « MUST », « MUST NOT », « REQUIRED », « SHALL », « SHALL NOT », « SHOULD », « SHOULD NOT », « RECOMMENDED », « NOT RECOMMENDED », « MAY » et « OPTIONAL » dans ce document doivent être interprétés comme décrit dans le BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en toutes lettres majuscules, comme indiqué ici.
1.2. Grammaire CBOR
La grammaire CBOR dans ce document utilise le langage de définition de données concis (CDDL) [RFC8610].
Le CDDL collecté peut être extrait de la version XML de ce document via l'expression XPath ci-dessous. (Selon l'évaluateur XPath que l'on utilise, il peut être nécessaire de traiter > comme une entité.)
//sourcecode[@type='cddl']/text()
CDDL s'attend à ce que le symbole non terminal initial soit le premier symbole du fichier. Pour cette raison, le premier fragment de CDDL est présenté ici.
start = COSE_Countersignature_Tagged / Internal_Types
; This is defined to make the tool quieter:
Internal_Types = Countersign_structure / COSE_Countersignature0
Le non-terminal Internal_Types est défini pour traiter les outils de validation automatisés utilisés lors de la rédaction de ce document. Il référence les non-terminaux qui sont utilisés pour les calculs de sécurité mais qui ne sont pas émis pour le transport.
1.3. Terminologie du document
Dans ce document, nous utilisons la terminologie suivante.
« Byte » (octet) est un synonyme de « octet ».
Le protocole d'application contraint (CoAP) est un protocole de transfert Web spécialisé destiné à être utilisé dans des systèmes contraints. Il est défini dans la [RFC7252].
« Context » (contexte) est utilisé tout au long de ce document pour représenter des informations qui ne font pas partie du message COSE. Les informations qui font partie du contexte peuvent provenir de différentes sources, notamment des interactions de protocole, des structures de clés associées et de la configuration de l'application. Le contexte à utiliser peut être implicite, identifié à l'aide du paramètre d'en-tête « kid context » défini dans la [RFC8613] ou un identifiant spécifique au protocole. Le contexte doit généralement être inclus dans la construction cryptographique ; pour plus de détails, voir la section 4.4 de la [RFC9052].
Le terme « byte string » (chaîne d'octets) est utilisé pour des séquences d'octets, tandis que le terme « text string » (chaîne de texte) est utilisé pour des séquences de caractères.