Zusammenfassung

  • Die IETF hat LAMPS neu beauftragt, PKIX und S/MIME zu pflegen und hybride Schlüsselvereinbarung, doppelte Signaturen sowie schlankere Zertifikatsverarbeitung zu bearbeiten.
  • Eine Charta schafft Agendaautorität; sie nimmt keinen Entwurf an, veröffentlicht keinen RFC, liefert keinen Code und installiert keinen Vertrauensanker.

Die Selbstsignatur ist nicht die Vertrauensentscheidung

Die Charta nennt ein unsigniertes X.509-Zertifikat als möglichen Träger von Subjektinformationen eines Vertrauensankers. Post-Quanten-Signaturen können groß sein. Erhält ein Gerät den Anker bereits über einen geschützten Konfigurationsweg, kann eine Selbstsignatur unnötig Bandbreite und Rechenleistung beanspruchen.

Eine Wurzel wird aber nicht glaubwürdig, weil sie sich selbst unterschreibt. RFC 5280 behandelt Vertrauensankerinformationen als Eingabe der Pfadvalidierung, die über ein vertrauenswürdiges Verfahren außerhalb des Pfades erlangt wird. RFC 5914 definiert dafür mit TrustAnchorInfo eine eigene Darstellung.

Die entscheidenden Belege liegen beim Installationsvorgang: Wer genehmigte den Anker, wie wurde der Kanal authentisiert, welcher Name, Schlüssel und welche Beschränkungen wurden fixiert, welcher alte Anker wurde ersetzt und wie funktioniert die Rücknahme? Ein kleinerer Behälter ist vertretbar, solange diese Kette vollständig bleibt.

Bislang ist dies ein zugelassener Arbeitsbereich, kein standardisierter Mechanismus und kein beobachteter Rollout.

Am 21. August änderte sich das institutionelle Mandat

Am 21. August 2026 um 20:40 UTC kündigte die IETF die Neuchartierung der Limited Additional Mechanisms for PKIX and SMIME an. Datatracker führt LAMPS als aktiv und Revision 08 als genehmigte Charta.

Das Mandat verbindet Pflege und Übergang. Die Gruppe kann aus den beendeten PKIX- und S/MIME-Gruppen stammende Mechanismen wie CMP, CMC, EST, S/MIME und PKIX betreuen. Zugleich soll sie diese Umgebungen auf Verfahren vorbereiten, die RSA, Diffie-Hellman, ECDSA, ECDH und EdDSA ersetzen oder begleiten.

Der Auftrag ist nicht grenzenlos. Neue Arbeit soll eine bekannte, an realer Einführung interessierte Gruppe und mindestens einen hinreichend beschriebenen Ansatz besitzen. Das öffnet die Tür zur Prüfung; es bestätigt weder Sicherheit noch Konsens. Ein Vorschlag kann in der Analyse scheitern, Betreiber können über Fehlerpolitik streiten, und die Gruppe kann ihn ablehnen.

NIST-Standards lösen die Einbettung nicht

NIST veröffentlichte FIPS 203 für ML-KEM, FIPS 204 für ML-DSA und FIPS 205 für SLH-DSA. Auch vom CFRG bewertete Verfahren kommen laut Charta infrage.

Diese Standards beantworten Algorithmusfragen, aber nicht sämtliche Fragen in PKIX-Zertifikaten, CMS-Objekten, Registrierungsprotokollen oder S/MIME-Programmen. Nötig sind Kodierungen, Parameter, Profile, Validierungs- und Fehlerregeln, Testvektoren und Implementierungen.

Die Spezifikationen sollen Objektkennungen von NIST oder IANA nutzen. Eine OID macht eine Konstruktion benennbar; sie installiert keine Bibliothek und ändert keine Annahmerichtlinie.

