3. Paramètres d'en-tête

Paramètres d'en-tête

La structure de COSE a été conçue pour avoir deux compartiments d'informations qui ne sont pas considérés comme faisant partie de la charge utile elle-même, mais qui sont utilisés pour contenir des informations sur le contenu, les algorithmes, les clés ou des conseils d'évaluation pour le traitement de la couche. Ces deux compartiments sont disponibles pour une utilisation dans toutes les structures, à l'exception des clés. Bien que ces compartiments soient présents, ils ne sont pas toujours utilisables dans tous les cas. Par exemple, bien que le compartiment protégé soit défini comme faisant partie de la structure du destinataire, certains des algorithmes utilisés pour les structures de destinataire ne fournissent pas de données authentifiées. Si tel est le cas, le compartiment protégé est laissé vide.

Les deux compartiments sont mis en œuvre sous forme de cartes CBOR. La clé de la carte est une « étiquette » (Section 1.5). La partie valeur dépend de la définition de l'étiquette. Les deux cartes utilisent le même ensemble de paires étiquette/valeur. Les valeurs entières et de chaîne de texte pour les étiquettes ont été divisées en plusieurs sections, y compris une plage standard, une plage d'utilisation privée et une plage qui dépend de l'algorithme sélectionné. Les étiquettes définies se trouvent dans le registre IANA « COSE Header Parameters » (Section 11.1).

Les deux compartiments sont :

protected (protégé) : Contient des paramètres concernant la couche actuelle qui sont protégés cryptographiquement. Ce compartiment DOIT être vide s'il ne doit pas être inclus dans un calcul cryptographique. Ce compartiment est encodé dans le message en tant qu'objet binaire. Cette valeur est obtenue par l'encodage CBOR de la carte protégée et en l'enveloppant dans un objet bstr. Les expéditeurs DEVRAIENT encoder une carte de longueur nulle comme une chaîne d'octets de longueur nulle plutôt que comme une carte de longueur nulle (encodée comme h'a0'). L'encodage de chaîne d'octets de longueur nulle est préféré, car il est à la fois plus court et la version utilisée dans les structures de sérialisation pour le calcul cryptographique. Les destinataires DOIVENT accepter à la fois une chaîne d'octets de longueur nulle et une carte de longueur nulle encodée dans une chaîne d'octets.

  Envelopper l'encodage avec une chaîne d'octets permet de transporter la carte protégée avec une plus grande probabilité qu'elle ne soit pas modifiée accidentellement en transit. (Les intermédiaires mal comportés pourraient décoder et ré-encoder, mais cela entraînera un échec de la vérification à moins que la chaîne d'octets ré-encodée ne soit identique à la chaîne d'octets décodée.) Cela évite le problème que toutes les parties aient besoin de pouvoir faire un encodage canonique commun de la carte pour l'entrée des opérations cryptographiques.

unprotected (non protégé) : Contient des paramètres concernant la couche actuelle qui ne sont pas protégés cryptographiquement.

Seuls les paramètres d'en-tête qui traitent de la couche actuelle doivent être placés à cette couche. À titre d'exemple, le paramètre d'en-tête « content type » décrit le contenu du message transporté dans le message. En tant que tel, ce paramètre d'en-tête est placé uniquement dans la couche de contenu et n'est pas placé dans les couches de destinataire ou de signature. En principe, on devrait pouvoir traiter n'importe quelle couche donnée sans référence à une autre couche. À l'exception de la structure COSE_Sign, les seules données qui doivent traverser les couches sont la clé cryptographique.

Les compartiments sont présents dans tous les objets de sécurité définis dans ce document. Les champs, dans l'ordre, sont le compartiment « protégé » (en tant que type CBOR « bstr ») et ensuite le compartiment « non protégé » (en tant que type CBOR « map »). La présence des deux compartiments est requise. Les paramètres d'en-tête qui vont dans les compartiments proviennent du registre IANA « COSE Header Parameters » (Section 11.1). Certains paramètres d'en-tête sont définis dans la section suivante.

