RFC 9052

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

CBOR Object Signing and Encryption (COSE): Strukturen und Prozess

Zusammenfassung

Concise Binary Object Representation (CBOR) ist ein Datenformat, das für eine geringe Codegröße und eine geringe Nachrichtengröße ausgelegt ist. Es besteht die Notwendigkeit, grundlegende Sicherheitsdienste für dieses Datenformat definieren zu können. Dieses Dokument definiert das Protokoll CBOR Object Signing and Encryption (COSE). Diese Spezifikation beschreibt, wie Signaturen, Nachrichtenauthentifizierungscodes und Verschlüsselung unter Verwendung von CBOR zur Serialisierung erstellt und verarbeitet werden. Diese Spezifikation beschreibt zusätzlich, wie kryptografische Schlüssel unter Verwendung von CBOR dargestellt werden.

Dieses Dokument ersetzt zusammen mit RFC 9053 RFC 8152.

Status dieses Memos

Dies ist ein Internet Standards Track-Dokument.

Dieses Dokument ist ein Produkt der Internet Engineering Task Force (IETF). Es repräsentiert den Konsens der IETF-Community. Es wurde einer öffentlichen Prüfung unterzogen und von der Internet Engineering Steering Group (IESG) zur Veröffentlichung freigegeben. Weitere Informationen zu Internetstandards finden Sie in Abschnitt 2 von RFC 7841.

Informationen zum aktuellen Status dieses Dokuments, etwaige Errata und Hinweise, wie Sie Feedback dazu geben können, erhalten Sie unter https://www.rfc-editor.org/info/rfc9052.

Urheberrechtshinweis

