Zum Hauptinhalt springen

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…

3. Sept. 2026

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…

3. Sept. 2026

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…

2. Sept. 2026

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.

2. Sept. 2026

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.

1. Sept. 2026

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…

1. Sept. 2026

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…

1. Sept. 2026
Sean Turner und der private Schlüsselnachweis, der kein Zertifikat genehmigte

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.

1. Sept. 2026
Panos Kampanakis und die SSH-Sitzung mit drei Sicherheitsnachweisen

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.

31. Aug. 2026
Bas Westerbaan und der hybride TLS-Handshake, der das Zertifikat nicht quantensicher machte

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…

31. Aug. 2026
Daniel Fett: Die MFA prüfte den Nutzer, nicht den QR-Kontext

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.

31. Aug. 2026

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…

31. Aug. 2026

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…

31. Aug. 2026

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…

31. Aug. 2026

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…

31. Aug. 2026

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…

31. Aug. 2026
Russ Housley und die MAC-Adresse, die ein Zertifikat benennen, aber nicht eindeutig machen konnte

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.

31. Aug. 2026
Aaron Parecki und der BFF, der Tokendiebstahl stoppt, aber kein Client-Hijacking

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…

31. Aug. 2026
Hannes Tschofenig und die Authority-ID, die das Token nicht signiert hatte

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.

31. Aug. 2026

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…

30. Aug. 2026