Anhang A. Richtlinien für die Authentifizierung externer Daten von Algorithmen

Während der Entwicklung von COSE wurde die Anforderung, dass der Algorithmusidentifikator in den geschützten Attributen enthalten sein muss, von einem "Muss" auf ein "Sollte" gelockert. Zwei grundlegende Gründe wurden vorgebracht, um diese Position zu unterstützen. Erstens wird die resultierende Nachricht kleiner sein, wenn der Algorithmusidentifikator in den häufigsten Nachrichten in einer CoAP-Umgebung weggelassen wird. Zweitens gibt es einen potenziellen Fehler, der auftreten wird, wenn die vollständige Überprüfung zwischen den verschiedenen Orten, an denen ein Algorithmusidentifikator platziert werden könnte (die Nachricht selbst, eine Anwendungsanweisung, die Schlüsselstruktur, die der Absender besitzt, und die Schlüsselstruktur, die der Empfänger besitzt), nicht korrekt durchgeführt wird.

Dieser Anhang legt dar, wie eine solche Änderung vorgenommen werden kann und welche Details eine Anwendung spezifizieren muss, um diese Option zu nutzen. Es werden zwei verschiedene Sätze von Details spezifiziert: diejenigen, die benötigt werden, um einen Algorithmusidentifikator wegzulassen, und diejenigen, die benötigt werden, um die Variante des Gegensignaturattributs zu verwenden, die keine Attribute über sich selbst enthält.

Es werden drei Sätze von Empfehlungen dargelegt. Der erste Satz von Empfehlungen gilt für die Identifizierung eines impliziten Algorithmus für eine einzelne Schicht eines COSE-Objekts. Der zweite Satz von Empfehlungen gilt für die Identifizierung mehrerer impliziter Algorithmen für mehrere Schichten eines COSE-Objekts. Der dritte Satz von Empfehlungen gilt für das Vorhandensein impliziter Algorithmen für mehrere COSE-Objektkonstrukte.

Die Schlüsselwörter aus BCP 14 ([RFC2119] und [RFC8174]) werden hier absichtlich nicht verwendet. Diese Spezifikation kann Empfehlungen geben, aber sie kann sie nicht durchsetzen.

Dieser Satz von Empfehlungen gilt für den Fall, dass eine Anwendung einen festen Algorithmus zusammen mit den Schlüsselinformationen zur Verwendung in einem einzigen COSE-Objekt verteilt. Dies gilt normalerweise für die kleinsten der COSE-Objekte – speziell COSE_Sign1, COSE_Mac0 und COSE_Encrypt0 –, könnte aber auch für die anderen Strukturen gelten.

Die folgenden Punkte sollten berücksichtigt werden:

Anwendungen müssen den Satz von COSE-Strukturen auflisten, in denen implizite Algorithmen verwendet werden sollen. Anwendungen müssen verlangen, dass der Empfang eines expliziten Algorithmusidentifikators in einer dieser Strukturen dazu führt, dass die Nachricht abgelehnt wird. Diese Anforderung wird gestellt, damit es nie einen Fall gibt, in dem Unklarheit über die Frage besteht, welcher Algorithmus verwendet werden soll, der implizite oder der explizite. Dies gilt auch dann, wenn der transportierte Algorithmusidentifikator ein geschütztes Attribut ist. Dies gilt auch dann, wenn der transportierte Algorithmus derselbe ist wie der implizite Algorithmus.
Anwendungen müssen den Satz von Informationen definieren, der als Teil eines Kontexts betrachtet werden soll, wenn Algorithmusidentifikatoren weggelassen werden. Zumindest wäre dies der Schlüsselidentifikator (falls erforderlich), der Schlüssel, der Algorithmus und die COSE-Struktur, mit der er verwendet wird. Anwendungen sollten die Verwendung eines einzelnen Schlüssels auf einen einzelnen Algorithmus beschränken. Wie für einige der Algorithmen in [RFC9053] angemerkt, kann die Verwendung desselben Schlüssels in verschiedenen, verwandten Algorithmen zum Durchsickern von Informationen über den Schlüssel, zum Durchsickern über die Daten oder zur Fähigkeit zur Durchführung von Fälschungen führen.
In vielen Fällen werden Anwendungen, die den Algorithmusidentifikator implizit machen, auch den Kontextidentifikator aus demselben Grund implizit machen wollen. Das heißt, das Weglassen des Kontextidentifikators verringert die Nachrichtengröße (möglicherweise erheblich, abhängig von der Länge des Identifikators). Anwendungen, die dies tun, müssen die Umstände beschreiben, unter denen der Kontextidentifikator weggelassen werden soll und wie der Kontextidentifikator in diesen Fällen abgeleitet werden soll. (Eine erschöpfende Suche über alle Schlüssel würde normalerweise nicht als akzeptabel angesehen werden.) Ein Beispiel dafür, wie dies getan werden kann, ist die Bindung des Kontexts an einen Transaktionsidentifikator. Beide würden in der ursprünglichen Nachricht gesendet, aber danach müsste nur der Transaktionsidentifikator gesendet werden, da der Kontext in den Transaktionsidentifikator eingebunden ist. Ein anderer Weg wäre, einen Kontext mit einer Netzwerkadresse zu verknüpfen. Es kann angenommen werden, dass alle Nachrichten, die von einer einzigen Netzwerkadresse kommen, mit einem bestimmten Kontext verknüpft sind. (In diesem Fall würde die Adresse normalerweise als Teil des Kontexts verteilt werden.)
Anwendungen können sich nicht darauf verlassen, dass Schlüsselidentifikatoren eindeutig sind, es sei denn, sie unternehmen erhebliche Anstrengungen, um sicherzustellen, dass sie so berechnet werden, dass diese Garantie geschaffen wird. Selbst wenn eine Anwendung dies tut, könnte die Eindeutigkeit verletzt werden, wenn die Anwendung in verschiedenen Kontexten (d. h. mit einem anderen Kontextanbieter) ausgeführt wird oder wenn das System die Sicherheitskontexte aus verschiedenen Anwendungen in einem einzigen Speicher kombiniert.
Anwendungen sollten die Praxis fortsetzen, den Algorithmusidentifikator zu schützen. Da dies nicht dadurch geschieht, dass er im Feld für geschützte Attribute platziert wird, sollten Anwendungen eine anwendungsspezifische externe Datenstruktur definieren, die diesen Wert enthält. Dieses externe Datenfeld kann als solches für Inhaltsverschlüsselungs-, MAC- und Signaturalgorithmen verwendet werden. Es kann im SuppPrivInfo-Feld für diejenigen Algorithmen verwendet werden, die eine KDF verwenden, um einen Schlüsselwert abzuleiten. Anwendungen möchten möglicherweise auch andere Informationen schützen, die ebenfalls Teil der Kontextstruktur sind. Es sollte beachtet werden, dass jene Felder, wie der Schlüssel oder ein Basis-IV, die dadurch geschützt sind, dass sie in der kryptografischen Berechnung verwendet werden, nicht in das externe Datenfeld aufgenommen werden müssen.