„PQC-bereit“ muss deshalb in Belege zerlegt werden: Algorithmusstandard, Protokollprofil, Kennung, Dokumentstatus, Code, Konfiguration, erzeugtes Objekt, akzeptiertes Objekt und beobachteter Dienst.

Zwei Geheimnisse brauchen eine gemeinsame Ableitung

Hybride Schlüsselvereinbarung kombiniert Geheimnisse traditioneller Verfahren mit Ergebnissen geeigneter Post-Quanten-Verfahren. LAMPS soll Formate, Kennungen, Registrierung und Betrieb beschreiben.

Bloßes Aneinanderhängen reicht nicht. Beide Seiten brauchen dieselbe eindeutige Kodierung und Ableitungsfunktion. Die Charta nennt HKDF, eine Methode aus NIST SP 800-56C oder eine vom CFRG bewertete Funktion. RFC 5869 trennt Extraktion und Expansion; Salt, Kontext und Länge gehören daher zur Vereinbarung.

Auch das Versagensmodell muss feststehen: Was bleibt geschützt, wenn ein Bestandteil gebrochen, falsch implementiert, ersetzt oder ausgelassen wird? Der Composite-KEM-Text ist weiterhin ein aktiver Internet-Draft. Er belegt Arbeit, nicht endgültige Interoperabilität.

Doppelte Signaturen erzeugen mehrere Annahmezustände

Die Charta umfasst außerdem Kombinationen traditioneller und post-quantenfester Signaturen. Auch das Dokument zu Composite Signatures ist ein aktiver Entwurf.

Prüfer müssen wissen, ob alle Bestandteile gelten müssen, ob Übergangsregeln einen akzeptieren, wie Kennungen Schlüssel und Signaturen binden und wie eine Bibliothek mit einem unbekannten inneren Teil umgeht. Eine lockere Regel kann den Übergangsschutz auf alleinige traditionelle Autorität herabstufen.

Zertifizierungsstelle, CMS-Erzeuger, Mailprogramm, Kryptobibliothek und Anwendung können unterschiedliche Fähigkeiten besitzen. Der reale Dienst liegt in ihrer Schnittmenge. Neue Inhalte im Zertifikat beweisen nicht, dass Vermittler sie erhalten oder Empfänger sie akzeptieren.

Ein Termin ist eine Koordinationsuhr

Die Ankündigung nennt Oktober 2026 für Composite Signatures in PKIX und CMS, November für Composite KEM und Dezember für CAA Security. Diese Meilensteine zeigen Reihenfolge und Verzug. Sie garantieren weder IETF Last Call und IESG-Zustimmung noch RFC, Softwareversion oder Flotteneinführung.

Verspätung kann Komplexität oder fehlende Prüfung anzeigen, ohne den Algorithmus zu widerlegen. Termintreue beweist wiederum weder tragbare Objektgrößen noch einen sicheren Rückweg im Vertrauensspeicher.

Institutioneller Fortschritt und Betriebsbelege gehören in getrennte Berichtsreihen.

Die Charta verwaltet keine fremden Systeme

Eine Charta gibt Dokumenten ein Zuhause, zieht Prüfer an und legitimiert ein Kompatibilitätsproblem. Sie macht LAMPS nicht zur Zertifizierungsstelle, Algorithmusaufsicht oder Fernverwaltung lokaler Vertrauensspeicher.

NIST verantwortet seine Standards, zuständige Stellen vergeben Kennungen, der IETF-Prozess bestimmt Dokumentstatus, Anbieter liefern Code und Betreiber konfigurieren Annahme. Ein RFC-konform dargestellter Anker bleibt eine lokale Ermächtigung.

Für jedes Vorhaben sollten Chartarevision, Problem, Einführungskreis, Entwurfsversion, Annahme, Einwände, Konsens, Sicherheitsanalyse, Abhängigkeiten, Kennungen, Tests, unabhängige Implementierungen, Registrierung, Prüferkonfiguration, Rückfall und gemessener Austausch erhalten bleiben.

Sources