10. Considérations relatives à l'IANA

10. Considérations relatives à l'IANA

L'IANA a mis à jour tous les registres COSE à l'exception de "COSE Header Parameters" et "COSE Key Common Parameters" pour pointer vers ce document au lieu de [RFC8152].

10.1. Modifications du registre "COSE Key Types"

L'IANA a ajouté une nouvelle colonne dans le registre "COSE Key Types". La nouvelle colonne est intitulée "Capabilities" (Capacités) et a été remplie selon les entrées du Tableau 22.

        +=======+===========+============================+
        | Valeur| Nom       | Capacités                  |
        +=======+===========+============================+
        | 1     | OKP       | [kty(1), crv]              |
        +-------+-----------+----------------------------+
        | 2     | EC2       | [kty(2), crv]              |
        +-------+-----------+----------------------------+
        | 3     | RSA       | [kty(3)]                   |
        +-------+-----------+----------------------------+
        | 4     | Symmetric | [kty(4)]                   |
        +-------+-----------+----------------------------+
        | 5     | HSS-LMS   | [kty(5), algo de hachage]  |
        +-------+-----------+----------------------------+
        | 6     | WalnutDSA | [kty(6), valeur N, val q]  |
        +-------+-----------+----------------------------+

                 Tableau 22 : Capacités de type de clé

10.2. Modifications du registre "COSE Algorithms"

L'IANA a ajouté une nouvelle colonne dans le registre "COSE Algorithms". La nouvelle colonne est intitulée "Capabilities" (Capacités) et a été remplie avec "[kty]" pour tous les enregistrements actuels et non provisoires.

L'IANA a mis à jour la colonne Référence dans le registre "COSE Algorithms" pour inclure ce document comme référence pour toutes les lignes où il n'était pas déjà présent.

L'IANA a ajouté une nouvelle ligne au registre "COSE Algorithms".

+===============+=======+===============+===========+=============+
| Nom           | Valeur| Description   | Référence | Recommandé  |
+===============+=======+===============+===========+=============+
| IV-GENERATION | 34    | Pour effectuer| RFC 9053  | Non         |
|               |       | la génération |           |             |
|               |       | d'IV pour les |           |             |
|               |       | algorithmes   |           |             |
|               |       | symétriques.  |           |             |
+---------------+-------+---------------+-----------+-------------+

        Tableau 23 : Nouvelle entrée dans le registre COSE Algorithms

La colonne Capabilities pour cet enregistrement doit être vide.

10.3. Modifications du registre "COSE Key Type Parameters"

L'IANA a modifié la description en "Public Key" (Clé publique) pour la ligne avec "Key Type" de 1 et le "Name" de "x". Voir le Tableau 20, qui a été modifié avec ce changement.

10.4. Instructions pour l'examen par des experts

Tous les registres IANA établis par [RFC8152] sont, au moins en partie, définis comme Examen par des experts [RFC8126]. Cette section donne quelques directives générales sur ce que les experts devraient rechercher, mais ils sont désignés comme experts pour une raison, ils devraient donc bénéficier d'une latitude substantielle.

Les examinateurs experts devraient prendre en considération ce qui suit :

• Le squat de points devrait être découragé. Les examinateurs sont encouragés à obtenir suffisamment d'informations pour les demandes d'enregistrement afin de s'assurer que l'utilisation ne va pas dupliquer un enregistrement existant et que le point de code est susceptible d'être utilisé dans des déploiements. Les plages étiquetées comme usage privé sont destinées à des fins de test et à des environnements fermés ; les points de code dans d'autres plages ne devraient pas être attribués pour les tests.

• Les RFC Standards Track ou BCP sont nécessaires pour enregistrer un point de code dans la plage Standards Action. Des spécifications devraient exister pour les plages Specification Required, mais une attribution anticipée avant qu'une RFC ne soit disponible est considérée comme admissible. Des spécifications sont nécessaires pour la plage premier arrivé, premier servi si les points sont censés être utilisés en dehors d'environnements fermés de manière interopérable. Lorsque les spécifications ne sont pas fournies, la description fournie doit contenir suffisamment d'informations pour identifier à quoi sert le point.

• Les experts devraient tenir compte de l'utilisation prévue des champs lors de l'approbation de l'attribution des points de code. Le fait que la plage Standards Action ne soit disponible que pour les documents Standards Track ne signifie pas qu'un document Standards Track ne peut pas avoir de points attribués en dehors de cette plage. La longueur de la valeur encodée doit être pesée par rapport au nombre de points de code de cette longueur restants et à la taille de l'appareil sur lequel il sera utilisé.

• Lorsque des algorithmes sont enregistrés, les enregistrements de vanité devraient être découragés. Une façon de faire cela est d'exiger que les enregistrements fournissent une documentation supplémentaire sur l'analyse de sécurité de l'algorithme. Une autre chose qui devrait être considérée est de demander un avis sur l'algorithme au Crypto Forum Research Group (CFRG). Les algorithmes sont censés répondre aux exigences de sécurité de la communauté et aux exigences des structures de message pour être adaptés à l'enregistrement.