RFC 9052

Internet Engineering Task Force (IETF) J. Schaad Request for Comments: 9052 August Cellars STD: 96 Août 2022 Obsoletes: 8152 Category: Standards Track ISSN: 2070-1721

Signature et chiffrement d'objets CBOR (COSE) : Structures et processus

Résumé

Concise Binary Object Representation (CBOR) est un format de données conçu pour une petite taille de code et une petite taille de message. Il est nécessaire de pouvoir définir des services de sécurité de base pour ce format de données. Ce document définit le protocole CBOR Object Signing and Encryption (COSE). Cette spécification décrit comment créer et traiter des signatures, des codes d'authentification de message et du chiffrement en utilisant CBOR pour la sérialisation. Cette spécification décrit en outre comment représenter les clés cryptographiques à l'aide de CBOR.

Ce document, avec la RFC 9053, rend obsolète la RFC 8152.

Statut de ce mémo

Ceci est un document de la voie des normes Internet.

Ce document est un produit de l'Internet Engineering Task Force (IETF). Il représente le consensus de la communauté IETF. Il a fait l'objet d'un examen public et a été approuvé pour publication par l'Internet Engineering Steering Group (IESG). De plus amples informations sur les normes Internet sont disponibles dans la section 2 de la RFC 7841.

Des informations sur le statut actuel de ce document, les errata éventuels et la manière de fournir des commentaires à son sujet peuvent être obtenues à l'adresse https://www.rfc-editor.org/info/rfc9052.

Avis de droit d'auteur

