Primäre Domain
Sicherheit
Innerhalb der Facette Primäre Domain bündelt Sicherheit die Berichterstattung nach primärem Themenbereich, sodass Leser einen fokussierten Bereich der Internetinfrastruktur, Governance, Konnektivitätsmärkte oder des digitalen Kapitals verfolgen können. Die Seite führt verwandte Artikel, öffentliche Belege, Institutionen, Unternehmen, Personen, regionale Verflechtungen, operative Abhängigkeiten und Marktkontext zusammen, die sonst über verschiedene Kategorieseiten verstreut wären. Sie erläutert den Themenbereich, die wahrscheinliche Akteursgruppe, den Markt- oder Governance-Kontext und das Quellenmaterial, das Leser beim Vergleich von Signalen heranziehen sollten. Betreiber, Analysten und mit Governance befasste Leser können erkennen, wie derselbe Themenbereich in Ereignissen, Profilen, Marktveränderungen, Belegen aus öffentlichen Quellen, regionalen Abhängigkeiten und langfristigen Infrastrukturentscheidungen immer wieder auftaucht.
Fallakte
Der Antrag war signiert. Der andere private Schlüssel blieb nur behauptet: RFC 9883
Eine gültige Signatur kann belegen, wer eine Aussage abgegeben hat, ohne den Inhalt der Aussage technisch zu beweisen. RFC 9883 baut genau auf dieser Trennung auf: Ein bereits zertifizierter Signaturschlüssel zeichnet den Antrag; der Besitz eines zweiten Schlüssels bleibt eine…
Fallakte
RFC 9882 verlangte SHA-512 im Feld – nicht immer im Rechenweg
Ein korrekt befülltes CMS-Feld ist noch kein Nachweis dafür, dass sein Wert die kryptografische Berechnung gesteuert hat. RFC 9882 macht diese Trennung ausdrücklich: Auf einem ML-DSA-Pfad muss SHA-512 aus Interoperabilitätsgründen genannt werden, während die prüfende Seite den…
Fallakte
RFC 9879 modernisiert den MAC. Der Altleser bleibt im Spiel
In einer PKCS-#12-Datei können zwei Iterationswerte stehen, von denen nur einer die neue Integritätsprüfung steuert. Ein Dashboard kann den anderen grün markieren und trotzdem das falsche Urteil liefern. RFC 9879 verbessert den Mechanismus — und zwingt Betreiber gerade deshalb…
Fallakte
Das Paket enthielt zwei Formen, aber noch nicht einen Schlüssel: RFC 9935
Ein ML-KEM-Privatschlüsselpaket kann Seed und expandierten Entkapselungsschlüssel gemeinsam tragen. Das erleichtert den Austausch, beweist jedoch keine Identität: Erst Neuberechnung und Vergleich verbinden beide Werte zu einem überprüften Schlüssel.
Fallakte
Die OID benannte das Schlüsselpakt. Sie erlaubte seine Nutzung nicht: RFC 9939
Das CMS-Objekt trug eine bekannte Kennung, und der Parser erkannte die PKCS-#8-Struktur. Das ist eine überprüfbare Aussage über ein Format. Es ist keine Aussage darüber, wer den privaten Schlüssel verwahrt, entschlüsseln kann oder ihn einsetzen darf.
Fallakte
Die Ressource nannte einen Autorisierungsserver. Sie erteilte kein Recht: Die Entdeckungsgrenze von RFC 9728
Eine Ressource kann präzise erklären, wo ein Client weiter suchen soll, ohne diesem Client irgendeinen Zugriff zu gestatten. RFC 9728 standardisiert diese Orientierung. Die Metadaten sind ein Koordinationssignal, kein Zugriffstoken, kein Urteil des Resource Servers und kein Beleg…
Fallakte
Das Autorisierungsgespräch war noch offen. Es war kein API-Recht: die Fortsetzungsgrenze von GNAP
Ein Client kann ein Autorisierungsgespräch fortsetzen dürfen, ohne die angefragte API aufrufen zu dürfen. RFC 9635 trennt beides: Ein Fortsetzungsnachweis bringt genau einen Antrag beim Autorisierungsserver weiter; ein Recht auf eine Ressource entsteht, wenn überhaupt, später und…

IETF
Sean Turner und der private Schlüsselnachweis, der kein Zertifikat genehmigte
Ein signierter Zertifikatsantrag ist kein Blankoscheck. Seine Signatur schützt den beantragten Schlüssel und Inhalt; ob Identität, Name, Erweiterungen und Ausstellerregeln eine Ausstellung erlauben, entscheiden andere Nachweise und andere Stellen.

IETF
Panos Kampanakis und die SSH-Sitzung mit drei Sicherheitsnachweisen
Eine SSH-Verbindung kann einen ML-KEM-Hybridaustausch nutzen, den Server mit einem davon getrennten Hostschlüssel erkennen und den Benutzer anschließend mit einer weiteren Identität zulassen. Der Kanal ist derselbe; die Nachweise sind es nicht.

