Zusammenfassung

  • RFC 9939 weist den RFC-5958-Strukturen PrivateKeyInfo und EncryptedPrivateKeyInfo CMS Content Types zu.
  • Eine OID ordnet einem Empfänger eine erwartete Syntax zu. Sie belegt nicht Besitz, sichere Wiederherstellung, Zweckbindung oder die Entscheidung eines vertrauenden Systems.

In einer Übergabeliste kann ein lesbarer Objektname die eigentliche Entscheidung verdecken. id-ct-encrPrivateKeyInfo erscheint, die Prüfung der ASN.1-Form gelingt, und aus einem Parsergebnis wird eine Freigabe. Gerade diese Schlussfolgerung liefert RFC 9939 nicht.

RFC 9939 gibt einer einzelnen PrivateKeyInfo und einer einzelnen EncryptedPrivateKeyInfo innerhalb von CMS eindeutige Namen. Der dezimale Wert 52 im CMS-Content-Type-Zweig steht für id-ct-privateKeyInfo, 53 für id-ct-encrPrivateKeyInfo. Ergänzt werden eine ASN.1-Modulkennung sowie die beiden inneren application/cms-Content-Types. Das IANA-Register hält diese Zuordnung fest. Es koordiniert Syntaxbezeichner, nicht Verwahrung oder Berechtigung.

RFC 5958 beschreibt die begrenzten Tatsachen im Paket. Die kompatible Form PrivateKeyInfo/OneAsymmetricKey enthält Version, Algorithmuskennung, privates Schlüsselmaterial sowie optionale Attribute und einen optionalen öffentlichen Schlüssel. Die verschlüsselte Form enthält eine Verschlüsselungsalgorithmuskennung und verschlüsselte Daten. Eine Implementierung kann diese Struktur prüfen. Sie weiß deshalb noch nicht, ob der Empfänger das erforderliche Geheimnis besitzt, ob Schutz und Übertragung angemessen waren, ob ein wiederhergestellter Schlüssel zum erwarteten Zertifikat passt oder ob eine bestimmte Operation erlaubt ist.

CMS bietet Schutzmechanismen, aber keinen Automatismus für diese Fragen. RFC 5652 beschreibt eine Kapselung für Signatur, Authentisierung und Verschlüsselung; die verwendenden Protokolle wählen passende Algorithmen. RFC 5959 definiert Algorithmuskonventionen für EncryptedPrivateKeyInfo. RFC 5958 warnt, dass die Offenlegung privaten Materials eine Täuschung ermöglichen kann und der Paketinhalt nicht allein durch seinen Typ geschützt ist.

Ein belastbarer Übergabebeleg trennt daher Objekt-Hash, OID, Parser und Version, Algorithmen, äußere Schutzhülle, Empfänger- oder Schlüsselverwaltungsnachweis, gegebenenfalls autorisierte Integritäts- und Entschlüsselungsprüfung, Zweck, Aufbewahrung und die davon getrennte Vertrauensentscheidung. Laufender Code belegt sein lokales Ergebnis. Er verleiht nicht selbst die Nutzungsbefugnis für ein Geheimnis an einer anderen Verantwortungsgrenze.

Sources