1. Introduzione
C'è stata una crescente attenzione sui piccoli dispositivi vincolati che compongono l'Internet delle cose (IoT). Uno degli standard emersi da questo processo è la "Concise Binary Object Representation (CBOR)" [RFC8949]. CBOR ha esteso il modello dati della 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 per codificare le strutture dati. CBOR è stato progettato specificamente per essere piccolo in termini sia di messaggi trasportati che di dimensioni dell'implementazione e per avere un decoder senza schema. Esiste la necessità di fornire servizi di sicurezza dei messaggi per l'IoT e l'uso di CBOR come formato di codifica dei messaggi è sensato.
Una controfirma è una seconda firma che conferma la firma primaria. Durante il processo di avanzamento della Firma e Crittografia di Oggetti CBOR (COSE) a Standard Internet, è stato notato che la descrizione delle proprietà di sicurezza delle controfirme non era corretta per la struttura COSE_Sign1 menzionata nella Sezione 4.5 della [RFC8152]. Per rimediare a questa situazione, il gruppo di lavoro COSE ha deciso di rimuovere tutto il testo della controfirma dalla [RFC9052], che rende obsoleta la [RFC8152]. Questo documento definisce una nuova controfirma con le proprietà di sicurezza desiderate.
Il problema con il precedente algoritmo di controfirma era che il valore calcolato crittograficamente non era sempre incluso. L'ipotesi iniziale che il valore crittografico fosse nel terzo slot dell'array era nota per non essere vera all'epoca, ma nel caso delle strutture Message Authentication Code (MAC) questo non è stato ritenuto un problema. Il nuovo algoritmo definito in questo documento richiede l'inclusione di più valori per il calcolo della controfirma. L'eccezione a questo è la struttura COSE_Signature in cui non esiste alcun valore calcolato crittograficamente.
Il nuovo algoritmo definito in questo documento è progettato per produrre lo stesso valore di controfirma nei casi in cui il valore crittografico calcolato era già incluso. Ciò significa che per quelle strutture l'unica cosa che dovrebbe essere fatta è cambiare il valore del parametro di intestazione.
Con la pubblicazione di questo documento, gli implementatori sono incoraggiati a migrare gli usi del precedente algoritmo di controfirma a quello specificato in questo documento. In particolare, gli usi di "CounterSignature" migreranno a "CounterSignatureV2" e gli usi di "CounterSignature0" migreranno a "CounterSignature0V2". Inoltre, la verifica di "CounterSignature" deve essere supportata dalle nuove implementazioni per rimanere compatibili con i mittenti che aderiscono alla [RFC8152], che presuppone che tutte le implementazioni comprendano "CounterSignature" come etichetta del parametro di intestazione 7. Allo stesso modo, la verifica di "CounterSignature0" può essere supportata per ulteriore compatibilità.
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 nel BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono in lettere tutte maiuscole, come mostrato qui.
1.2. Grammatica CBOR
La grammatica CBOR in questo documento utilizza il Concise Data Definition Language (CDDL) [RFC8610].
Il CDDL raccolto può essere estratto dalla versione XML di questo documento tramite l'espressione XPath riportata di seguito. (A seconda del valutatore XPath utilizzato, potrebbe essere necessario trattare > come un'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_Countersignature_Tagged / Internal_Types
; This is defined to make the tool quieter:
Internal_Types = Countersign_structure / COSE_Countersignature0
Il non terminale Internal_Types è definito per gestire gli strumenti di convalida automatizzata utilizzati durante la scrittura 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.3. Terminologia del documento
In questo documento, utilizziamo la seguente terminologia.
"Byte" è un sinonimo di "ottetto".
Il Constrained Application Protocol (CoAP) è un protocollo di trasferimento web specializzato per l'uso in sistemi vincolati. È definito nella [RFC7252].
"Context" (contesto) viene utilizzato in tutto questo 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 di chiavi associate e configurazione dell'applicazione. Il contesto da utilizzare può essere implicito, identificato utilizzando il parametro di intestazione "kid context" definito nella [RFC8613] o un identificatore specifico del protocollo. Il contesto dovrebbe generalmente essere incluso nella costruzione crittografica; per maggiori dettagli, vedere la Sezione 4.4 della [RFC9052].
Il termine "byte string" (stringa di byte) viene utilizzato per sequenze di byte, mentre il termine "text string" (stringa di testo) viene utilizzato per sequenze di caratteri.