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
Die Challenge überwand die Verzögerung, die Autorität nicht: RFC 9891
RFC 9891 bringt eine ACME-Prüfung in verzögerungstolerante Netze. Ihr Erfolg belegt Kontrolle unter einer konkreten Richtlinie, aber weder Namensrecht noch legitime Routen oder die spätere Nutzung des Zertifikats.
IETF
Rich Salz und die TLS-1.3-Anforderung, die keine Betriebsquittung war
Ein Standard kann eine strenge Regel setzen, ohne damit selbst den Nachweis zu erzeugen, dass sie in jedem laufenden System erfüllt ist. Das ist keine Schwäche des Standards. Es verhindert, dass eine richtige Protokollentscheidung als unbeobachtete Betriebsbehauptung ausgegeben…
IETF
Nancy Cam-Winget und das SCIM-Ereignis, das keine Abgleichquittung war
Wenn eine Identitätsdomäne einer anderen eine Änderung meldet, ist damit nicht erwiesen, dass die empfangende Domäne sie bereits übernommen hat. Sie muss die Ressource noch zuordnen, Schemata abgleichen, gegebenenfalls rückfragen, eine lokale Regel anwenden und ihren eigenen…
IETF
Chris Wendt und die signierte Antwort, die das Medium nicht authentifizierte
Eine erreichte SIP-Antwort kann eine wichtige Beobachtung sein. Sie ist aber weder ein Beweis über den späteren Gesprächsstrom noch eine fertige Handlungsanweisung. RFC 9970, an dem Chris Wendt mitgeschrieben hat, ist gerade dann nützlich, wenn diese Trennung in Produkt, Betrieb…
IETF
Michael Prorock und der Algorithmusbezeichner, der keine Vertrauenspolitik auswählte
Ein Algorithmusbezeichner kann einem System sagen, wie es einen Schlüssel und eine Signatur technisch behandeln soll. Er kann nicht sagen, ob der Schlüssel aus einem akzeptierten Kanal stammt, welchem Aussteller zu trauen ist oder welche Wirkung eine gültige Signatur haben darf.…
Fallakte
Das Token kam vor dem Anruf. Die Verifizierung musste warten: RFC 9888
Die signierte Identitätsaussage lag beim Zielanbieter, bevor der zugehörige Anruf sein Netz erreicht hatte. RFC 9888 gibt STIR einen Nebenweg durch Telefonnetze, die das Token nicht in SIP transportieren. Zwei getrennte Eingänge werden dadurch jedoch nicht automatisch zu einem…
IETF
Dan Harkins und der Bootstrap Key, der seine eigene Verwahrung nicht belegen konnte
Dass ein Gerät einen privaten Schlüssel beherrscht, sagt noch nicht, wie sein öffentlicher Schlüssel zum Server gelangte, wer diese Zuordnung geprüft hat oder wer über den Zugang entscheidet. RFC 9966 hält diese Lücke offen. Sie liefert einen begrenzten TLS-Nachweis, keine…
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…