Passa al contenuto principale

11. Considerazioni IANA

  1. Considerazioni IANA

I registri e le registrazioni elencati di seguito sono stati definiti dalla RFC 8152 [RFC8152]. La maggior parte delle azioni seguenti consiste nell'aggiornare i riferimenti in modo che puntino a questo documento.

Si noti che mentre la [RFC9053] aggiorna anche i registri e le registrazioni originariamente stabiliti dalla [RFC8152], gli aggiornamenti richiesti si escludono a vicenda. Gli aggiornamenti richiesti in questo documento non sono in conflitto né si sovrappongono agli aggiornamenti richiesti nella [RFC9053], e viceversa.

11.1. Registro dei parametri dell'intestazione COSE

Il registro "COSE Header Parameters" (Parametri dell'intestazione COSE) è stato definito dalla [RFC8152]. La IANA ha aggiornato il riferimento per questo registro in modo che punti a questo documento invece che alla [RFC8152]. La IANA ha anche aggiornato tutte le voci che facevano riferimento alla [RFC8152], eccetto "counter signature" e "CounterSignature0", per fare riferimento a questo documento. I riferimenti per "counter signature" e "CounterSignature0" continuano a fare riferimento alla [RFC8152].

11.2. Registro dei parametri comuni delle chiavi COSE

Il registro "COSE Key Common Parameters" (Parametri comuni delle chiavi COSE) [COSE.KeyParameters] è stato definito nella [RFC8152]. La IANA ha aggiornato il riferimento per questo registro in modo che punti a questo documento invece che alla [RFC8152]. La IANA ha anche aggiornato le voci che facevano riferimento alla [RFC8152] per fare riferimento a questo documento.

11.3. Registrazioni dei tipi di media

11.3.1. Messaggio di sicurezza COSE

La IANA ha registrato il tipo di media "application/cose" nel registro "Media Types" (Tipi di media). Questo tipo di media viene utilizzato per indicare che il contenuto è un messaggio COSE.

Type name: application

Subtype name: cose

Required parameters: N/A

Optional parameters: cose-type

Encoding considerations: binary

Security considerations: Vedere la sezione Considerazioni sulla sicurezza della RFC 9052.

Interoperability considerations: N/A

Published specification: RFC 9052

Applications that use this media type: Applicazioni IoT che inviano contenuti di sicurezza su trasporti 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. Tipo di media chiave COSE

La IANA ha registrato i tipi di media "application/cose-key" e "application/cose-key-set" nel registro "Media Types" (Tipi di media). Questi tipi di media vengono utilizzati per indicare, rispettivamente, che il contenuto è un oggetto COSE_Key o COSE_KeySet.

Il modello per "application/cose-key" è il seguente:

Type name: application

Subtype name: cose-key

Required parameters: N/A

Optional parameters: N/A

Encoding considerations: binary

Security considerations: Vedere la sezione Considerazioni sulla sicurezza della RFC 9052.

Interoperability considerations: N/A

Published specification: RFC 9052

Applications that use this media type: Distribuzione di chiavi basate su COSE per applicazioni 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

Il modello per la registrazione di "application/cose-key-set" è:

Type name: application

Subtype name: cose-key-set

Required parameters: N/A

Optional parameters: N/A

Encoding considerations: binary

Security considerations: Vedere la sezione Considerazioni sulla sicurezza della RFC 9052.

Interoperability considerations: N/A

Published specification: RFC 9052

Applications that use this media type: Distribuzione di chiavi basate su COSE per applicazioni 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. Registro dei formati di contenuto CoAP

La IANA ha aggiunto voci al registro "CoAP Content-Formats" (Formati di contenuto CoAP) come indicato nella [RFC8152]. La IANA ha aggiornato il riferimento per puntare a questo documento invece che alla [RFC8152].

11.5. Registro dei tag CBOR

La IANA ha aggiunto voci al registro "CBOR Tags" (Tag CBOR) come indicato nella [RFC8152]. La IANA ha aggiornato i riferimenti per puntare a questo documento invece che alla [RFC8152].

11.6. Istruzioni per la revisione degli esperti

Tutti i registri IANA stabiliti dalla [RFC8152] sono, almeno in parte, definiti come Revisione degli esperti (Expert Review) [RFC8126]. Questa sezione fornisce alcune linee guida generali su cosa gli esperti dovrebbero cercare, ma sono stati designati come esperti per un motivo, quindi dovrebbe essere data loro una sostanziale libertà.

I revisori esperti dovrebbero prendere in considerazione quanto segue:

  • Il "point squatting" (occupazione di punti) dovrebbe essere scoraggiato. I revisori sono incoraggiati a ottenere informazioni sufficienti per le richieste di registrazione per garantire che l'utilizzo non duplichi una registrazione esistente e che il punto di codice sarà probabilmente utilizzato nelle distribuzioni. Gli intervalli contrassegnati come uso privato sono destinati a scopi di test e ambienti chiusi; i punti di codice in altri intervalli non dovrebbero essere assegnati per i test.

  • Le RFC Standards Track o BCP sono necessarie per registrare un punto di codice nell'intervallo Standards Action (Azione standard). Le specifiche dovrebbero esistere per gli intervalli Specification Required (Specifica richiesta), ma l'assegnazione anticipata prima che una RFC sia disponibile è considerata ammissibile. Le specifiche sono necessarie per l'intervallo "primo arrivato, primo servito" (first-come, first-served) se si prevede che i punti vengano utilizzati al di fuori di ambienti chiusi in modo interoperabile. Quando le specifiche non vengono fornite, la descrizione fornita deve contenere informazioni sufficienti per identificare a cosa serve il punto.

  • Gli esperti dovrebbero tenere conto dell'uso previsto dei campi quando approvano l'assegnazione dei punti di codice. Il fatto che l'intervallo Standards Action sia disponibile solo per i documenti Standards Track non significa che un documento Standards Track non possa avere punti assegnati al di fuori di quell'intervallo. La lunghezza del valore codificato dovrebbe essere soppesata rispetto a quanti punti di codice di quella lunghezza sono rimasti e alla dimensione del dispositivo su cui verrà utilizzato.

  • Quando vengono registrati gli algoritmi, le registrazioni di vanità (vanity registrations) dovrebbero essere scoraggiate. Un modo per farlo è richiedere alle registrazioni di fornire documentazione aggiuntiva sull'analisi della sicurezza dell'algoritmo. Un'altra cosa che dovrebbe essere considerata è la richiesta di un parere sull'algoritmo al Crypto Forum Research Group (CFRG). Ci si aspetta che gli algoritmi soddisfino i requisiti di sicurezza della comunità e i requisiti delle strutture dei messaggi per essere idonei alla registrazione.

Ultimo aggiornamento il