Les étiquettes dans chacune des cartes DOIVENT être uniques. Lors du traitement des messages, si une étiquette apparaît plusieurs fois, le message DOIT être rejeté comme malformé. Les applications DEVRAIENT vérifier que la même étiquette ne se produit pas à la fois dans les paramètres d'en-tête protégés et non protégés. Si le message n'est pas rejeté comme malformé, les attributs DOIVENT être obtenus à partir du compartiment protégé, et seulement si un attribut n'est pas trouvé dans le compartiment protégé, cet attribut peut être obtenu à partir du compartiment non protégé.

Le fragment CDDL suivant représente les deux compartiments de paramètres d'en-tête. Un groupe « Headers » est défini en CDDL qui représente les deux compartiments dans lesquels les attributs sont placés. Ce groupe est utilisé pour fournir ces deux champs de manière cohérente dans tous les emplacements. Un type est également défini qui représente la carte des paramètres d'en-tête communs.

   Headers = (
       protected : empty_or_serialized_map,
       unprotected : header_map
   )

   header_map = {
       Generic_Headers,
       * label => values
   }

   empty_or_serialized_map = bstr .cbor header_map / bstr .size 0

3.1. Paramètres d'en-tête COSE communs

Cette section définit un ensemble de paramètres d'en-tête communs. Un résumé de ces paramètres d'en-tête se trouve dans le Tableau 3. Ce tableau doit être consulté pour déterminer la valeur de l'étiquette et le type de la valeur.

L'ensemble des paramètres d'en-tête définis dans cette section est le suivant :

alg : Ce paramètre d'en-tête est utilisé pour indiquer l'algorithme utilisé pour le traitement de sécurité. Ce paramètre d'en-tête DOIT être authentifié lorsque la capacité de le faire existe. Ce support est fourni par des algorithmes AEAD ou une construction (par exemple, COSE_Sign et COSE_Mac0). Cette authentification peut être effectuée soit par le placement du paramètre d'en-tête dans le compartiment des paramètres d'en-tête protégés, soit dans le cadre des données fournies de manière externe (Section 4.3). La valeur est tirée du registre « COSE Algorithms » (voir [COSE.Algorithms]).

crit : Ce paramètre d'en-tête est utilisé pour indiquer quels paramètres d'en-tête protégés une application qui traite un message est tenue de comprendre. Les paramètres d'en-tête définis dans ce document n'ont pas besoin d'être inclus, car ils devraient être compris par toutes les mises en œuvre. De plus, le paramètre d'en-tête « counter signature » (étiquette 7) défini par [RFC8152] doit être compris par les nouvelles mises en œuvre, pour rester compatible avec les expéditeurs qui adhèrent à ce document et supposent que toutes les mises en œuvre le comprendront. Lorsqu'il est présent, le paramètre d'en-tête « crit » DOIT être placé dans le compartiment des paramètres d'en-tête protégés. Le tableau DOIT avoir au moins une valeur dedans.

  Toutes les étiquettes de paramètres d'en-tête n'ont pas besoin d'être incluses dans le paramètre d'en-tête « crit ». Les règles pour décider quels paramètres d'en-tête sont placés dans le tableau sont :

  *  Les étiquettes entières dans la plage de 0 à 7 DEVRAIENT être omises.

  *  Les étiquettes entières dans la plage -1 à -128 peuvent être omises. Les algorithmes peuvent attribuer des étiquettes dans cette plage où la capacité de traiter le contenu de l'étiquette est considérée comme centrale pour la mise en œuvre de l'algorithme. Les algorithmes peuvent attribuer des étiquettes en dehors de cette plage et les inclure dans le paramètre d'en-tête « crit » lorsque la capacité de traiter le contenu de l'étiquette n'est pas considérée comme une fonctionnalité centrale de l'algorithme mais doit être comprise pour traiter correctement cette instance. Les étiquettes entières dans la plage -129 à -65536 DEVRAIENT être incluses, car ce seraient des paramètres d'en-tête moins courants qui pourraient ne pas être généralement pris en charge.

  *  Les étiquettes pour les paramètres d'en-tête requis pour une application PEUVENT être omises. Les applications devraient avoir une déclaration déclarant si l'étiquette peut être omise ou non.

  Les paramètres d'en-tête indiqués par « crit » peuvent être traités soit par le code de la bibliothèque de sécurité, soit par une application utilisant une bibliothèque de sécurité ; la seule exigence est que le paramètre d'en-tête soit traité. Si la liste de valeurs « crit » comprend une étiquette pour laquelle le paramètre d'en-tête n'est pas dans le compartiment des paramètres d'en-tête protégés, c'est une erreur fatale dans le traitement du message.

