RFC 9052

Internet Engineering Task Force (IETF) J. Schaad Request for Comments: 9052 August Cellars STD: 96 Agosto 2022 Obsoletes: 8152 Category: Standards Track ISSN: 2070-1721

Firma e Crittografia di Oggetti CBOR (COSE): Strutture e Processo

Sommario

Concise Binary Object Representation (CBOR) è un formato dati progettato per dimensioni di codice ridotte e dimensioni di messaggio ridotte. C'è bisogno di poter definire servizi di sicurezza di base per questo formato dati. Questo documento definisce il protocollo CBOR Object Signing and Encryption (COSE). Questa specifica descrive come creare ed elaborare firme, codici di autenticazione dei messaggi e crittografia utilizzando CBOR per la serializzazione. Questa specifica descrive inoltre come rappresentare le chiavi crittografiche utilizzando CBOR.

Questo documento, insieme alla RFC 9053, rende obsoleta la RFC 8152.

Stato di questo Memo

Questo è un documento Internet Standards Track.

Questo documento è un prodotto della Internet Engineering Task Force (IETF). Rappresenta il consenso della comunità IETF. Ha ricevuto revisione pubblica ed è stato approvato per la pubblicazione dall'Internet Engineering Steering Group (IESG). Ulteriori informazioni sugli Standard Internet sono disponibili nella Sezione 2 della RFC 7841.

Informazioni sullo stato attuale di questo documento, eventuali errata e come fornire feedback su di esso possono essere ottenute su https://www.rfc-editor.org/info/rfc9052.

Avviso di Copyright

Questo documento è soggetto al BCP 78 e alle Disposizioni Legali dell'IETF Trust relative ai Documenti IETF (https://trustee.ietf.org/license-info) in vigore alla data di pubblicazione di questo documento. Si prega di esaminare attentamente questi documenti, in quanto descrivono i vostri diritti e restrizioni rispetto a questo documento. I Componenti di Codice estratti da questo documento devono includere il testo della Licenza BSD Revisionata come descritto nella Sezione 4.e delle Disposizioni Legali del Trust e sono forniti senza garanzia come descritto nella Licenza BSD Revisionata.

Indice

Introduzione 1.1. Terminologia dei Requisiti 1.2. Modifiche rispetto alla RFC 8152 1.3. Modifiche di Progettazione rispetto a JOSE 1.4. Grammatica CDDL per Strutture Dati CBOR 1.5. Terminologia relativa a CBOR 1.6. Terminologia del Documento
Struttura COSE di Base
Parametri dell'Intestazione 3.1. Parametri dell'Intestazione COSE Comuni
Oggetti di Firma 4.1. Firma con Uno o Più Firmatari 4.2. Firma con Un Solo Firmatario 4.3. Dati Forniti Esternamente 4.4. Processo di Firma e Verifica
Oggetti di Crittografia 5.1. Struttura COSE Avvolta 5.1.1. Metodi di Distribuzione della Chiave di Contenuto 5.2. Crittografia a Destinatario Singolo 5.3. Come Cifrare e Decifrare per Algoritmi AEAD 5.4. Come Cifrare e Decifrare per Algoritmi AE
Oggetti MAC 6.1. Messaggio MACato con Destinatari 6.2. Messaggi MACati con Chiave Implicita 6.3. Come Calcolare e Verificare un MAC
Oggetti Chiave 7.1. Parametri Comuni della Chiave COSE
Tassonomia degli Algoritmi Usati da COSE 8.1. Algoritmi di Firma 8.2. Algoritmi di Codice di Autenticazione del Messaggio (MAC) 8.3. Algoritmi di Crittografia del Contenuto 8.4. Funzioni di Derivazione della Chiave (KDF) 8.5. Metodi di Distribuzione della Chiave di Contenuto 8.5.1. Crittografia Diretta 8.5.2. Key Wrap 8.5.3. Trasporto della Chiave 8.5.4. Accordo Chiave Diretto 8.5.5. Accordo Chiave con Key Wrap
Restrizioni di Codifica CBOR
Considerazioni sulla Profilazione dell'Applicazione
Considerazioni IANA 11.1. Registro Parametri Intestazione COSE 11.2. Registro Parametri Comuni Chiave COSE 11.3. Registrazioni Tipo Media 11.3.1. Messaggio di Sicurezza COSE 11.3.2. Tipo Media Chiave COSE 11.4. Registro Formati Contenuto CoAP 11.5. Registro Tag CBOR 11.6. Istruzioni per la Revisione di Esperti
Considerazioni sulla Sicurezza
Riferimenti 13.1. Riferimenti Normativi 13.2. Riferimenti Informativi Appendice A. Linee Guida per l'Autenticazione Dati Esterna degli Algoritmi Appendice B. Due Livelli di Informazioni sul Destinatario Appendice C. Esempi C.1. Esempi di Messaggi Firmati C.1.1. Firma Singola C.1.2. Firmatari Multipli C.1.3. Firma con Criticità C.2. Esempi di Firmatario Singolo C.2.1. Firma ECDSA Singola C.3. Esempi di Messaggi Avvolti C.3.1. ECDH Diretto C.3.2. Diretto Più Derivazione della Chiave C.3.3. Contenuto Cifrato con Dati Esterni C.4. Esempi di Messaggi Cifrati C.4.1. Messaggio Cifrato Semplice C.4.2. Messaggio Cifrato con un IV Parziale C.5. Esempi di Messaggi MACati C.5.1. MAC Diretto a Segreto Condiviso C.5.2. MAC Diretto ECDH C.5.3. MAC Avvolto C.5.4. Messaggio MACato a Più Destinatari C.6. Esempi di Messaggi MAC0 C.6.1. MAC Diretto a Segreto Condiviso C.7. Chiavi COSE C.7.1. Chiavi Pubbliche C.7.2. Chiavi Private Riconoscimenti Indirizzo dell'Autore
Introduzione

