Zusammenfassung

  • RFC 5208 PrivateKeyInfo und RFC 5958 OneAsymmetricKey strukturieren privates Schlüsselmaterial. Die unverschlüsselte Form belegt weder Vertraulichkeit noch Zugriffskontrolle, Hardwareverwahrung oder sichere Löschung.
  • Entschlüsselung, mathematische Prüfung, Public-Key-Zuordnung, Import, Berechtigung, Operation und Anwendungsannahme sind getrennte Quittungen. Parser-Erfolg ersetzt keine davon.

Eine Syntax mit begrenzter Zuständigkeit

PKCS #8 schafft einen gemeinsamen äußeren Rahmen für algorithmusspezifische Schlüssel. RFC 5208 definiert Version, Algorithmuskennung, einen privaten OCTET STRING und optionale Attribute. Die Registrierung des Algorithmus bestimmt die Bedeutung der inneren Bytes.

Der Vertrag endet an dieser Grenze. Er sagt nicht, wo die Bytes entstanden, ob sie in einer temporären Datei lagen, wer sie kopierte oder welche Sicherung sie behielt. Ein gültiges ASN.1-Objekt ist ein Darstellungsbeleg, keine Verwahrungskette.

RFC 5958 ersetzt RFC 5208, nennt die Struktur OneAsymmetricKey, ergänzt optional den öffentlichen Schlüssel und definiert Pakete für mehrere Schlüssel. Zugleich erklärt der Text die Paketinhalte für ungeschützt. Ein CMS-Schutztyp kann hinzukommen. Schutz ist damit ausdrücklich eine weitere Handlung.

Der Header trennt Klartext und Schutz

RFC 7468 verwendet PRIVATE KEY für die unverschlüsselte Form und ENCRYPTED PRIVATE KEY für EncryptedPrivateKeyInfo. Letzteres enthält Verschlüsselungskennung und Ciphertext. Erst wird die Schlüsselinformation codiert, danach werden die Bytes verschlüsselt.

Ein Audit muss beide Schritte erhalten: Strukturprüfung und Entschlüsselung mit konkretem KDF, Salt, Aufwand, Cipher, Integritätsresultat und Ziel des Klartexts. Der Status importiert verrät nicht, wann Schutz entfernt wurde.

RFC 8018 weist darauf hin, dass Passwörter häufig aus kleinem Raum stammen. Eine OID bescheinigt daher keine praktische Stärke. Parameter, Versuchslimits und Implementierung sind eigene Tatsachen.

Derselbe Container, andere Herrschaft

Ein PKCS-#8-Objekt kann Speicher, Platte, Ticketsystem, Software-Keystore, Cloud-KMS und HSM durchlaufen. Die Syntax bleibt gleich; Kontrolle, Kopien und Rechtsraum ändern sich.

.p8, application/pkcs8 und korrekte PEM-Grenzen belegen keine HSM-Residency. Auch eine HSM-Objektkennung schließt frühere Klartextkopien, Exportierbarkeit oder ungleich geschützte Backups nicht aus.

Die Verwahrungsquittung verbindet Quellhash, Transport, Importeur, Slot, Objektkennung, Exportregel, Repliken, Nutzungsaudit und Löschung temporärer Dateien. Diese Informationen entstehen im Betrieb, nicht im ASN.1-Parser.

Formal richtig kann sachlich falsch sein

RFC 5958 kann einen öffentlichen Schlüssel mitführen; manche inneren Formate enthalten öffentliche Komponenten. Trotzdem muss das System den Public Key ableiten oder prüfen und mit Zertifikat, Konto oder Vertrauensdatensatz vergleichen. Nähe im Paket ersetzt keine unabhängige Bindung.

RFC 8479 speichert Eingaben, mit denen sich bestimmte RSA- oder DSA-Parameter später validieren lassen. Gespeicherte Eingaben sind kein Nachweis, dass die Prüfung lief oder bestand.

Nach Zuordnung folgen Berechtigung und Wirkung. Eine korrekte Taste kann durch Policy gesperrt sein. Eine erzeugte Signatur kann wegen Nachricht, Kontext, Zeit, Kette oder Algorithmusregel scheitern. Jede Schicht braucht ihren eigenen Status.

Eine moderne Referenz migriert keine Werkzeuge

RFC 5208 erschien 2008 als Informational. RFC 5958 ersetzte sie 2010 auf dem Standards Track und ergänzte Namen, Public-Key-Feld, Versionsregel und CMS-Typ. Abwärtskompatibilität lässt jedoch alte v1-Formen weiter zu.

Ein Inventareintrag RFC 5958 beweist deshalb keine einheitliche Unterstützung in Export, Import, Backup und Restore. Beobachtete Bytes, Versions- und Negativtests, Roundtrips und Wiederherstellung liefern den Beleg. Dokumentation ist Absicht; laufender Code ist Verhalten.

Die Belegkette

Getrennt erfassen: Ursprungsbytes; Textdecodierung; ASN.1 und Parameter; Klartext/Schutztyp; KDF und Cipher; Entschlüsselung/Integrität; mathematische Prüfung; Public-Key-Zuordnung; Ziel und Exportregel; Berechtigung; Operation; Verifikation; Anwendungsannahme; Widerruf und Löschung.

PRIVATE KEY benennt Darstellung. Entschlüsselung belegt Klartextzugriff. Public-Key-Vergleich belegt Zuordnung. HSM-Log belegt eine Operation in einer Grenze. Signaturprüfung belegt ein Ergebnis für eine Nachricht. Keiner dieser Belege darf den nächsten erben.

Führung sollte die gemeinsame Spezifikation klein halten, lokale Verwahrung explizit entscheiden und verifizierbare Resultate laufender Systeme als Primärbeleg behandeln. Herkunft erklärt den Weg, nicht die Wirkung.

Quellen

  1. RFC-5208-Information
  2. RFC 5208 HTML
  3. RFC 5208 Text
  4. IETF Datatracker: RFC 5208
  5. RFC-5208-Historie
  6. RFC-5208-Referenzen
  7. RFC-5208-Errata
  8. RFC-5958-Information
  9. RFC 5958 HTML
  10. RFC 5958 Text
  11. IETF Datatracker: RFC 5958
  12. RFC-5958-Historie
  13. RFC-5958-Referenzen
  14. RFC-5958-Errata
  15. RFC 8018 — passwortbasierte Kryptografie
  16. RFC 8351 — EncryptedPrivateKeyInfo-Medientyp
  17. RFC 7468 — Textcodierungen
  18. RFC 8479 — Validierungsparameter in PKCS #8
  19. RFC 5915 — EC-Private-Key-Struktur
  20. Heng Lu — Realitätsebenen und symbolische Macht
  21. Heng Lu — minimale Anfangsspezifikation
  22. Heng Lu — Vorrang laufenden Codes