Dieses Dokument unterliegt BCP 78 und den gesetzlichen Bestimmungen des IETF Trust in Bezug auf IETF-Dokumente (https://trustee.ietf.org/license-info), die zum Zeitpunkt der Veröffentlichung dieses Dokuments gelten. Bitte lesen Sie diese Dokumente sorgfältig durch, da sie Ihre Rechte und Einschränkungen in Bezug auf dieses Dokument beschreiben. Codekomponenten, die aus diesem Dokument extrahiert werden, müssen den Text der überarbeiteten BSD-Lizenz enthalten, wie in Abschnitt 4.e der gesetzlichen Bestimmungen des Trust beschrieben, und werden ohne Gewährleistung bereitgestellt, wie in der überarbeiteten BSD-Lizenz beschrieben.

Inhaltsverzeichnis

Einführung 1.1. Anforderungsterminologie 1.2. Änderungen gegenüber RFC 8152 1.3. Designänderungen gegenüber JOSE 1.4. CDDL-Grammatik für CBOR-Datenstrukturen 1.5. CBOR-bezogene Terminologie 1.6. Dokumentterminologie
Grundlegende COSE-Struktur
Header-Parameter 3.1. Allgemeine COSE-Header-Parameter
Signaturobjekte 4.1. Signieren mit einem oder mehreren Unterzeichnern 4.2. Signieren mit einem Unterzeichner 4.3. Extern bereitgestellte Daten 4.4. Signatur- und Verifizierungsprozess
Verschlüsselungsobjekte 5.1. Eingehüllte COSE-Struktur 5.1.1. Verteilungsmethoden für Inhaltsschlüssel 5.2. Verschlüsselt für einen einzelnen Empfänger 5.3. Wie man für AEAD-Algorithmen verschlüsselt und entschlüsselt 5.4. Wie man für AE-Algorithmen verschlüsselt und entschlüsselt
MAC-Objekte 6.1. MAC-Nachricht mit Empfängern 6.2. MAC-Nachrichten mit implizitem Schlüssel 6.3. Wie man einen MAC berechnet und verifiziert
Schlüsselobjekte 7.1. Allgemeine COSE-Schlüsselparameter
Taxonomie der von COSE verwendeten Algorithmen 8.1. Signaturalgorithmen 8.2. Algorithmen für Nachrichtenauthentifizierungscodes (MAC) 8.3. Inhaltsverschlüsselungsalgorithmen 8.4. Schlüsselableitungsfunktionen (KDFs) 8.5. Verteilungsmethoden für Inhaltsschlüssel 8.5.1. Direkte Verschlüsselung 8.5.2. Key Wrap 8.5.3. Key Transport 8.5.4. Direkte Schlüsselvereinbarung 8.5.5. Schlüsselvereinbarung mit Key Wrap
CBOR-Codierungsbeschränkungen
Überlegungen zur Anwendungsprofilierung
IANA-Überlegungen 11.1. COSE-Header-Parameter-Register 11.2. COSE-Schlüssel-Allgemeine-Parameter-Register 11.3. Medientyp-Registrierungen 11.3.1. COSE-Sicherheitsnachricht 11.3.2. COSE-Schlüssel-Medientyp 11.4. CoAP-Content-Formats-Register 11.5. CBOR-Tag-Register 11.6. Anweisungen für die Expertenprüfung
Sicherheitsüberlegungen
Referenzen 13.1. Normative Referenzen 13.2. Informative Referenzen Anhang A. Richtlinien für die externe Datenauthentifizierung von Algorithmen Anhang B. Zwei Schichten von Empfängerinformationen Anhang C. Beispiele C.1. Beispiele für signierte Nachrichten C.1.1. Einzelsignatur C.1.2. Mehrere Unterzeichner C.1.3. Signatur mit Kritikalität C.2. Beispiele für einzelne Unterzeichner C.2.1. Einzelne ECDSA-Signatur C.3. Beispiele für eingehüllte Nachrichten C.3.1. Direktes ECDH C.3.2. Direkt plus Schlüsselableitung C.3.3. Verschlüsselter Inhalt mit externen Daten C.4. Beispiele für verschlüsselte Nachrichten C.4.1. Einfache verschlüsselte Nachricht C.4.2. Verschlüsselte Nachricht mit teilweisem IV C.5. Beispiele für MAC-Nachrichten C.5.1. Direkter MAC mit gemeinsamem Geheimnis C.5.2. Direkter ECDH-MAC C.5.3. Eingehüllter MAC C.5.4. MAC-Nachricht mit mehreren Empfängern C.6. Beispiele für MAC0-Nachrichten C.6.1. Direkter MAC mit gemeinsamem Geheimnis C.7. COSE-Schlüssel C.7.1. Öffentliche Schlüssel C.7.2. Private Schlüssel Danksagungen Adresse des Autors
Einführung

Es liegt ein verstärkter Fokus auf kleinen, eingeschränkten Geräten, die das Internet der Dinge (IoT) bilden. Einer der Standards, der aus diesem Prozess hervorgegangen ist, ist "Concise Binary Object Representation (CBOR)" [STD94]. CBOR erweiterte das Datenmodell der JavaScript Object Notation (JSON) [STD90], indem es unter anderem Binärdaten zuließ. CBOR wurde von mehreren IETF-Arbeitsgruppen, die sich mit der IoT-Welt befassen, als ihre Methode zur Codierung 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 die Notwendigkeit, Nachrichtensicherheitsdienste für das IoT bereitzustellen, und die Verwendung von CBOR als Nachrichtencodierungsformat ist sinnvoll.

Die JOSE-Arbeitsgruppe erstellte eine Reihe von Dokumenten [RFC7515] [RFC7516] [RFC7517] [RFC7518], die spezifizierten, wie Verschlüsselungs-, Signatur- und Message Authentication Code (MAC)-Operationen verarbeitet und wie Schlüssel unter Verwendung von JSON codiert werden. Dieses Dokument definiert den Standard CBOR Object Signing and Encryption (COSE), der dasselbe für das CBOR-Codierungsformat tut. Dieses Dokument wird mit [RFC9053] kombiniert, das einen anfänglichen Satz von Algorithmen bereitstellt. Obwohl stark versucht wird, den Charakter der ursprünglichen JSON Object Signing and Encryption (JOSE)-Dokumente beizubehalten, werden zwei Überlegungen berücksichtigt:

CBOR verfügt über Funktionen, die in JSON nicht vorhanden sind und deren Verwendung angemessen ist. Ein Beispiel hierfür ist die Tatsache, dass CBOR eine Methode zur direkten Codierung von Binärdaten hat, ohne diese zuerst in eine base64-codierte Textzeichenfolge umzuwandeln.
COSE ist keine direkte Kopie der JOSE-Spezifikation. Bei der Erstellung von COSE wurden Entscheidungen, die für JOSE getroffen wurden, erneut geprüft. In vielen Fällen wurde entschieden, zu unterschiedlichen Ergebnissen zu kommen, da die Kriterien nicht immer dieselben waren.

Dieses Dokument enthält:

Die Beschreibung der Struktur für die CBOR-Objekte, die über die Leitung übertragen werden. Es werden jeweils zwei Objekte für Verschlüsselung, Signatur und Nachrichtenauthentifizierung definiert. Ein Objekt ist für den Transport von Schlüsseln und eines für den Transport von Schlüsselgruppen definiert.
Die Verfahren, die verwendet werden, um die Eingaben für die kryptografischen Funktionen zu erstellen, die für jede der Strukturen erforderlich sind.
Eine Reihe von Attributen, die für die verschiedenen Sicherheitsobjekte gelten.

Dieses Dokument enthält nicht die Regeln und Verfahren zur Verwendung spezifischer kryptografischer Algorithmen. Details zu spezifischen Algorithmen finden sich in [RFC9053] und [RFC8230]. Details für zusätzliche Algorithmen werden voraussichtlich in zukünftigen Dokumenten definiert.

COSE wurde ursprünglich als Teil einer Lösung zur Bereitstellung von Sicherheit für Constrained RESTful Environments (CoRE) entwickelt, und dies erfolgt unter Verwendung von [RFC8613] und [CORE-GROUPCOMM]. COSE ist jedoch nicht nur auf diese Fälle beschränkt und kann an jedem Ort verwendet werden, an dem man entweder JOSE oder Cryptographic Message Syntax (CMS) [RFC5652] zum Zwecke der Bereitstellung von Sicherheitsdiensten in Betracht ziehen würde. COSE ist wie JOSE und CMS nur für die Verwendung in Store-and-Forward- oder Offline-Protokollen vorgesehen. Die Verwendung von COSE in Online-Protokollen, die Verschlüsselung benötigen, erfordert, dass ein Online-Schlüsselerstellungsprozess durchgeführt wird, bevor Objekte hin und her gesendet werden. Jede Anwendung, die COSE für Sicherheitsdienste verwendet, muss zuerst bestimmen, welche Sicherheitsdienste erforderlich sind, und dann die geeigneten COSE-Strukturen und kryptografischen Algorithmen basierend auf diesen Anforderungen auswählen. Abschnitt 10 enthält zusätzliche Informationen darüber, was Anwendungen bei der Verwendung von COSE angeben müssen.

Ein Merkmal, das in CMS vorhanden ist, aber in diesem Standard nicht, ist eine Digest-Struktur. Dieses Weglassen ist absichtlich. Es ist besser, wenn die Struktur in jedem Protokoll definiert wird, da verschiedene Protokolle einen unterschiedlichen Satz von Feldern als Teil der Struktur enthalten möchten. Während ein Algorithmusbezeichner und der Digest-Wert für alle Anwendungen gemeinsam sein werden, sind die beiden Werte möglicherweise nicht immer benachbart, da der Algorithmus einmal mit mehreren Werten definiert werden könnte. Anwendungen möchten möglicherweise zusätzlich zusätzliche Datenfelder als Teil der Struktur definieren. Ein solches anwendungsspezifisches Element wäre das Einschließen eines URI oder eines anderen Zeigers darauf, wo die Daten, die gehasht werden, abgerufen werden können. [RFC9054] enthält eine solche mögliche Struktur und definiert einen Satz von Digest-Algorithmen.

Während des Prozesses der Weiterentwicklung von COSE zum Internetstandard wurde festgestellt, dass die Beschreibung der Sicherheitseigenschaften von Gegensignaturen für die COSE_Sign1-Struktur falsch war. Da die beschriebenen Sicherheitseigenschaften -- die einer echten Gegensignatur -- diejenigen waren, die die Arbeitsgruppe wünschte, wurde beschlossen, den gesamten Gegensignaturtext aus diesem Dokument zu entfernen und ein neues Dokument [COSE-COUNTERSIGN] zu erstellen, um sowohl den alten Gegensignaturalgorithmus und die Header-Parameter abzuschaffen als auch einen neuen Algorithmus und Header-Parameter mit den gewünschten Sicherheitseigenschaften zu definieren.

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. Änderungen gegenüber RFC 8152

Aufteilung des ursprünglichen Dokuments in dieses Dokument und [RFC9053].
Hinzufügen von Text, der beschreibt, warum es keine von COSE definierte Digest-Struktur gibt.
Textklarstellungen und Änderungen in der Terminologie vorgenommen.
Entfernen aller Details bezüglich Gegensignaturen und Platzierung in [COSE-COUNTERSIGN].

1.3. Designänderungen gegenüber JOSE

Eine einzige Gesamtnachrichtenstruktur wurde definiert, damit verschlüsselte, signierte und MAC-Nachrichten leicht identifiziert werden können und dennoch eine konsistente Sicht haben.
Signierte Nachrichten unterscheiden zwischen den geschützten und ungeschützten Header-Parametern, die sich auf den Inhalt beziehen, und solchen, die sich auf die Signatur beziehen.
MAC-Nachrichten sind von signierten Nachrichten getrennt.
MAC-Nachrichten haben die Möglichkeit, denselben Satz von Empfängeralgorithmen wie eingehüllte Nachrichten zu verwenden, um den MAC-Authentifizierungsschlüssel zu erhalten.
Binärcodierungen werden anstelle von base64url-Codierungen verwendet, um Binärdaten zu codieren.
Das Authentifizierungs-Tag für Verschlüsselungsalgorithmen wurde mit dem Geheimtext kombiniert.
Der Satz kryptografischer Algorithmen wurde in einigen Richtungen erweitert und in anderen gekürzt.

1.4. CDDL-Grammatik für CBOR-Datenstrukturen

Als COSE ursprünglich geschrieben wurde, war die Concise Data Definition Language (CDDL) [RFC8610] noch nicht in einem RFC veröffentlicht worden, sodass sie nicht als Datenbeschreibungssprache verwendet werden konnte, um die von COSE verwendeten CBOR-Datenstrukturen normativ zu beschreiben. Aus diesem Grund werden die hier definierten CBOR-Datenobjekte in Prosa beschrieben. Zusätzliche (nicht normative) Beschreibungen der COSE-Datenobjekte werden in einer Teilmenge von CDDL bereitgestellt, die unten beschrieben wird.

Dieses Dokument wurde entwickelt, indem zuerst an der Grammatik gearbeitet und dann die dazu passende Prosa entwickelt wurde. Ein Artefakt davon ist, dass die Prosa unter Verwendung der von der Concise Data Definition Language (CDDL) [RFC8610] definierten Primitivtyp-Zeichenfolgen geschrieben wurde. In dieser Spezifikation werden die folgenden primitiven Typen verwendet:

any: Ein unspezifischer Wert, der es erlaubt, alle CBOR-Werte hier zu platzieren.

bool: Ein boolescher Wert (Haupttyp 7, Wert 21; false: Haupttyp 7, Wert 20).

bstr: Byte-String (Haupttyp 2).

int: Eine vorzeichenlose Ganzzahl oder eine negative Ganzzahl.

nil: Ein Nullwert (Haupttyp 7, Wert 22).

nint: Eine negative Ganzzahl (Haupttyp 1).

tstr: Eine UTF-8-Textzeichenfolge (Haupttyp 3).

uint: Eine vorzeichenlose Ganzzahl (Haupttyp 0).

Drei Syntaxen aus CDDL erscheinen in diesem Dokument als Abkürzung. Diese sind:

FOO / BAR: Gibt an, dass entweder FOO oder BAR hier erscheinen kann.

[+ FOO]: Gibt an, dass der Typ FOO ein- oder mehrmals in einem Array erscheint.

FOO: Gibt an, dass der Typ FOO null- oder mehrmals erscheint.

Zwei der von CDDL definierten Einschränkungen werden auch in diesem Dokument verwendet. Diese sind:

type1 .cbor type2: Gibt an, dass der Inhalt von type1, normalerweise bstr, einen Wert von type2 enthält.

type1 .size integer: Gibt an, dass der Inhalt von type1 integer Bytes lang ist.

Neben der Prosabeschreibung wird eine Grammatik für die CBOR-Datenstrukturen in der zuvor beschriebenen Teilmenge von CDDL präsentiert. Die CDDL-Grammatik ist informativ; die Prosabeschreibung ist normativ.

Die gesammelte CDDL kann aus der XML-Version dieses Dokuments über den unten stehenden XPath-Ausdruck extrahiert werden. (Je nachdem, welchen XPath-Auswerter man verwendet, kann es notwendig sein, mit > als Entität umzugehen.)

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

CDDL erwartet, dass das anfängliche Nichtterminalsymbol das erste Symbol in der Datei ist. Aus diesem Grund wird das erste Fragment von CDDL hier vorgestellt.

start = COSE_Messages / COSE_Key / COSE_KeySet / Internal_Types

; Dies ist definiert, um das Tool leiser zu machen: Internal_Types = Sig_structure / Enc_structure / MAC_structure

Das Nichtterminal Internal_Types ist für den Umgang mit den automatisierten Validierungstools definiert, die während des Schreibens dieses Dokuments verwendet wurden. Es verweist auf diejenigen Nichtterminale, die für Sicherheitsberechnungen verwendet werden, aber nicht für den Transport ausgegeben werden.

1.5. CBOR-bezogene Terminologie

In JSON werden Maps als Objekte bezeichnet und haben nur eine Art von Map-Schlüssel: eine Textzeichenfolge. In COSE verwenden wir Textzeichenfolgen, negative Ganzzahlen und vorzeichenlose Ganzzahlen als Map-Schlüssel. Die Ganzzahlen werden zur Kompaktheit der Codierung und zum einfachen Vergleich verwendet. Die Einbeziehung von Textzeichenfolgen ermöglicht auch die Verwendung eines zusätzlichen Bereichs kurzer codierter Werte. Da das Wort "Key" (Schlüssel) hauptsächlich in seiner anderen Bedeutung, als kryptografischer Schlüssel, verwendet wird, verwenden wir den Begriff "Label" für diese Verwendung als Map-Schlüssel.

In einer durch diese Spezifikation definierten CBOR-Map ist das Vorhandensein eines Labels, das weder eine Textzeichenfolge noch eine Ganzzahl ist, ein Fehler. Anwendungen können entweder die Verarbeitung fehlschlagen lassen oder Nachrichten verarbeiten, indem sie falsche Labels ignorieren; sie DÜRFEN JEDOCH KEINE (MUST NOT) Nachrichten mit falschen Labels erstellen.

Ein CDDL-Grammatikfragment definiert das Nichtterminal "label", wie im vorherigen Absatz, und "values", das die Verwendung eines beliebigen Wertes erlaubt.

label = int / tstr values = any

1.6. Dokumentterminologie

In diesem Dokument verwenden wir die folgende Terminologie:

Byte: Ein Synonym für Oktett.

Constrained Application Protocol (CoAP): Ein spezialisiertes Webübertragungsprotokoll zur Verwendung in eingeschränkten Systemen. Es ist in [RFC7252] definiert.

Authenticated Encryption (AE) algorithms [RFC5116]: Verschlüsselungsalgorithmen, die eine Authentifizierungsprüfung des Inhalts zusammen mit dem Verschlüsselungsdienst bereitstellen. Ein Beispiel für einen in COSE verwendeten AE-Algorithmus ist AES Key Wrap [RFC3394]. Diese Algorithmen werden für die Schlüsselverschlüsselung verwendet, aber Algorithmen für Authenticated Encryption with Associated Data (AEAD) würden bevorzugt.

AEAD algorithms [RFC5116]: Verschlüsselungsalgorithmen, die denselben Authentifizierungsdienst für den Inhalt bieten wie AE-Algorithmen und auch erlauben, dass zugehörige Daten, die nicht Teil des verschlüsselten Körpers sind, in den Authentifizierungsdienst einbezogen werden. Ein Beispiel für einen in COSE verwendeten AEAD-Algorithmus ist AES-GCM [RFC5116]. Diese Algorithmen werden für die Inhaltsverschlüsselung verwendet und können auch für die Schlüsselverschlüsselung verwendet werden.

"Context" (Kontext) wird im gesamten 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 Programmkonfiguration. Der zu verwendende Kontext kann implizit sein, unter Verwendung des in [RFC8613] definierten Header-Parameters "kid context" identifiziert werden oder durch einen protokollspezifischen Bezeichner identifiziert werden. Kontext sollte im Allgemeinen in die kryptografische Konstruktion einbezogen werden; weitere Einzelheiten siehe Abschnitt 4.3.

Der Begriff "byte string" (Byte-String) wird für Folgen von Bytes verwendet, während der Begriff "text string" (Textzeichenfolge) für Folgen von Zeichen verwendet wird.