Zusammenfassung

  • RFC 9879 erlaubt PBMAC1 in PKCS #12, verlangt PBKDF2/HMAC-SHA-256 als gemeinsamen Nenner und korrigiert die Passwortkodierung aus RFC 9579.
  • Ein alter Leser kann trotz unverstandener MAC-Prüfung an verschlüsseltes Schlüsselmaterial gelangen; schwache Passwörter und KDF-Parameter bleiben eigene Risiken.
  • Eine belastbare Migration protokolliert wirksame Parameter, MAC-Ergebnis, Fehlerpolitik und spätere Schlüsselverwahrung getrennt.

PKCS #12 transportiert Zertifikate, private Schlüssel und andere Geheimnisse zwischen Plattformen. „Import erfolgreich“ sagt dabei zu wenig. Vielleicht wurde nur die Struktur gelesen. Vielleicht wurde verschlüsselter Inhalt geöffnet. Vielleicht wurde der MAC geprüft. Vielleicht erfüllten die Parameter die lokale Mindeststärke. Vielleicht blieb der Schlüssel im vorgesehenen Tresor. Jeder Schritt braucht einen eigenen Beleg.

RFC 9879 wurde im September 2025 als informatorisches IETF-Dokument veröffentlicht. Er ersetzt RFC 9579 und aktualisiert RFC 7292 sowie RFC 8018. id-PBMAC1 darf nun im DigestAlgorithmIdentifier von PKCS #12 stehen. Dann müssen passende PBMAC1-params vorhanden sein, und der Wert muss über authSafe mit genau diesen Parametern berechnet werden.

Die Modernisierung löst eine alte Bindung. Das ursprüngliche PKCS-#12-Verfahren bot bei der Ableitung des MAC-Schlüssels wenig Spielraum. PBMAC1 benennt KDF und Authentisierungsfunktion. Jede Implementierung muss PBKDF2 mit HMAC-SHA-256 für Integritätsprüfung und PBKDF2-PRF unterstützen. Weitere SHA-2-HMACs sind empfohlen; scrypt und andere Optionen dürfen hinzukommen.

Damit wird das Parameterobjekt zur entscheidenden Prüfoberfläche. Die Länge des abgeleiteten Schlüssels muss explizit sein. PBKDF2 ohne keyLength darf nicht akzeptiert werden; bei HMAC-SHA-256 sind 32 Oktette vorgesehen. PBKDF2 mit HMAC-SHA-1 sollte nicht verwendet werden, andere Digestfunktionen mit höchstens 160 Bit sind verboten.

Die alten Außenfelder können täuschen. Bei PBMAC1 müssen macSalt und iterations auf der äußeren PKCS-#12-Ebene ignoriert werden. Für Rückwärtskompatibilität sollen sie dennoch nicht leer beziehungsweise null sein. Liest ein Prüfwerkzeug nur diese äußere Iteration, kann es eine Zahl bestätigen, die für die tatsächliche Ableitung bedeutungslos war.

Die Altleser-Regel zieht die zweite Grenze. Die neue Syntax soll es alten Anwendungen ermöglichen, Schlüsselmaterial weiterhin zu entschlüsseln, obwohl sie den neuen Integritätsschutz nicht verstehen — sofern sie einen MAC-Prüffehler ignorieren können. Das erleichtert schrittweise Einführung. Es zeigt zugleich, dass Entschlüsselung kein Integritätsnachweis ist. Der RFC benennt keine konkrete Anwendung mit diesem Verhalten.

Bei der Passwortkodierung korrigierte laufende Implementierung den Text. RFC 9579 verlangte eine nullterminierte BMPString. Das verifizierte Erratum 7974 stellte fest, dass die Testvektoren tatsächlich mit UTF-8 erzeugt wurden. RFC 9879 schreibt deshalb UTF-8 ohne Nullterminator und ohne BOM vor. Für die Reproduzierbarkeit zählen die KDF-Bytes, nicht bloß die sichtbaren Zeichen.

Die Testvektoren enthalten gültige SHA-256- und SHA-512-Kombinationen sowie ungültige Beispiele für falsche Iteration, falsches Salt und fehlende Schlüssellänge. Wer sie besteht, beherrscht diese Berechnungen. Daraus folgen weder starke Produktionspasswörter noch geschlossene Fehlerpfade, vollständige Flottenabdeckung oder korrekte Verwahrung.

RFC 9879 warnt selbst vor KDF-Ausgaben bis hinunter zu einem Oktett. Die KDF-Parameter sind nicht kryptographisch geschützt; ein winziger Schlüssel erleichtert Brute-Force gegen den HMAC. Unter 20 Oktetten wird Ablehnung empfohlen, und schwache Parameter dürfen lokal verworfen werden. Diese Erlaubnis ist noch keine Umsetzung.

RFC 8018 beschreibt die grundsätzliche Grenze passwortbasierter Verfahren: Offline-Suche bleibt möglich. Salt und Iterationen verteuern Versuche, erzeugen aber keine fehlende Passwortentropie. Scrypt will durch Speicherkosten den Vorteil paralleler Hardware mindern; in RFC 9879 ist es optional. Derselbe PBMAC1-Name kann daher sehr unterschiedliche Risikoprofile tragen.

Die Beweiskette lautet: Container empfangen; Erzeuger und Leser bestimmen; OID und wirksame Parameter lesen; lokale Parameterpolitik anwenden; Passwortbytes bilden; MAC prüfen; Entschlüsselung gesondert bewerten; Schlüsselverwendung erlauben oder ablehnen; Verwahrungsziel erfassen; Reexport beobachten. Ein späterer Erfolg darf eine frühere Lücke nicht überschreiben.

Quellen