1. Einführung
Es gibt einen verstärkten Fokus auf kleine, eingeschränkte Geräte, die das Internet der Dinge (IoT) bilden. Einer der Standards, der aus diesem Prozess hervorgegangen ist, ist "Concise Binary Object Representation (CBOR)" [RFC8949]. CBOR erweiterte das Datenmodell der JavaScript Object Notation (JSON) [STD90], indem es unter anderem binäre Daten zuließ. CBOR wurde von mehreren IETF-Arbeitsgruppen, die sich mit der IoT-Welt befassen, als ihre Methode zur Kodierung von Datenstrukturen übernommen. CBOR wurde speziell entwickelt, um sowohl hinsichtlich der transportierten Nachrichten als auch der Implementierungsgröße klein zu sein und einen schemafreien Decoder zu haben. Es besteht ein Bedarf an Nachrichtensicherheitsdiensten für das IoT, und die Verwendung von CBOR als Nachrichtenkodierungsformat ist sinnvoll.
Eine Gegensignatur ist eine zweite Signatur, die die primäre Signatur bestätigt. Während des Prozesses zur Weiterentwicklung von CBOR Object Signing and Encryption (COSE) zum Internetstandard wurde festgestellt, dass die Beschreibung der Sicherheitseigenschaften von Gegensignaturen für die in Abschnitt 4.5 von [RFC8152] erwähnte Struktur COSE_Sign1 falsch war. Um diese Situation zu beheben, beschloss die COSE-Arbeitsgruppe, den gesamten Text zu Gegensignaturen aus [RFC9052] zu entfernen, das [RFC8152] ersetzt. Dieses Dokument definiert eine neue Gegensignatur mit den gewünschten Sicherheitseigenschaften.
Das Problem mit dem vorherigen Gegensignatur-Algorithmus bestand darin, dass der kryptographisch berechnete Wert nicht immer enthalten war. Die anfängliche Annahme, dass sich der kryptographische Wert im dritten Slot des Arrays befand, war zu diesem Zeitpunkt bekanntermaßen nicht wahr, aber im Fall der Message Authentication Code (MAC)-Strukturen wurde dies nicht als Problem angesehen. Der neue in diesem Dokument definierte Algorithmus erfordert die Einbeziehung von mehr Werten für die Gegensignaturberechnung. Die Ausnahme ist die COSE_Signature-Struktur, bei der es keinen kryptographisch berechneten Wert gibt.
Der neue in diesem Dokument definierte Algorithmus ist so konzipiert, dass er in den Fällen, in denen der berechnete kryptographische Wert bereits enthalten war, denselben Gegensignaturwert erzeugt. Dies bedeutet, dass für diese Strukturen lediglich der Wert des Header-Parameters geändert werden müsste.
Mit der Veröffentlichung dieses Dokuments werden Implementierer ermutigt, die Verwendung des vorherigen Gegensignatur-Algorithmus auf den in diesem Dokument spezifizierten zu migrieren. Insbesondere wird die Verwendung von "CounterSignature" zu "CounterSignatureV2" und die Verwendung von "CounterSignature0" zu "CounterSignature0V2" migriert. Darüber hinaus muss die Verifizierung von "CounterSignature" von neuen Implementierungen unterstützt werden, um mit Absendern kompatibel zu bleiben, die sich an [RFC8152] halten, das davon ausgeht, dass alle Implementierungen "CounterSignature" als Header-Parameter-Label 7 verstehen. Ebenso kann die Verifizierung von "CounterSignature0" für weitere Kompatibilität unterstützt werden.
1.1. Anforderungsterminologie
Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind so auszulegen, wie in BCP 14 [RFC2119] [RFC8174] beschrieben, wenn, und nur wenn, sie in Großbuchstaben erscheinen, wie hier gezeigt.
1.2. CBOR-Grammatik
Die CBOR-Grammatik in diesem Dokument verwendet die Concise Data Definition Language (CDDL) [RFC8610].
Die gesammelte CDDL kann über den unten stehenden XPath-Ausdruck aus der XML-Version dieses Dokuments extrahiert werden. (Abhängig vom verwendeten XPath-Auswerter kann es erforderlich sein, > als Entität zu behandeln.)
//sourcecode[@type='cddl']/text()
CDDL erwartet, dass das anfängliche Nicht-Terminal-Symbol das erste Symbol in der Datei ist. Aus diesem Grund wird hier das erste Fragment von CDDL vorgestellt.
start = COSE_Countersignature_Tagged / Internal_Types
; This is defined to make the tool quieter:
Internal_Types = Countersign_structure / COSE_Countersignature0
Das Nicht-Terminal Internal_Types ist für den Umgang mit den automatisierten Validierungstools definiert, die während des Schreibens dieses Dokuments verwendet wurden. Es verweist auf jene Nicht-Terminale, die für Sicherheitsberechnungen verwendet werden, aber nicht für den Transport ausgegeben werden.
1.3. Dokumentterminologie
In diesem Dokument verwenden wir die folgende Terminologie.
"Byte" ist ein Synonym für "Oktett".
Das Constrained Application Protocol (CoAP) ist ein spezialisiertes Web-Transfer-Protokoll zur Verwendung in eingeschränkten Systemen. Es ist in [RFC7252] definiert.
"Kontext" wird in diesem Dokument verwendet, um Informationen darzustellen, die nicht Teil der COSE-Nachricht sind. Informationen, die Teil des Kontexts sind, können aus verschiedenen Quellen stammen, einschließlich Protokollinteraktionen, zugehörigen Schlüsselstrukturen und Anwendungskonfigurationen. Der zu verwendende Kontext kann implizit sein, identifiziert entweder über den in [RFC8613] definierten Header-Parameter "kid context" oder einen protokollspezifischen Identifikator. Der Kontext sollte im Allgemeinen in die kryptographische Konstruktion einbezogen werden; weitere Einzelheiten finden Sie in Abschnitt 4.4 von [RFC9052].
Der Begriff "Byte-String" wird für Folgen von Bytes verwendet, während der Begriff "Text-String" für Folgen von Zeichen verwendet wird.