10. Überlegungen zum Anwendungsprofiling

10. Überlegungen zum Anwendungsprofiling

Dieses Dokument soll eine Reihe von Sicherheitsdiensten bereitstellen, aber keine Anforderungen an die Algorithmusimplementierung für eine bestimmte Verwendung auferlegen. Die Interoperabilitätsanforderungen werden dafür bereitgestellt, wie jeder der einzelnen Dienste verwendet wird und wie die Algorithmen für die Interoperabilität verwendet werden sollen. Die Anforderungen darüber, welche Algorithmen und welche Dienste benötigt werden, werden auf jede Anwendung verschoben.

Ein Beispiel für ein Profil finden Sie in [RFC8613], wo eines für die Übertragung von Inhalten in Kombination mit CoAP-Headern entwickelt wurde.

Es ist beabsichtigt, ein Profil dieses Dokuments zu erstellen, das die Interoperabilitätsanforderungen für diese spezifische Anwendung definiert. Dieser Abschnitt enthält eine Reihe von Richtlinien und Themen, die beim Profiling dieses Dokuments berücksichtigt werden müssen.

• Anwendungen müssen den Satz von Nachrichten bestimmen, die in diesem Dokument definiert sind, die sie verwenden werden. Der Satz von Nachrichten entspricht ziemlich direkt dem benötigten Satz von Sicherheitsdiensten und Sicherheitsstufen.

• Anwendungen können neue Header-Parameter für einen bestimmten Zweck definieren. Anwendungen werden oft spezifische Header-Parameter auswählen, die verwendet oder nicht verwendet werden sollen. Beispielsweise würde eine Anwendung normalerweise eine Präferenz für die Verwendung entweder des IV- oder des Partial-IV-Header-Parameters angeben. Wenn der Partial-IV-Header-Parameter angegeben ist, muss die Anwendung auch definieren, wie der feste Teil des IV bestimmt wird.

• Wenn Anwendungen extern definierte authentifizierte Daten verwenden, müssen sie definieren, wie diese Daten kodiert werden. Dieses Dokument geht davon aus, dass die Daten als Bytefolge bereitgestellt werden. Weitere Informationen finden Sie in Abschnitt 4.3.

• Anwendungen müssen den Satz von Sicherheitsalgorithmen bestimmen, der verwendet werden soll. Bei der Auswahl der Algorithmen, die als obligatorisch zu implementierender Satz verwendet werden sollen, sollte in Betracht gezogen werden, verschiedene Arten von Algorithmen zu wählen, wenn zwei für einen bestimmten Zweck ausgewählt werden. Ein Beispiel hierfür wäre die Wahl von HMAC-SHA512 und AES-CMAC (Cipher-Based Message Authentication Code) als unterschiedliche MAC-Algorithmen; die Konstruktion ist zwischen diesen beiden Algorithmen sehr unterschiedlich. Dies bedeutet, dass eine Schwächung eines Algorithmus unwahrscheinlich zu einer Schwächung der anderen Algorithmen führen würde. Natürlich bieten diese Algorithmen nicht dasselbe Sicherheitsniveau und sind daher möglicherweise nicht für die gewünschte Sicherheitsfunktionalität vergleichbar. Zusätzliche Anleitungen finden Sie in [BCP201].

• Anwendungen müssen möglicherweise eine Art von Aushandlungs- oder Ermittlungsmethode bereitstellen, wenn mehrere Algorithmen oder Nachrichtenstrukturen zulässig sind. Die Methode kann von etwas so Einfachem wie der Anforderung einer Vorkonfiguration des Satzes von Algorithmen bis zur Bereitstellung einer im Protokoll integrierten Ermittlungsmethode reichen. S/MIME bot eine Reihe verschiedener Möglichkeiten, das Problem anzugehen, denen Anwendungen folgen könnten:

  • Werbung in der Nachricht (S/MIME-Funktionen) [RFC8551].

  • Werbung im Zertifikat (Funktionserweiterung) [RFC4262].

  • Mindestanforderungen für S/MIME, die im Laufe der Zeit aktualisiert wurden [RFC2633] [RFC3851] [RFC5751] [RFC8551]. (Beachten Sie, dass [RFC2633] durch [RFC3851] veraltet wurde, das durch [RFC5751] veraltet wurde, das durch [RFC8551] veraltet wurde.)