Zum Hauptinhalt springen

11. IANA-Überlegungen

  1. IANA-Überlegungen

Die unten aufgeführten Register und Registrierungen wurden durch RFC 8152 [RFC8152] definiert. Die Mehrheit der folgenden Aktionen dient dazu, die Referenzen so zu aktualisieren, dass sie auf dieses Dokument verweisen.

Beachten Sie, dass [RFC9053] zwar auch die ursprünglich durch [RFC8152] eingerichteten Register und Registrierungen aktualisiert, die angeforderten Aktualisierungen sich jedoch gegenseitig ausschließen. Die in diesem Dokument angeforderten Aktualisierungen stehen nicht im Konflikt mit den in [RFC9053] angeforderten Aktualisierungen und überschneiden sich nicht mit diesen, und umgekehrt.

11.1. Register für COSE-Header-Parameter

Das Register "COSE Header Parameters" (COSE-Header-Parameter) wurde durch [RFC8152] definiert. Die IANA hat die Referenz für dieses Register aktualisiert, um auf dieses Dokument anstelle von [RFC8152] zu verweisen. Die IANA hat auch alle Einträge aktualisiert, die auf [RFC8152] verwiesen, mit Ausnahme von "counter signature" und "CounterSignature0", um auf dieses Dokument zu verweisen. Die Referenzen für "counter signature" und "CounterSignature0" verweisen weiterhin auf [RFC8152].

11.2. Register für gemeinsame COSE-Schlüsselparameter

Das Register "COSE Key Common Parameters" (Gemeinsame COSE-Schlüsselparameter) [COSE.KeyParameters] wurde in [RFC8152] definiert. Die IANA hat die Referenz für dieses Register aktualisiert, um auf dieses Dokument anstelle von [RFC8152] zu verweisen. Die IANA hat auch die Einträge aktualisiert, die auf [RFC8152] verwiesen, um auf dieses Dokument zu verweisen.

11.3. Medientyp-Registrierungen

11.3.1. COSE-Sicherheitsnachricht

Die IANA hat den Medientyp "application/cose" im Register "Media Types" (Medientypen) registriert. Dieser Medientyp wird verwendet, um anzuzeigen, dass der Inhalt eine COSE-Nachricht ist.

Type name: application

Subtype name: cose

Required parameters: N/A

Optional parameters: cose-type

Encoding considerations: binary

Security considerations: Siehe den Abschnitt Sicherheitsüberlegungen in RFC 9052.

Interoperability considerations: N/A

Published specification: RFC 9052

Applications that use this media type: IoT-Anwendungen, die Sicherheitsinhalte über HTTP(S)-Transporte senden.

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. COSE-Schlüssel-Medientyp

Die IANA hat die Medientypen "application/cose-key" und "application/cose-key-set" im Register "Media Types" (Medientypen) registriert. Diese Medientypen werden verwendet, um anzuzeigen, dass der Inhalt ein COSE_Key- bzw. COSE_KeySet-Objekt ist.

Die Vorlage für "application/cose-key" lautet wie folgt:

Type name: application

Subtype name: cose-key

Required parameters: N/A

Optional parameters: N/A

Encoding considerations: binary

Security considerations: Siehe den Abschnitt Sicherheitsüberlegungen in RFC 9052.

Interoperability considerations: N/A

Published specification: RFC 9052

Applications that use this media type: Verteilung von COSE-basierten Schlüsseln für IoT-Anwendungen.

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

Die Vorlage für die Registrierung von "application/cose-key-set" ist:

Type name: application

Subtype name: cose-key-set

Required parameters: N/A

Optional parameters: N/A

Encoding considerations: binary

Security considerations: Siehe den Abschnitt Sicherheitsüberlegungen in RFC 9052.

Interoperability considerations: N/A

Published specification: RFC 9052