C'è stata una crescente attenzione sui piccoli dispositivi vincolati che compongono l'Internet delle cose (IoT). Uno degli standard emersi da questo processo è "Concise Binary Object Representation (CBOR)" [STD94]. CBOR ha esteso il modello di dati di JavaScript Object Notation (JSON) [STD90] consentendo dati binari, tra le altre modifiche. CBOR è stato adottato da diversi gruppi di lavoro IETF che si occupano del mondo IoT come metodo di codifica delle strutture dati. CBOR è stato progettato specificamente per essere piccolo sia in termini di messaggi trasportati che di dimensioni di implementazione e per avere un decoder senza schema. Esiste la necessità di fornire servizi di sicurezza dei messaggi per l'IoT e l'utilizzo di CBOR come formato di codifica dei messaggi ha senso.

Il gruppo di lavoro JOSE ha prodotto una serie di documenti [RFC7515] [RFC7516] [RFC7517] [RFC7518] che specificavano come elaborare operazioni di crittografia, firme e Codice di Autenticazione del Messaggio (MAC) e come codificare le chiavi utilizzando JSON. Questo documento definisce lo standard CBOR Object Signing and Encryption (COSE), che fa la stessa cosa per il formato di codifica CBOR. Questo documento è combinato con [RFC9053], che fornisce un set iniziale di algoritmi. Sebbene vi sia un forte tentativo di mantenere il sapore dei documenti JSON Object Signing and Encryption (JOSE) originali, vengono prese in considerazione due considerazioni:

CBOR ha capacità che non sono presenti in JSON e che sono appropriate da utilizzare. Un esempio di ciò è il fatto che CBOR ha un metodo per codificare direttamente i dati binari senza prima convertirli in una stringa di testo codificata in base64.
COSE non è una copia diretta della specifica JOSE. Nel processo di creazione di COSE, le decisioni prese per JOSE sono state riesaminate. In molti casi, sono stati decisi risultati diversi, poiché i criteri non erano sempre gli stessi.

Questo documento contiene:

La descrizione della struttura per gli oggetti CBOR che vengono trasmessi sulla rete. Sono definiti due oggetti ciascuno per la crittografia, la firma e l'autenticazione dei messaggi. Un oggetto è definito per il trasporto di chiavi e uno per il trasporto di gruppi di chiavi.
Le procedure utilizzate per costruire gli input per le funzioni crittografiche richieste per ciascuna delle strutture.
Un insieme di attributi che si applicano ai diversi oggetti di sicurezza.

Questo documento non contiene le regole e le procedure per l'utilizzo di specifici algoritmi crittografici. Dettagli su specifici algoritmi possono essere trovati in [RFC9053] e [RFC8230]. Dettagli per ulteriori algoritmi dovrebbero essere definiti in documenti futuri.

COSE è stato inizialmente progettato come parte di una soluzione per fornire sicurezza agli ambienti RESTful vincolati (CoRE), e questo viene fatto utilizzando [RFC8613] e [CORE-GROUPCOMM]. Tuttavia, COSE non è limitato solo a questi casi e può essere utilizzato in qualsiasi luogo in cui si considererebbe JOSE o Cryptographic Message Syntax (CMS) [RFC5652] allo scopo di fornire servizi di sicurezza. COSE, come JOSE e CMS, è solo per l'uso in protocolli store-and-forward o offline. L'uso di COSE in protocolli online che necessitano di crittografia richiede che venga eseguito un processo di definizione delle chiavi online prima di inviare oggetti avanti e indietro. Qualsiasi applicazione che utilizza COSE per i servizi di sicurezza deve prima determinare quali servizi di sicurezza sono richiesti e quindi selezionare le strutture COSE e gli algoritmi crittografici appropriati in base a tali esigenze. La Sezione 10 fornisce ulteriori informazioni su ciò che le applicazioni devono specificare quando utilizzano COSE.