content type : Ce paramètre d'en-tête est utilisé pour indiquer le type de contenu des données dans le champ « payload » ou « ciphertext ». Les entiers proviennent du tableau de registre IANA « CoAP Content-Formats » [COAP.Formats]. Les valeurs textuelles suivent la syntaxe de « <type-name>/<subtype-name> », où <type-name> et <subtype-name> sont définis dans la Section 4.2 de [RFC6838]. Les espaces de début et de fin ne sont pas autorisés. Les valeurs de type de contenu textuel, ainsi que les paramètres et sous-paramètres, peuvent être localisés à l'aide du registre IANA « Media Types ». Les applications DEVRAIENT fournir ce paramètre d'en-tête si la structure du contenu est potentiellement ambiguë.

kid : Ce paramètre d'en-tête identifie un élément de données qui peut être utilisé comme entrée pour trouver la clé cryptographique nécessaire. La valeur de ce paramètre d'en-tête peut être mise en correspondance avec le membre « kid » dans une structure COSE_Key. D'autres méthodes de distribution de clés peuvent définir un champ équivalent à mettre en correspondance. Les applications NE DOIVENT PAS supposer que les valeurs « kid » sont uniques. Il peut y avoir plus d'une clé avec la même valeur « kid », donc toutes les clés associées à ce « kid » peuvent devoir être vérifiées. La structure interne des valeurs « kid » n'est pas définie et ne peut pas être invoquée par les applications. Les valeurs d'identifiant de clé sont des indications sur la clé à utiliser. Ce n'est pas un champ critique pour la sécurité. Pour cette raison, il peut être placé dans le compartiment des paramètres d'en-tête non protégés.

IV : Ce paramètre d'en-tête contient la valeur du vecteur d'initialisation (IV). Pour certains algorithmes de chiffrement symétrique, cela peut être appelé un nonce. L'IV peut être placé dans le compartiment non protégé, car pour les algorithmes AE et AEAD, la modification de l'IV entraînera l'échec du déchiffrement.

Partial IV : Ce paramètre d'en-tête contient une partie de la valeur IV. Lors de l'utilisation de la structure COSE_Encrypt0, une partie de l'IV peut faire partie du contexte associé à la clé (Context IV), tandis qu'une partie peut être modifiée avec chaque message (Partial IV). Ce champ est utilisé pour transporter une valeur qui fait que l'IV est modifié pour chaque message. Le Partial IV peut être placé dans le compartiment non protégé, car la modification de la valeur fera en sorte que le déchiffrement produise un texte clair qui est facilement détectable comme brouillé. Les paramètres d'en-tête « Initialization Vector » et « Partial Initialization Vector » NE DOIVENT PAS être tous deux présents dans la même couche de sécurité.

  L'IV du message est généré par les étapes suivantes :

  1.  Remplir à gauche le Partial IV avec des zéros jusqu'à la longueur de l'IV (déterminée par l'algorithme).

  2.  XOR le Partial IV rempli avec le Context IV.

                 Tableau 3 : Paramètres d'en-tête communs

Le fragment CDDL qui représente l'ensemble des paramètres d'en-tête définis dans cette section est donné ci-dessous. Chacun des paramètres d'en-tête est marqué comme optionnel, car ils n'ont pas besoin d'être dans chaque carte ; les paramètres d'en-tête requis dans des cartes spécifiques sont discutés ci-dessus.

   Generic_Headers = (
       ? 1 => int / tstr,  ; algorithm identifier
       ? 2 => [+label],    ; criticality
       ? 3 => tstr / int,  ; content type
       ? 4 => bstr,        ; key identifier
       ? ( 5 => bstr //    ; IV
           6 => bstr )     ; Partial IV
   )