Applications that use this media type: Verteilung von COSE-basierten Schlüsseln für IoT-Anwendungen.

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. CoAP-Inhaltsformat-Register

Die IANA hat Einträge zum Register "CoAP Content-Formats" (CoAP-Inhaltsformate) hinzugefügt, wie in [RFC8152] angegeben. Die IANA hat die Referenz aktualisiert, um auf dieses Dokument anstelle von [RFC8152] zu verweisen.

11.5. CBOR-Tag-Register

Die IANA hat Einträge zum Register "CBOR Tags" (CBOR-Tags) hinzugefügt, wie in [RFC8152] angegeben. Die IANA hat die Referenzen aktualisiert, um auf dieses Dokument anstelle von [RFC8152] zu verweisen.

11.6. Anweisungen zur Expertenbegutachtung

Alle durch [RFC8152] eingerichteten IANA-Register sind zumindest teilweise als Expertenbegutachtung (Expert Review) [RFC8126] definiert. Dieser Abschnitt enthält einige allgemeine Richtlinien, worauf die Experten achten sollten, aber sie werden aus einem bestimmten Grund als Experten benannt, daher sollte ihnen ein erheblicher Spielraum eingeräumt werden.

Expertenbegutachter sollten Folgendes berücksichtigen:

  • Point Squatting (Besetzung von Codepunkten) sollte entmutigt werden. Begutachter werden ermutigt, ausreichende Informationen für Registrierungsanfragen einzuholen, um sicherzustellen, dass die Nutzung eine bestehende Registrierung nicht dupliziert und dass der Codepunkt wahrscheinlich in Bereitstellungen verwendet wird. Die als privat gekennzeichneten Bereiche sind für Testzwecke und geschlossene Umgebungen vorgesehen; Codepunkte in anderen Bereichen sollten nicht für Tests zugewiesen werden.

  • Standards Track oder BCP RFCs sind erforderlich, um einen Codepunkt im Bereich Standards Action (Standardisierungsmaßnahme) zu registrieren. Spezifikationen sollten für Bereiche mit Specification Required (Spezifikation erforderlich) vorhanden sein, aber eine frühe Zuweisung, bevor ein RFC verfügbar ist, gilt als zulässig. Spezifikationen sind für den Bereich "Wer zuerst kommt, mahlt zuerst" (first-come, first-served) erforderlich, wenn erwartet wird, dass die Punkte außerhalb geschlossener Umgebungen auf interoperable Weise verwendet werden. Wenn keine Spezifikationen bereitgestellt werden, muss die bereitgestellte Beschreibung ausreichende Informationen enthalten, um zu identifizieren, wofür der Punkt verwendet wird.

  • Experten sollten bei der Genehmigung der Zuweisung von Codepunkten die erwartete Nutzung der Felder berücksichtigen. Die Tatsache, dass der Bereich Standards Action nur für Standards Track-Dokumente verfügbar ist, bedeutet nicht, dass einem Standards Track-Dokument keine Punkte außerhalb dieses Bereichs zugewiesen werden können. Die Länge des codierten Werts sollte dagegen abgewogen werden, wie viele Codepunkte dieser Länge noch übrig sind und wie groß das Gerät ist, auf dem er verwendet wird.

  • Wenn Algorithmen registriert werden, sollten Vanity-Registrierungen (Eitelkeitsregistrierungen) entmutigt werden. Eine Möglichkeit, dies zu tun, besteht darin, für Registrierungen zusätzliche Dokumentation zur Sicherheitsanalyse des Algorithmus zu verlangen. Eine weitere Sache, die in Betracht gezogen werden sollte, ist die Anforderung einer Stellungnahme zum Algorithmus von der Crypto Forum Research Group (CFRG). Von Algorithmen wird erwartet, dass sie die Sicherheitsanforderungen der Gemeinschaft und die Anforderungen der Nachrichtenstrukturen erfüllen, um für eine Registrierung geeignet zu sein.

Letztes Update am