Una caratteristica presente in CMS che non è presente in questo standard è una struttura di digest. Questa omissione è deliberata. È meglio che la struttura sia definita in ogni protocollo poiché protocolli diversi vorranno includere un diverso insieme di campi come parte della struttura. Mentre un identificatore di algoritmo e il valore del digest saranno comuni a tutte le applicazioni, i due valori potrebbero non essere sempre adiacenti, poiché l'algoritmo potrebbe essere definito una volta con più valori. Le applicazioni potrebbero inoltre voler definire campi dati aggiuntivi come parte della struttura. Uno di questi elementi specifici dell'applicazione sarebbe includere un URI o un altro puntatore a dove possono essere ottenuti i dati che vengono sottoposti ad hashing. [RFC9054] contiene una di queste possibili strutture e definisce un insieme di algoritmi di digest.

Durante il processo di avanzamento di COSE a Standard Internet, è stato notato che la descrizione delle proprietà di sicurezza delle controfirme non era corretta per la struttura COSE_Sign1. Poiché le proprietà di sicurezza descritte -- quelle di una vera controfirma -- erano quelle desiderate dal gruppo di lavoro, è stata presa la decisione di rimuovere tutto il testo della controfirma da questo documento e creare un nuovo documento [COSE-COUNTERSIGN] per deprecare sia il vecchio algoritmo di controfirma che i parametri dell'intestazione e definire un nuovo algoritmo e parametri dell'intestazione con le proprietà di sicurezza desiderate.

1.1. Terminologia dei Requisiti

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", e "OPTIONAL" in questo documento devono essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono in maiuscolo, come mostrato qui.

1.2. Modifiche rispetto alla RFC 8152

Diviso il documento originale in questo documento e [RFC9053].
Aggiunto del testo che descrive perché non esiste una struttura di digest definita da COSE.
Apportati chiarimenti al testo e modifiche alla terminologia.
Rimossi tutti i dettagli relativi alle controfirme e inseriti in [COSE-COUNTERSIGN].

1.3. Modifiche di Progettazione rispetto a JOSE

È stata definita un'unica struttura complessiva del messaggio in modo che i messaggi cifrati, firmati e MACati possano essere facilmente identificati e avere comunque una visione coerente.
I messaggi firmati distinguono tra i parametri dell'intestazione protetti e non protetti che si riferiscono al contenuto e quelli che si riferiscono alla firma.
I messaggi MACati sono separati dai messaggi firmati.
I messaggi MACati hanno la capacità di utilizzare lo stesso set di algoritmi del destinatario dei messaggi avvolti per ottenere la chiave di autenticazione MAC.
Le codifiche binarie vengono utilizzate, anziché le codifiche base64url, per codificare i dati binari.
Il tag di autenticazione per gli algoritmi di crittografia è stato combinato con il testo cifrato.
L'insieme degli algoritmi crittografici è stato ampliato in alcune direzioni e ridotto in altre.

1.4. Grammatica CDDL per Strutture Dati CBOR

Quando COSE è stato originariamente scritto, il Concise Data Definition Language (CDDL) [RFC8610] non era ancora stato pubblicato in una RFC, quindi non poteva essere utilizzato come linguaggio di descrizione dei dati per descrivere normativamente le strutture dati CBOR impiegate da COSE. Per questo motivo, gli oggetti dati CBOR definiti qui sono descritti in prosa. Ulteriori descrizioni (non normative) degli oggetti dati COSE sono fornite in un sottoinsieme di CDDL, descritto di seguito.

Questo documento è stato sviluppato lavorando prima sulla grammatica e poi sviluppando la prosa per accompagnarla. Un artefatto di ciò è che la prosa è stata scritta utilizzando le stringhe di tipo primitivo definite dal Concise Data Definition Language (CDDL) [RFC8610]. In questa specifica, vengono utilizzati i seguenti tipi primitivi:

any: Un valore non specifico che consente di inserire qui tutti i valori CBOR.

bool: Un valore booleano (tipo maggiore 7, valore 21; false: tipo maggiore 7, valore 20).

bstr: Stringa di byte (tipo maggiore 2).

int: Un intero senza segno o un intero negativo.

nil: Un valore nullo (tipo maggiore 7, valore 22).

nint: Un intero negativo (tipo maggiore 1).

tstr: Una stringa di testo UTF-8 (tipo maggiore 3).

uint: Un intero senza segno (tipo maggiore 0).

Tre sintassi di CDDL appaiono in questo documento come abbreviazione. Queste sono:

