Zusammenfassung

  • rsaEncryption sagt laut RFC 9690 nicht, dass der Schlüsselinhaber RSA-KEM akzeptiert; die Bereitschaft braucht einen eigenen, begrenzten Beleg.
  • Eine belastbare Versandentscheidung verbindet Zertifikat, Herkunft und Alter der Fähigkeitsanzeige, beide KDF-Stellen, KEK-Länge, Wrap-Verfahren und CMS-Inhaltstyp.

Die Fehlannahme entsteht oft in einer Abstraktionsschicht. Ein Zertifikatsdienst meldet „RSA-Schlüssel gültig“. Eine Nachrichtenplattform liest daraus „RSA-KEM verfügbar“. Der erste Satz beschreibt Schlüsselmaterial und Validierung. Der zweite behauptet etwas über Software, Konfiguration und Politik des Empfängers.

RFC 9690 stellt klar, dass der übliche rsaEncryption-Bezeichner die Annahme von RSA-KEM nicht signalisiert. Das Zertifikat kann weiter gültig sein, obwohl der Empfänger den Pfad abgeschaltet, den Inhaltstyp geändert oder nur eine andere Komponentenkombination zugelassen hat.

RSA-KEM ist außerdem kein einzelner Schalter. Eine frische Zufallszahl z wird mit dem RSA-Schlüssel gekapselt; eine interne KDF erzeugt das gemeinsame Geheimnis. Danach nutzt CMS eine weitere KDF, um den KEK für den Inhaltschlüssel zu bilden. Beide KDFs dürfen sich unterscheiden. KDF3/SHA-256 und AES-Wrap-128 sind der Pflichtsockel, nicht die vollständige Fähigkeitsbeschreibung.

Teilweise Fähigkeitsanzeige

Die Bereitschaft kann über SMIMECapabilities in signed-data nach RFC 8551 oder über die Zertifikatserweiterung aus RFC 4262 angezeigt werden. Das ist positiver als eine Ableitung aus der Schlüsselform, bleibt aber eine partielle Liste. Eine ältere signierte Nachricht belegt eine damalige Anzeige, keinen aktuellen Betriebszustand.

Darum gehören Unterzeichner, Zeitpunkt, Quelle, Zertifikatsbindung und Parameter in den Beleg. Das Vorhandensein beweist weder laufenden Dienst noch Autorisierung der konkreten Nachricht; das Fehlen beweist wegen der partiellen Liste nicht automatisch Nichtunterstützung.

Für einen ausschließlich RSA-KEM gewidmeten Schlüssel dient id-rsa-kem-spki. Ohne Parameter gilt intern KDF3/SHA-256. Mit Parametern müssen GenericHybridParameters KDF, KEK-Länge und Wrap des KEMRecipientInfo begrenzen. Ein vorhandenes keyUsage darf nur keyEncipherment enthalten. Das ist eine engere Zweckangabe, aber noch kein Nachweis für private-key custody oder erfolgreiche Entkapselung.

Rückwärtskompatibilität bleibt ein eigener Pfad

RFC 5990 verwendete KeyTransRecipientInfo und verband C mit WK. RFC 9690 setzt auf das allgemeine KEMRecipientInfo aus RFC 9629 und trennt kemct von encryptedKey. Rückwärtskompatibilität erleichtert Migration, vereinheitlicht aber weder Container noch Fehlerstellen.

Ein überprüfbares Protokoll nennt RFC 5990 oder RFC 9690, Zertifikat, Fähigkeitsbeleg und exaktes Tupel. Auf Empfängerseite trennt es Längen- und Bereichsprüfung, private Operation, Geheimnisableitung, KEK-Ableitung, Unwrap, Inhaltsverarbeitung und Anwendungsentscheidung. Erfolgreiche Konstruktion beim Absender beweist keine dieser entfernten Stufen.

Ein Beleg mit Ablaufdatum

Gespeichert werden Zertifikatsfingerabdruck und Pfadentscheidung, AlgorithmIdentifier samt Parameterbytes, keyUsage, Signatur und Alter der Fähigkeitsanzeige, interne KDF, CMS-KDF, KEK-Länge, Wrap, Inhaltstyp und der gewählte Kompatibilitätspfad.

Zertifikatswechsel, Client-Update, Algorithmusabschaltung, Inhaltswechsel oder der erste tupelspezifische Fehler lassen den Cache ablaufen. Bei Unsicherheit wird bestätigt oder ein separat autorisierter Weg gewählt; rsaEncryption allein genügt nicht.

RFC 8017, RFC 3394, RFC 4086 und RFC 5280 definieren RSA, Wrap, Zufall und Zertifikate. Sie beobachten nicht den lebenden Empfängerprozess.

Lu Hengs minimale Anfangsspezifikation spricht für einen schmalen gemeinsamen Sockel und explizite lokale Folgeentscheidungen. Die Realitätsebenen halten Zertifikat, Anzeige, Struktur, private Berechnung und Geschäftsentscheidung auseinander. Running-Code-Primat verlangt als letzten Beleg das tatsächliche Verhalten des Empfängers, nicht die Möglichkeit, die ein OID suggeriert.

Quellen