Der zweite Fall ist, dass mehrere implizite Algorithmusidentifikatoren für ein mehrschichtiges COSE-Objekt spezifiziert sind. Ein Beispiel dafür, wie dies funktionieren würde, ist der Verschlüsselungskontext, den eine Anwendung spezifiziert, der einen Inhaltsverschlüsselungsalgorithmus, einen Key-Wrap-Algorithmus, einen Schlüsselidentifikator und ein gemeinsames Geheimnis enthält. Der Absender lässt das Senden des Algorithmusidentifikators sowohl für die Inhaltsschicht als auch für die Empfängerschicht weg und lässt nur den Schlüsselidentifikator übrig. Der Empfänger verwendet dann den Schlüsselidentifikator, um die impliziten Algorithmusidentifikatoren zu erhalten.

Die folgenden zusätzlichen Punkte müssen berücksichtigt werden:

Anwendungen, die dies unterstützen wollen, müssen eine Struktur definieren, die sowohl die COSE-Struktur, die mit einem gegebenen Schlüssel verwendet werden soll, als auch die Struktur und den Algorithmus, die für die sekundäre Schicht verwendet werden sollen, ermöglicht und eindeutig identifiziert. Der Schlüssel für die sekundäre Schicht wird wie gewohnt aus der Empfängerschicht berechnet.

Der dritte Fall ist, dass mehrere implizite Algorithmusidentifikatoren vorhanden sind, die jedoch auf potenziell nicht verwandte Schichten oder verschiedene COSE-Objekte abzielen. Es gibt eine Reihe verschiedener Szenarien, in denen dies anwendbar sein könnte. Einige dieser Szenarien sind:

Zwei Kontexte werden als Paar verteilt. Jeder der Kontexte ist zur Verwendung mit einer COSE_Encrypt-Nachricht bestimmt. Jeder Kontext besteht aus unterschiedlichen geheimen Schlüsseln und IVs und möglicherweise sogar unterschiedlichen Algorithmen. Ein Kontext ist für das Senden von Nachrichten von Partei A an Partei B bestimmt, und der zweite Kontext ist für das Senden von Nachrichten von Partei B an Partei A bestimmt. Dies bedeutet, dass keine Chance besteht, dass ein Reflexionsangriff auftritt, da jede Partei unterschiedliche geheime Schlüssel verwendet, um ihre Nachrichten zu senden; eine Nachricht, die zu ihr zurückreflektiert wird, würde nicht entschlüsselt werden können.
Zwei Kontexte werden als Paar verteilt. Der erste Kontext wird für die Verschlüsselung der Nachricht verwendet, und der zweite Kontext wird verwendet, um eine Gegensignatur auf der Nachricht zu platzieren. Die Absicht ist, dass der zweite Kontext unabhängig vom ersten Kontext an andere Entitäten verteilt werden kann. Dies ermöglicht diesen Entitäten zu validieren, dass die Nachricht von einer Einzelperson stammt, ohne die Nachricht entschlüsseln und den Inhalt sehen zu können.
Zwei Kontexte werden als Paar verteilt. Der erste Kontext enthält einen Schlüssel für den Umgang mit MAC-versehenen Nachrichten, und der zweite Kontext enthält einen anderen Schlüssel für den Umgang mit verschlüsselten Nachrichten. Dies ermöglicht eine einheitliche Verteilung von Schlüsseln an Teilnehmer für verschiedene Arten von Nachrichten, die unterschiedliche Schlüssel haben, wobei die Schlüssel jedoch auf koordinierte Weise verwendet werden können.

Für diese Fälle müssen die folgenden zusätzlichen Punkte berücksichtigt werden:

Anwendungen müssen sicherstellen, dass die mehreren Kontexte verknüpft bleiben. Wenn einer der Kontexte aus irgendeinem Grund ungültig wird, sollten alle damit verknüpften Kontexte ebenfalls ungültig werden.