FOO / BAR: Indica che qui può apparire FOO o BAR.

[+ FOO]: Indica che il tipo FOO appare una o più volte in un array.

FOO: Indica che il tipo FOO appare zero o più volte.

Due dei vincoli definiti da CDDL sono utilizzati anche in questo documento. Questi sono:

type1 .cbor type2: Indica che il contenuto di type1, solitamente bstr, contiene un valore di type2.

type1 .size integer: Indica che il contenuto di type1 è lungo integer byte.

Oltre alla descrizione in prosa, una grammatica per le strutture dati CBOR è presentata nel sottoinsieme di CDDL descritto in precedenza. La grammatica CDDL è informativa; la descrizione in prosa è normativa.

Il CDDL raccolto può essere estratto dalla versione XML di questo documento tramite l'espressione XPath di seguito. (A seconda del valutatore XPath che si sta utilizzando, potrebbe essere necessario gestire > come entità.)

//sourcecode[@type='cddl']/text()

CDDL si aspetta che il simbolo non terminale iniziale sia il primo simbolo nel file. Per questo motivo, il primo frammento di CDDL è presentato qui.

start = COSE_Messages / COSE_Key / COSE_KeySet / Internal_Types

; Questo è definito per rendere lo strumento più silenzioso: Internal_Types = Sig_structure / Enc_structure / MAC_structure

Il non terminale Internal_Types è definito per gestire gli strumenti di convalida automatizzata utilizzati durante la stesura di questo documento. Fa riferimento a quei non terminali che vengono utilizzati per i calcoli di sicurezza ma non vengono emessi per il trasporto.

1.5. Terminologia relativa a CBOR

In JSON, le mappe sono chiamate oggetti e hanno un solo tipo di chiave di mappa: una stringa di testo. In COSE, utilizziamo stringhe di testo, interi negativi e interi senza segno come chiavi di mappa. Gli interi vengono utilizzati per la compattezza della codifica e la facilità di confronto. L'inclusione di stringhe di testo consente anche di utilizzare un intervallo aggiuntivo di valori codificati brevi. Poiché la parola "key" (chiave) viene utilizzata principalmente nel suo altro significato, come chiave crittografica, utilizziamo il termine "label" (etichetta) per questo utilizzo come chiave di mappa.

In una mappa CBOR definita da questa specifica, la presenza di un'etichetta che non è né una stringa di testo né un intero è un errore. Le applicazioni possono fallire l'elaborazione o elaborare i messaggi ignorando le etichette errate; tuttavia, NON DEVONO (MUST NOT) creare messaggi con etichette errate.

Un frammento di grammatica CDDL definisce il non terminale "label", come nel paragrafo precedente, e "values", che consente di utilizzare qualsiasi valore.

label = int / tstr values = any

1.6. Terminologia del Documento

In questo documento, utilizziamo la seguente terminologia:

Byte: Un sinonimo di ottetto.

Constrained Application Protocol (CoAP): Un protocollo di trasferimento web specializzato per l'uso in sistemi vincolati. È definito in [RFC7252].

Authenticated Encryption (AE) algorithms [RFC5116]: Algoritmi di crittografia che forniscono un controllo di autenticazione dei contenuti insieme al servizio di crittografia. Un esempio di algoritmo AE utilizzato in COSE è AES Key Wrap [RFC3394]. Questi algoritmi sono utilizzati per la crittografia delle chiavi, ma gli algoritmi Authenticated Encryption with Associated Data (AEAD) sarebbero preferiti.

AEAD algorithms [RFC5116]: Algoritmi di crittografia che forniscono lo stesso servizio di autenticazione del contenuto degli algoritmi AE e consentono anche di includere dati associati che non fanno parte del corpo cifrato nel servizio di autenticazione. Un esempio di algoritmo AEAD utilizzato in COSE è AES-GCM [RFC5116]. Questi algoritmi sono utilizzati per la crittografia del contenuto e possono essere utilizzati anche per la crittografia delle chiavi.

"Context" (Contesto) è utilizzato in tutto il documento per rappresentare informazioni che non fanno parte del messaggio COSE. Le informazioni che fanno parte del contesto possono provenire da diverse fonti, tra cui interazioni di protocollo, strutture chiave associate e configurazione del programma. Il contesto da utilizzare può essere implicito, identificato utilizzando il parametro dell'intestazione "kid context" definito in [RFC8613], o identificato da un identificatore specifico del protocollo. Il contesto dovrebbe generalmente essere incluso nella costruzione crittografica; per maggiori dettagli, vedere la Sezione 4.3.

Il termine "byte string" (stringa di byte) è utilizzato per sequenze di byte, mentre il termine "text string" (stringa di testo) è utilizzato per sequenze di caratteri.