IETF
Bas Westerbaan und der hybride TLS-Handshake, der das Zertifikat nicht quantensicher machte
Eine gute Prüfung beginnt nicht mit der Frage, ob ein Dienst „postquantenfähig“ ist. Sie beginnt mit der Frage, welche Eigenschaft sich nachweislich geändert hat. Bei RFC 10024 lautet die Antwort: die Schlüsselvereinbarung in TLS 1.3. Die Zertifikatsauthentifizierung steht in…

IETF
Daniel Fett: Die MFA prüfte den Nutzer, nicht den QR-Kontext
Der Nutzer landet auf der echten Seite, verwendet die echten Faktoren und bestätigt eine echte Anfrage. Trotzdem erhält der Angreifer die Sitzung. Nicht die Identitätsprüfung war gefälscht, sondern die Geschichte darüber, welches Gerät diese Prüfung ausgelöst hatte.
Fallakte
Das Zertifikat prüfte den Partner. Der externe PSK brauchte trotzdem einen Verwahrer: RFC 9973 und TLS-Zuständigkeit
Eine gelungene TLS-Verbindung ist ein belastbarer technischer Befund. Sie ist keine Eigentumsurkunde für jeden Schlüssel, der an ihr beteiligt war. Gerade bei werksprovisionierten Geräten kann ein Zertifikat sauber geprüft werden, während der zusätzliche Geheimwert noch in…
Fallakte
Das Cookie passte zur Anfrage. Es bewies keine Entscheidung: RFC 10025 und umgebende Autorität
In einem Prüfbericht wirkt der Satz „gültige Sitzung“ beruhigend. Er kann jedoch nur bedeuten, dass ein Browser einen gespeicherten Wert gesendet und der Server ihn einer noch bekannten Sitzung zugeordnet hat. Daraus folgt weder eine aktuelle Willensentscheidung noch eine…
Fallakte
Der Chiffretext erreichte den Schlüssel. Er nannte keinen Absender: RFC 9180 und die fehlende Autorität des HPKE-Basismodus
Dass ein HPKE-Chiffretext mit dem richtigen privaten Schlüssel geöffnet werden kann, ist ein überprüfbares Kryptographieereignis. Es benennt weder den Absender noch die Gültigkeit eines Auftrags und auch nicht die Befugnis, aus dem Klartext eine Handlung zu machen. Genau diese…
Fallakte
Ein Fragment war angekommen. Es war noch keine vollständige Handlungsanweisung: RFC 9993 und haptische Ausführung
Ein RTP-Empfänger kann den Anfang einer fragmentierten MIHS-Einheit sehen, ihren Unit Type erkennen und ihre Priorität lesen. Fehlt später ein Fragment, hat er keine vollständige Einheit. Wer daraus dennoch eine teilweise Kraft-, Temperatur- oder Vibrationsausgabe ableitet…
Fallakte
Der Bericht sollte aufklären. Ohne Grenzen konnte er den Angriff verstärken: RFC 9991 und DMARC-Offenlegungsbefugnis
Ein Angreifer verschickt massenhaft Nachrichten im Namen eines fremden Domains, lässt SPF und DKIM scheitern und wartet, bis empfangende Systeme detaillierte Berichte an das Opfer oder dessen Dienstleister senden. Der Bericht ist als Diagnose gedacht; ohne Ziel-, Mengen- und…

IETF
Russ Housley und die MAC-Adresse, die ein Zertifikat benennen, aber nicht eindeutig machen konnte
Sechs oder acht Oktette lassen sich sauber signieren. Ob sie heute an der erwarteten Schnittstelle erscheinen und dort eine Handlung erlauben, bleibt dennoch eine Frage des laufenden Netzes.

IETF
Aaron Parecki und der BFF, der Tokendiebstahl stoppt, aber kein Client-Hijacking
Ein Backend for Frontend kann OAuth-Token vollständig aus dem JavaScript entfernen und trotzdem eine unerwünschte Aktion aus der laufenden Browsersitzung weiterleiten. RFC 10017 beschreibt darin keinen Widerspruch, sondern zwei getrennte Sicherheitsfragen: Kann der Angreifer die…

IETF
Hannes Tschofenig und die Authority-ID, die das Token nicht signiert hatte
Ein gültiger Komponentenschlüssel und eine gültige EAT-Signatur können zu verschiedenen Verantwortlichen gehören. RFC 10013 trennt diese Aussagen ausdrücklich. Wer beide unter „vertrauenswürdige Authority“ zusammenfasst, verliert nicht Kryptografie, sondern Zurechnung.
Fallakte
Der Umschlag benennt den Nachweis, bindet aber nicht das Gerät: RFC 9999 und die Autorität in einer Attestation Collection
CPU, SmartNIC und GPU können drei korrekt signierte Zustandsnachweise liefern. In derselben Collection zu liegen beweist trotzdem nicht, dass sie zu demselben Server und derselben Prüfung gehören. RFC 9999 schafft einen transportablen Rahmen für RATS-Nachrichten. Wer die…
