Aller au contenu principal

11. Considérations relatives à l'IANA

  1. Considérations relatives à l'IANA

Les registres et enregistrements énumérés ci-dessous ont été définis par le RFC 8152 [RFC8152]. La majorité des actions suivantes visent à mettre à jour les références pour qu'elles pointent vers le présent document.

Notez que bien que le [RFC9053] mette également à jour les registres et enregistrements initialement établis par le [RFC8152], les mises à jour demandées sont mutuellement exclusives. Les mises à jour demandées dans le présent document n'entrent pas en conflit et ne se chevauchent pas avec les mises à jour demandées dans le [RFC9053], et vice versa.

11.1. Registre des paramètres d'en-tête COSE

Le registre "COSE Header Parameters" (Paramètres d'en-tête COSE) a été défini par le [RFC8152]. L'IANA a mis à jour la référence de ce registre pour qu'elle pointe vers le présent document au lieu du [RFC8152]. L'IANA a également mis à jour toutes les entrées qui référençaient le [RFC8152], à l'exception de "counter signature" et "CounterSignature0", pour faire référence au présent document. Les références pour "counter signature" et "CounterSignature0" continuent de faire référence au [RFC8152].

11.2. Registre des paramètres communs de clé COSE

Le registre "COSE Key Common Parameters" (Paramètres communs de clé COSE) [COSE.KeyParameters] a été défini dans le [RFC8152]. L'IANA a mis à jour la référence de ce registre pour qu'elle pointe vers le présent document au lieu du [RFC8152]. L'IANA a également mis à jour les entrées qui référençaient le [RFC8152] pour faire référence au présent document.

11.3. Enregistrements de types de médias

11.3.1. Message de sécurité COSE

L'IANA a enregistré le type de média "application/cose" dans le registre "Media Types" (Types de médias). Ce type de média est utilisé pour indiquer que le contenu est un message COSE.

Type name: application

Subtype name: cose

Required parameters: N/A

Optional parameters: cose-type

Encoding considerations: binary

Security considerations: Voir la section Considérations de sécurité du RFC 9052.

Interoperability considerations: N/A

Published specification: RFC 9052

Applications that use this media type: Applications IoT envoyant du contenu de sécurité via des transports HTTP(S).

Fragment identifier considerations: N/A

Additional information: * Deprecated alias names for this type: N/A

  *  Magic number(s): N/A

  *  File extension(s): cbor

  *  Macintosh file type code(s): N/A

Person & email address to contact for further information: [email protected]

Intended usage: COMMON

Restrictions on usage: N/A

Author: Jim Schaad

Change Controller: IESG

Provisional registration? No

11.3.2. Type de média de clé COSE

L'IANA a enregistré les types de médias "application/cose-key" et "application/cose-key-set" dans le registre "Media Types" (Types de médias). Ces types de médias sont utilisés pour indiquer, respectivement, que le contenu est un objet COSE_Key ou COSE_KeySet.

Le modèle pour "application/cose-key" est le suivant :

Type name: application

Subtype name: cose-key

Required parameters: N/A

Optional parameters: N/A

Encoding considerations: binary

Security considerations: Voir la section Considérations de sécurité du RFC 9052.

Interoperability considerations: N/A

Published specification: RFC 9052

Applications that use this media type: Distribution de clés basées sur COSE pour les applications IoT.

Fragment identifier considerations: N/A

Additional information: * Deprecated alias names for this type: N/A

  *  Magic number(s): N/A

  *  File extension(s): cbor

  *  Macintosh file type code(s): N/A

Person & email address to contact for further information: [email protected]

Intended usage: COMMON

Restrictions on usage: N/A

Author: Jim Schaad

Change Controller: IESG

Provisional registration? No

Le modèle pour l'enregistrement de "application/cose-key-set" est :

Type name: application

Subtype name: cose-key-set

Required parameters: N/A

Optional parameters: N/A

Encoding considerations: binary

Security considerations: Voir la section Considérations de sécurité du RFC 9052.

Interoperability considerations: N/A

Published specification: RFC 9052

Applications that use this media type: Distribution de clés basées sur COSE pour les applications IoT.

Fragment identifier considerations: N/A

Additional information: * Deprecated alias names for this type: N/A

  *  Magic number(s): N/A

  *  File extension(s): cbor

  *  Macintosh file type code(s): N/A

Person & email address to contact for further information: iesg@ietf .org

Intended usage: COMMON

Restrictions on usage: N/A

Author: Jim Schaad

Change Controller: IESG

Provisional registration? No

11.4. Registre des formats de contenu CoAP

L'IANA a ajouté des entrées au registre "CoAP Content-Formats" (Formats de contenu CoAP) comme indiqué dans le [RFC8152]. L'IANA a mis à jour la référence pour qu'elle pointe vers le présent document au lieu du [RFC8152].

11.5. Registre des balises CBOR

L'IANA a ajouté des entrées au registre "CBOR Tags" (Balises CBOR) comme indiqué dans le [RFC8152]. L'IANA a mis à jour les références pour qu'elles pointent vers le présent document au lieu du [RFC8152].

11.6. Instructions d'examen par des experts

Tous les registres IANA établis par le [RFC8152] sont, au moins en partie, définis comme Examen d'expert (Expert Review) [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 disposer d'une latitude substantielle.

Les experts examinateurs doivent prendre en compte les éléments suivants :

  • L'occupation de points (Point squatting) doit être découragée. Les examinateurs sont encouragés à obtenir suffisamment d'informations pour les demandes d'enregistrement afin de s'assurer que l'utilisation ne dupliquera pas un enregistrement existant et que le point de code est susceptible d'être utilisé dans des déploiements. Les plages marquées comme usage privé sont destinées à des fins de test et aux environnements fermés ; les points de code dans d'autres plages ne doivent pas être attribués pour des tests.

  • Les RFC Standards Track ou BCP sont nécessaires pour enregistrer un point de code dans la plage Standards Action (Action de normalisation). Des spécifications doivent exister pour les plages Specification Required (Spécification requise), mais une attribution anticipée avant qu'un RFC ne soit disponible est considérée comme admissible. Des spécifications sont nécessaires pour la plage premier arrivé, premier servi (first-come, first-served) 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 doivent 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 codée doit être pondérée par rapport au nombre de points de code de cette longueur restants et à la taille du dispositif sur lequel elle sera utilisée.

  • Lorsque des algorithmes sont enregistrés, les enregistrements de vanité (vanity registrations) doivent être découragés. Une façon de faire est d'exiger que les enregistrements fournissent une documentation supplémentaire sur l'analyse de sécurité de l'algorithme. Une autre chose à considérer 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 pouvoir être enregistrés.

Dernière mise à jour le