Ce document est soumis au BCP 78 et aux dispositions légales du IETF Trust relatives aux documents IETF (https://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Veuillez examiner ces documents attentivement, car ils décrivent vos droits et restrictions concernant ce document. Les composants de code extraits de ce document doivent inclure le texte de la licence BSD révisée tel que décrit dans la section 4.e des dispositions légales du Trust et sont fournis sans garantie telle que décrite dans la licence BSD révisée.

Table des matières

Introduction 1.1. Terminologie des exigences 1.2. Changements par rapport à la RFC 8152 1.3. Changements de conception par rapport à JOSE 1.4. Grammaire CDDL pour les structures de données CBOR 1.5. Terminologie liée à CBOR 1.6. Terminologie du document
Structure COSE de base
Paramètres d'en-tête 3.1. Paramètres d'en-tête COSE communs
Objets de signature 4.1. Signature avec un ou plusieurs signataires 4.2. Signature avec un seul signataire 4.3. Données fournies en externe 4.4. Processus de signature et de vérification
Objets de chiffrement 5.1. Structure COSE enveloppée 5.1.1. Méthodes de distribution de clé de contenu 5.2. Chiffrement à destinataire unique 5.3. Comment chiffrer et déchiffrer pour les algorithmes AEAD 5.4. Comment chiffrer et déchiffrer pour les algorithmes AE
Objets MAC 6.1. Message MACé avec destinataires 6.2. Messages MACés avec clé implicite 6.3. Comment calculer et vérifier un MAC
Objets clés 7.1. Paramètres communs de clé COSE
Taxonomie des algorithmes utilisés par COSE 8.1. Algorithmes de signature 8.2. Algorithmes de code d'authentification de message (MAC) 8.3. Algorithmes de chiffrement de contenu 8.4. Fonctions de dérivation de clé (KDF) 8.5. Méthodes de distribution de clé de contenu 8.5.1. Chiffrement direct 8.5.2. Enveloppement de clé 8.5.3. Transport de clé 8.5.4. Accord de clé direct 8.5.5. Accord de clé avec enveloppement de clé
Restrictions d'encodage CBOR
Considérations sur le profilage des applications
Considérations IANA 11.1. Registre des paramètres d'en-tête COSE 11.2. Registre des paramètres communs de clé COSE 11.3. Enregistrements de type de média 11.3.1. Message de sécurité COSE 11.3.2. Type de média de clé COSE 11.4. Registre des formats de contenu CoAP 11.5. Registre des étiquettes CBOR 11.6. Instructions d'examen par des experts
Considérations de sécurité
Références 13.1. Références normatives 13.2. Références informatives Annexe A. Lignes directrices pour l'authentification des données externes des algorithmes Annexe B. Deux couches d'informations sur les destinataires Annexe C. Exemples C.1. Exemples de messages signés C.1.1. Signature unique C.1.2.ieurs signataires C.1.3. Signature avec criticité C.2. Exemples de signataire unique C.2.1. Signature ECDSA unique C.3. Exemples de messages enveloppés C.3.1. ECDH direct C.3.2. Direct plus dérivation de clé C.3.3. Contenu chiffré avec données externes C.4. Exemples de messages chiffrés C.4.1. Message chiffré simple C.4.2. Message chiffré avec un IV partiel C.5. Exemples de messages MACés C.5.1. MAC direct à secret partagé C.5.2. MAC direct ECDH C.5.3. MAC enveloppé C.5.4. Message MACé à plusieurs destinataires C.6. Exemples de messages MAC0 C.6.1. MAC direct à secret partagé C.7. Clés COSE C.7.1. Clés publiques C.7.2. Clés privées Remerciements Adresse de l'auteur
Introduction

L'accent est de plus en plus mis sur les petits dispositifs contraints qui composent l'Internet des objets (IoT). L'une des normes issues de ce processus est la "Concise Binary Object Representation (CBOR)" [STD94]. CBOR a étendu le modèle de données de JavaScript Object Notation (JSON) [STD90] en autorisant les données binaires, entre autres changements. CBOR a été adopté par plusieurs groupes de travail de l'IETF traitant du monde de l'IoT 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 existe un besoin de fournir des services de sécurité des messages pour l'IoT, et l'utilisation de CBOR comme format d'encodage des messages est logique.

Le groupe de travail JOSE a produit un ensemble de documents [RFC7515] [RFC7516] [RFC7517] [RFC7518] qui spécifiaient comment traiter les opérations de chiffrement, de signature et de code d'authentification de message (MAC) et comment encoder les clés à l'aide de JSON. Ce document définit la norme CBOR Object Signing and Encryption (COSE), qui fait la même chose pour le format d'encodage CBOR. Ce document est combiné avec [RFC9053], qui fournit un ensemble initial d'algorithmes. Bien qu'il y ait une forte tentative de conserver la saveur des documents JSON Object Signing and Encryption (JOSE) originaux, deux considérations sont prises en compte :

CBOR a des capacités qui ne sont pas présentes dans JSON et qui sont appropriées à utiliser. Un exemple de cela est le fait que CBOR a une méthode pour encoder directement des données binaires sans les convertir d'abord en une chaîne de texte encodée en base64.
COSE n'est pas une copie directe de la spécification JOSE. Dans le processus de création de COSE, les décisions qui ont été prises pour JOSE ont été réexaminées. Dans de nombreux cas, des résultats différents ont été décidés, car les critères n'étaient pas toujours les mêmes.

Ce document contient :

La description de la structure des objets CBOR qui sont transmis sur le fil. Deux objets chacun sont définis pour le chiffrement, la signature et l'authentification des messages. Un objet est défini pour transporter des clés et un pour transporter des groupes de clés.
Les procédures utilisées pour construire les entrées des fonctions cryptographiques requises pour chacune des structures.
Un ensemble d'attributs qui s'appliquent aux différents objets de sécurité.

Ce document ne contient pas les règles et procédures d'utilisation d'algorithmes cryptographiques spécifiques. Les détails sur les algorithmes spécifiques peuvent être trouvés dans [RFC9053] et [RFC8230]. Les détails pour les algorithmes supplémentaires devraient être définis dans de futurs documents.

COSE a été initialement conçu dans le cadre d'une solution pour fournir une sécurité aux environnements RESTful contraints (CoRE), et cela est fait en utilisant [RFC8613] et [CORE-GROUPCOMM]. Cependant, COSE n'est pas limité à ces seuls cas et peut être utilisé dans tout endroit où l'on envisagerait soit JOSE soit Cryptographic Message Syntax (CMS) [RFC5652] dans le but de fournir des services de sécurité. COSE, comme JOSE et CMS, est uniquement destiné à être utilisé dans des protocoles de stockage et retransmission ou hors ligne. L'utilisation de COSE dans des protocoles en ligne nécessitant un chiffrement nécessite qu'un processus d'établissement de clé en ligne soit effectué avant d'envoyer des objets dans les deux sens. Toute application qui utilise COSE pour des services de sécurité doit d'abord déterminer quels services de sécurité sont requis, puis sélectionner les structures COSE et les algorithmes cryptographiques appropriés en fonction de ces besoins. La section 10 fournit des informations supplémentaires sur ce que les applications doivent spécifier lors de l'utilisation de COSE.

Une fonctionnalité présente dans CMS qui n'est pas présente dans cette norme est une structure de condensé (digest). Cette omission est délibérée. Il est préférable que la structure soit définie dans chaque protocole car différents protocoles voudront inclure un ensemble différent de champs dans le cadre de la structure. Bien qu'un identifiant d'algorithme et la valeur du condensé soient communs à toutes les applications, les deux valeurs peuvent ne pas toujours être adjacentes, car l'algorithme pourrait être défini une fois avec plusieurs valeurs. Les applications peuvent en outre vouloir définir des champs de données supplémentaires dans le cadre de la structure. Un tel élément spécifique à l'application serait d'inclure un URI ou un autre pointeur vers l'endroit où les données hachées peuvent être obtenues. [RFC9054] contient une telle structure possible et définit un ensemble d'algorithmes de condensé.

Au cours du processus d'avancement de COSE vers la norme Internet, il a été remarqué que la description des propriétés de sécurité des contre-signatures était incorrecte pour la structure COSE_Sign1. Étant donné que les propriétés de sécurité qui étaient décrites -- celles d'une véritable contre-signature -- étaient celles que le groupe de travail souhaitait, la décision a été prise de supprimer tout le texte de contre-signature de ce document et de créer un nouveau document [COSE-COUNTERSIGN] pour à la fois rendre obsolète l'ancien algorithme de contre-signature et les paramètres d'en-tête et définir un nouvel algorithme et des paramètres d'en-tête avec les propriétés de sécurité souhaitées.

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 BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.

1.2. Changements par rapport à la RFC 8152

Division du document original en ce document et [RFC9053].
Ajout de texte décrivant pourquoi il n'y a pas de structure de condensé définie par COSE.
Clarifications du texte et changements de terminologie.
Suppression de tous les détails relatifs aux contre-signatures et placement dans [COSE-COUNTERSIGN].

1.3. Changements de conception par rapport à JOSE

Une structure de message globale unique a été définie afin que les messages chiffrés, signés et MACés puissent être facilement identifiés et avoir toujours une vue cohérente.
Les messages signés distinguent entre les paramètres d'en-tête protégés et non protégés qui se rapportent au contenu et ceux qui se rapportent à la signature.
Les messages MACés sont séparés des messages signés.
Les messages MACés ont la capacité d'utiliser le même ensemble d'algorithmes de destinataire que les messages enveloppés pour obtenir la clé d'authentification MAC.
Les encodages binaires sont utilisés, plutôt que les encodages base64url, pour encoder les données binaires.
L'étiquette d'authentification pour les algorithmes de chiffrement a été combinée avec le texte chiffré.
L'ensemble des algorithmes cryptographiques a été étendu dans certaines directions et réduit dans d'autres.

1.4. Grammaire CDDL pour les structures de données CBOR

Lorsque COSE a été écrit à l'origine, le Concise Data Definition Language (CDDL) [RFC8610] n'avait pas encore été publié dans une RFC, il ne pouvait donc pas être utilisé comme langage de description de données pour décrire normativement les structures de données CBOR employées par COSE. Pour cette raison, les objets de données CBOR définis ici sont décrits en prose. Des descriptions supplémentaires (non normatives) des objets de données COSE sont fournies dans un sous-ensemble de CDDL, décrit ci-dessous.

Ce document a été développé en travaillant d'abord sur la grammaire, puis en développant la prose pour l'accompagner. Un artefact de cela est que la prose a été écrite en utilisant les chaînes de type primitif définies par le Concise Data Definition Language (CDDL) [RFC8610]. Dans cette spécification, les types primitifs suivants sont utilisés :

any : Une valeur non spécifique qui permet de placer toutes les valeurs CBOR ici.

bool : Une valeur booléenne (type majeur 7, valeur 21 ; false : type majeur 7, valeur 20).

bstr : Chaîne d'octets (type majeur 2).

int : Un entier non signé ou un entier négatif.

nil : Une valeur nulle (type majeur 7, valeur 22).

nint : Un entier négatif (type majeur 1).

tstr : Une chaîne de texte UTF-8 (type majeur 3).

uint : Un entier non signé (type majeur 0).

Trois syntaxes de CDDL apparaissent dans ce document comme raccourci. Ce sont :

FOO / BAR : Indique que soit FOO soit BAR peut apparaître ici.

[+ FOO] : Indique que le type FOO apparaît une ou plusieurs fois dans un tableau.

FOO : Indique que le type FOO apparaît zéro ou plusieurs fois.

Deux des contraintes définies par CDDL sont également utilisées dans ce document. Ce sont :

type1 .cbor type2 : Indique que le contenu de type1, généralement bstr, contient une valeur de type2.

type1 .size integer : Indique que le contenu de type1 a une longueur de integer octets.

Outre la description en prose, une grammaire pour les structures de données CBOR est présentée dans le sous-ensemble de CDDL décrit précédemment. La grammaire CDDL est informative ; la description en prose est normative.

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_Messages / COSE_Key / COSE_KeySet / Internal_Types

; Ceci est défini pour rendre l'outil plus silencieux : Internal_Types = Sig_structure / Enc_structure / MAC_structure

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 fait référence à ces non-terminaux qui sont utilisés pour les calculs de sécurité mais ne sont pas émis pour le transport.

1.5. Terminologie liée à CBOR

En JSON, les cartes sont appelées objets et n'ont qu'un seul type de clé de carte : une chaîne de texte. Dans COSE, nous utilisons des chaînes de texte, des entiers négatifs et des entiers non signés comme clés de carte. Les entiers sont utilisés pour la compacité de l'encodage et la facilité de comparaison. l'inclusion de chaînes de texte permet d'utiliser une gamme supplémentaire de valeurs encodées courtes. Étant donné que le mot "key" (clé) est principalement utilisé dans son autre sens, en tant que clé cryptographique, nous utilisons le terme "label" (étiquette) pour cet usage en tant que clé de carte.

Dans une carte CBOR définie par cette spécification, la présence d'une étiquette qui n'est ni une chaîne de texte ni un entier est une erreur. Les applications peuvent soit échouer le traitement, soit traiter les messages en ignorant les étiquettes incorrectes ; cependant, elles NE DOIVENT PAS (MUST NOT) créer de messages avec des étiquettes incorrectes.

Un fragment de grammaire CDDL définit le non-terminal "label", comme dans le paragraphe précédent, et "values", qui permet d'utiliser n'importe quelle valeur.

label = int / tstr values = any

1.6. Terminologie du document

Dans ce document, nous utilisons la terminologie suivante :

Byte : Un synonyme d'octet.

Constrained Application Protocol (CoAP) : Un protocole de transfert web spécialisé pour une utilisation dans des systèmes contraints. Il est défini dans [RFC7252].

Authenticated Encryption (AE) algorithms [RFC5116] : Algorithmes de chiffrement qui fournissent une vérification d'authentification du contenu avec le service de chiffrement. Un exemple d'algorithme AE utilisé dans COSE est AES Key Wrap [RFC3394]. Ces algorithmes sont utilisés pour le chiffrement de clé, mais les algorithmes de chiffrement authentifié avec données associées (AEAD) seraient préférés.

AEAD algorithms [RFC5116] : Algorithmes de chiffrement qui fournissent le même service d'authentification du contenu que les algorithmes AE, et permettent également d'inclure des données associées qui ne font pas partie du corps chiffré dans le service d'authentification. Un exemple d'algorithme AEAD utilisé dans COSE est AES-GCM [RFC5116]. Ces algorithmes sont utilisés pour le chiffrement de contenu et peuvent également être utilisés pour le chiffrement de clé.

"Context" (Contexte) est utilisé tout au long du document pour représenter des informations qui ne font pas partie du message COSE. Les informations qui font partie du contexte peuvent provenir de plusieurs sources différentes, y compris les interactions de protocole, les structures de clés associées et la configuration du programme. Le contexte à utiliser peut être implicite, identifié à l'aide du paramètre d'en-tête "kid context" défini dans [RFC8613], ou identifié par 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.3.

Le terme "byte string" (chaîne d'octets) est utilisé pour les séquences d'octets, tandis que le terme "text string" (chaîne de texte) est utilisé pour les séquences de caractères.