Thema
Digitale Identität und Nachweise
Innerhalb der Facette Thema verbindet die Themenanalyse Digitale Identität und Nachweise Artikel, die ein gemeinsames Thema, einen Signalfokus oder ein Monitoring-Thema teilen. Die Seite bietet den Lesern einen umfassenderen Zugang zu verwandter Berichterstattung, Quellenbelegen, Marktakteuren und Infrastrukturfolgen – mit ausreichend Kontext, um zu verstehen, warum das Thema für Unternehmensaktivitäten, Governance-Entscheidungen, regionale Risikoexposition und operationelle Risiken relevant ist. Leser können wiederkehrende Signale, betroffene Organisationen, öffentliche Belege, Marktkontext, Servicekontinuität, Beschaffung, Wettbewerb, Compliance und strategische Planungsfragen hinter dem Thema vergleichen, statt bei einer dünnen Liste passender Artikel stehenzubleiben. Es erklärt, was das Thema abdeckt, welche Infrastrukturakteure oder -politiken beteiligt sind, welche Belege die Berichterstattung stützen und warum das Thema für Betreiber, Kunden, Investoren und politisch interessierte Leser von Bedeutung sein kann.
IETF
Der Beweis ist gültig. Wer trägt nun die Verantwortung für das Label?
Key Transparency kann eine konsistente Verzeichnisantwort beweisen. Sie legt damit noch nicht fest, wer handeln durfte, wer sich auf die Antwort verließ und wer später weiter prüfen muss. Genau diese Rollenlücke hat die jüngste IETF-Prüfung offengelegt.
Fallakte
Metadaten versprachen den Algorithmus. Erst die Prüferspur zeigte den verwendeten Schlüssel: RFC 9701
Ein Authorization Server kann unterstützte Signatur- und Verschlüsselungsalgorithmen veröffentlichen. Das ist eine Fähigkeitserklärung, kein Ausführungsnachweis. Für eine konkrete Zugriffsentscheidung zählen der tatsächlich gewählte Algorithmus, der an den Issuer gebundene…
IETF
Das Zertifikat schrumpfte. Die Vertrauensentscheidung nicht
Die Analyse-Zusammenfassung zu Das Zertifikat schrumpfte. Die Vertrauensentscheidung nicht erläutert die Entwicklung, die öffentlich zugänglichen Belege, die beteiligten Organisationen, den regionalen Kontext, die Marktexposition und die möglichen Infrastrukturauswirkungen. Der…
IETF
Das Zertifikat galt für die Nummer. Über den Anruf war noch nicht entschieden
Ein dynamischer Nummernbestand passt schlecht zu einer pauschalen Zertifikatsampel. Das neue STIR-OCSP-Profil fragt deshalb genauer: Gehört diese eine Rufnummer noch zum Geltungsbereich? Die Antwort schließt eine Beweislücke, ohne aus Zertifikatsstatus ein Urteil über Menschen…
Fallakte
Der Parser meldete SHA3-Unterstützung. Die empfangenen Parameter waren schon verloren
Die Analyse-Zusammenfassung zu Der Parser meldete SHA3-Unterstützung. Die empfangenen Parameter waren schon verloren erläutert die Entwicklung, die öffentlich zugänglichen Belege, die beteiligten Organisationen, den regionalen Kontext, die Marktexposition und die möglichen…
IETF
Kein Normenkonflikt gefunden. Der Fabrikschlüssel hat trotzdem keine Sicherheitsnote
Der IESG-Konfliktcheck sieht kein Hindernis für die Veröffentlichung einer IRTF-Taxonomie zu herstellerseitig eingebrachten Schlüsseln und Vertrauensankern. Damit ist eine Verfahrensfrage geklärt. Die fünf Fertigungsmethoden sind weder bewertet noch ist die Geheimhaltung eines…
IETF
Ein Empfänger entschlüsselte das JWE. Die Empfängerregel war damit noch nicht erfüllt
Ein JWE für mehrere Empfänger kann Klartext liefern, sobald ein einziger Empfängerpfad funktioniert. Das neue HPKE-Profil macht diesen Erfolg prüfbar. Ob genau dieser Empfänger genügen durfte, alle Pflichtempfänger erreichbar waren und jeder Algorithmus zugelassen war, bleibt…
IETF
SATP verlangt Checkpoints, standardisiert aber noch keinen Neustartpunkt
Ein Ersatz-Gateway kann nur dann sicher übernehmen, wenn es nicht bloß das Protokollprotokoll, sondern auch den dauerhaften Zustand seines Vorgängers versteht. SATP beschreibt diese Möglichkeit, verschiebt die gemeinsame Semantik dafür jedoch auf spätere Arbeit.
Fallakte
Der Eintrag landete im Standardkalender. Erfolgreich hieß noch nicht: am richtigen Ort
RFC 9671 kann neue Kalenderobjekte ohne `:calendarid` im vom System bestimmten Standardkalender ablegen. Das ist interoperabel, aber kein Nachweis dafür, dass der organisatorisch richtige Kalender getroffen wurde.
Fallakte
Zwei Administratoren speicherten dieselbe Freigabekarte. Einer löschte unbemerkt die Entscheidung des anderen
RFC 9670 macht `shareWith` zu einer gemeinsamen JMAP-Oberfläche für objektbezogene Freigaben. Gerade weil diese Oberfläche wie eine vollständige Karte wirkt, braucht jede Änderung einen State-Beleg: Ein erfolgreicher Save darf keine verlorene konkurrierende…
Gesellschaft für Nummernressourcen
Passkey statt App: Wie die RIPE NCC die Zwei-Faktor-Authentifizierung für Registry-Konten umstellt
Ein Abschnittsvermerk in der Support-Dokumentation der RIPE NCC mit dem Titel „Setting up 2FA with Passkey“ ist in einem Verzeichnis fälschlich als Institution aus Taiwan registriert worden. Dahinter steht kein taiwanisches Unternehmen, sondern ein dokumentierter Einrichtungsweg…
IETF
Das Zertifikat ist da. Die Auslieferung ist noch nicht bewiesen
RFC 9538 gibt einem nachgelagerten CDN einen geregelten Weg zum eigenen Zertifikatsschlüssel, ohne den langlebigen privaten Schlüssel des vorgelagerten CDN zu teilen. DNS-Umschaltung, vollständige Edge-Aktivierung, TLS-Auswahl und richtige Inhalte bleiben eigene Nachweise.
Fallakte
RFC 9646: Der HTTP-400-Auftrag war noch keine Identitätsentscheidung
Das Kontrollsystem feierte bereits den Besitznachweis: Der CSR war korrekt signiert. Doch damit war nur geklärt, dass jemand den passenden privaten Schlüssel kontrollierte. Wer den Antrag erzeugt hatte, ob der Bootstrap-Server vertrauenswürdig war, ob die CA zustimmte und ob das…
Fallakte
RFC 9645: Die Konfiguration bestand die Prüfung, doch der verwendete TLS-Identitätspfad blieb offen
Ein freigegebener Konfigurationsstand kann revisionssicher sein und trotzdem die entscheidende forensische Frage nicht beantworten: Wurde die Verbindung mit einem Zertifikat, einem Raw Public Key, einem TLS-1.2-PSK oder einem externen TLS-1.3-PSK authentisiert? Bei einer…
Fallakte
RFC 9644: Die Beweiskette hinter einer SSH-Algorithmuswahl
Im Audit liegt die freigegebene Richtlinie vor. Das Gerät hat sie angenommen, und die unterstützten Algorithmen wurden inventarisiert. Dann kommt die einfache Frage: Welcher Algorithmus lief in der entscheidenden Sitzung tatsächlich? Keines der drei Dokumente enthält die Antwort.…
Fallakte
Die Konfiguration war da. Die Schlüsselgewalt nicht: RFC 9642
RFC 9642 beschreibt zentrale und eingebettete Schlüssel, Zertifikate, verschlüsselte Werte und eingebaute Schlüssel in einem gemeinsamen YANG-Modell. Ein erfolgreicher Import belegt noch nicht, dass der Zielserver den KEK nutzen, der Verbraucher das richtige Objekt wählen oder…
Fallakte
NACM verweigerte den Schreibzugriff. Der Anker war dennoch nicht vollständig geschützt: RFC 9641
RFC 9641 versieht Truststore-Knoten mit `nacm:default-deny-write`. Das begrenzt Änderungen über die Managementschnittstelle, beweist aber weder die Integrität der gespeicherten Daten noch die Berechtigung eines privilegierten lokalen Prozesses. Ein belastbarer Vertrauensnachweis…
Fallakte
Eine gültige digitale Bescheinigung braucht trotzdem Verantwortliche
Das neue W3C-Arbeitspapier zu verifizierbaren Nachweisen beschreibt Gefahren entlang des gesamten Weges vom Aussteller bis zur prüfenden Stelle. Seine eigentliche Aussage für die Governance lautet: Eine erkannte Bedrohung ist noch keine betriebene Schutzmaßnahme.
Fallakte
Trennung ist nicht Unverknüpfbarkeit: die Beweislast aus RFC 9614
Zwei Dienste speicherten zwei verschiedene Wahrheiten. Der Relay kannte den Anschluss, aber nicht die Anfrage. Das Gateway kannte die Anfrage, aber nicht den Anschluss. Auf dem Organigramm waren sie getrennt; im Analysezugang lagen beide Protokolle nebeneinander. Trennung…
IETF
Der sichere Austausch scheiterte. Der Rückfall legte den Versuch wieder offen
RFC 9588 schützt einen Kerberos-Passwortaustausch vor Offline-Tests; fällt der Client danach auf den verschlüsselten Zeitstempel zurück, kann dieser Schutz verschwinden.