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.
Geschichte
Der Server brauchte den Klartext nicht. Er kontrollierte dennoch die Verfügbarkeit: RFC 3157
Ein Verwahrer muss den Inhalt eines versiegelten Umschlags nicht kennen, um seine Rückgabe zu verweigern. RFC 3157 übertrug diese Trennung im August 2001 auf kryptografische Berechtigungsnachweise, die zwischen Rechnern, Telefonen und Routern beweglich werden sollten.…
Berichte
Bei RIPE NCC wird der RPKI-Schlüssel moderner – seine Reichweite muss enger werden
RIPE NCC bindet das RPKI-Dashboard und künftige API-Schlüssel an OpenID Connect. Auf derselben Planungsseite steht, warum eine RPKI-Routing-Beacon noch nicht umgesetzt wurde: Die dafür vorgesehene API hätte ROAs für den gesamten Adressraum von RIPE NCC bearbeiten können. Diese…
Geschichte
Der Server brauchte eine dritte Zufallszahl: RFC 3163
Im gegenseitigen Authentisierungsmodus von RFC 3163 war der dritte Zufallswert kein Beiwerk. Er reagierte auf eine Asymmetrie im Ablauf: Als der Client seinen eigenen Wert auswählte, kannte er bereits die erste Herausforderung des Servers. Die Korrektur war eng umrissen – ebenso…
IETF
Der Umschlag war signiert. Der abgetrennte Chiffretext lag außerhalb der Signatur.
Ein gültiges COSE-Objekt und eine erfolgreich entschlüsselte Datei können gleichzeitig vorliegen, ohne dass die äußere Signatur diese Datei je erfasst hat. Sobald Steuerobjekt und Chiffretext getrennt gespeichert werden, entscheidet die exakte Byte-Abdeckung über die Aussagekraft…
IETF
Der Kalender nannte ihn Eigentümer. Kontrolle hatte er damit noch nicht.
Ein portabler Kalendereintrag kann einen Teilnehmer als Eigentümer bezeichnen, ohne ihn zum berechtigten Bearbeiter zu machen. Das Label beschreibt eine Rolle; erst das Austauschprotokoll entscheidet, wer den Termin verschieben, Teilnehmer ändern oder ein Update versenden darf.
IETF
Die Umleitung gelang. Das Zugangstoken war bereits im Klartext unterwegs.
Am Ende des Traces stehen eine HTTPS-Adresse und eine erfolgreiche Antwort. Der entscheidende Vorgang liegt davor: Noch bevor der Server umleiten konnte, hatte der Client das Zugangsmittel in die erste unverschlüsselte HTTP-Anfrage geschrieben.
IETF
Die Kette validierte mit ihrem eigenen Anker. Die prüfende Stelle hatte ihm noch nicht vertraut.
Bei did:x509 kann die Auflösung fehlerfrei enden, obwohl die entscheidende institutionelle Prüfung noch aussteht. Kette, CA-Fingerabdruck und Blatt-Prädikate können zusammenpassen; ob die prüfende Stelle der CA vertraut und den konkreten Vorgang erlaubt, entscheidet weiterhin…
Geschichte
Langzeitbeweise mussten den Schlüssel überleben: RFC 3126
RFC 3126 behandelte eine alte Signatur als Aufbewahrungsproblem. Eine 2001 richtige Berechnung konnte sich Jahrzehnte später nicht erklären, wenn Zertifikate, Sperrdaten, exakte Bytes oder vertrauenswürdige Algorithmen fehlten. Die Antwort war eine erneuerbare Beweiskette, kein…
IETF
Die Nachricht ließ sich öffnen. Der Gruppenkontext fehlte trotzdem.
Ein externer MLS-Empfänger kann denselben Commit oder Proposal wie die Mitglieder entschlüsseln und dennoch den Absender nicht authentifizieren. Dafür braucht er den GroupContext, der Epoche, Sender-Leaf, Credential und vereinbarte Empfängerliste verbindet.
Geschichte
Auch eine gültige Signatur brauchte noch eine Richtlinie: RFC 3125
RFC 3125 wollte die Regeln um eine elektronische Signatur eindeutig referenzierbar und maschinenlesbar machen. Die korrekte Kryptografie öffnete nur das erste Tor: Policy-Fassung, Verpflichtung, Vertrauensbedingungen und institutionelle Anerkennung blieben eigene Entscheidungen.
IETF
Der aktive Schlüssel signierte seinen Nachfolger. Genau das war das Risiko.
Ein lückenloser Übergang kann technisch korrekt und trotzdem vom Angreifer geschrieben sein. Entscheidend ist, ob die aktuelle Signaturbefugnis auch das Recht umfasste, den gesamten künftigen Schlüsselzustand festzulegen.
IETF
Die Signatur war gültig. Wer hatte den Schlüssel dem Partner zugeordnet?
Bei einer Zertifikatsumstellung kann alles grün sein: HTTPS steht, AS2-Namen stimmen, die Signatur ist gültig, der MIC passt. Gerade dann wird sichtbar, was kein Algorithmus nachtragen kann—die dokumentierte Entscheidung, dass dieser Schlüssel für diese Geschäftsbeziehung…
Asien-Pazifik Institutionell
TrueMoney: Faktencheck der Nutzer- und Agentenzahlen
TrueMoney wirbt mit Millionen Nutzern, Zehntausenden Agenten und Milliardenvolumen in Südostasien. Diese Prüfung stellt die veröffentlichten Kennzahlen von TrueMoney und Ascend Money datierten Primärquellen gegenüber — und zeigt, welche Zahlen tragen und wo die Marketinggrenze…
IETF
Der Voucher versprach eine Neuausstellung. Erneuert war noch nichts.
Im aktuellen ANIMA-Entwurf ist `last-renewal-date` eine informative Prognose des MASA. Revision 36 benennt die spätere Entscheidung genauer: neue RVR, Domain-Schlüssel, Zertifikatsstatus, aktuelle Policy und ein tatsächlich ausgestellter Ersatz bleiben eigenständige Nachweise.
IETF
Zwei Modi verschwinden aus dem Entwurf, nicht aus jedem Binärprogramm
Der geplante Nachfolger von RFC 9180 behält Base und PSK im HPKE-Kern und reserviert die früheren Werte für Auth und AuthPSK. Das ist eine klare Spezifikationsgrenze, aber noch kein Nachweis über geladene Bibliotheken, aktive Ausnahmen, langlebige Objekte oder Gegenstellen.
IETF
Der Tunnel blieb grün. Die große Ethernet-Frame wurde verworfen
Ein CONNECT-ETHERNET-Tunnel kann vollständig aufgebaut, authentisiert und betriebsbereit sein, während bestimmte Frames deterministisch verloren gehen. In QUIC-DATAGRAM passen sie nicht, am Ausgang überschreiten sie die zulässige Größe oder die Bridge kann sie nicht zustellen.…
IETF
Der Server lieferte das alte Objekt, nicht den Audit-Trail
JMAP Entität History soll frühere und zerstörte Objektversionen abrufbar machen. Die Regeln des Entwurfs zeigen zugleich, weshalb solche Momentaufnahmen weder jede Änderung noch Akteur, Berechtigung oder Ergebnis belegen.
IETF
Falsche Pfadmetadaten erzeugen einen Ausfall, kein neues Vertrauen
Wenn ein Server eine Zertifikatskette dem falschen Trust-Anchor-Kennzeichen zuordnet, kann er mit großer Zuverlässigkeit genau den Pfad ausliefern, den der Client ablehnen muss. Der Entwurf der IETF lässt diesen Fehler an der Verfügbarkeitsgrenze enden: Die Metadaten steuern die…
IETF
Der Exporter lieferte 128 Byte. Sie banden den Token-Inhaber nicht an den Tunnel
Revision 04 von EAP-PPT streicht eine Ausgabe, die wie Schlüsselmaterial der inneren Methode wirkte. Ein TLS-Exporter kann sitzungsspezifische Bytes liefern, ohne zu beweisen, dass Token-Inhaber und Tunnelendpunkt dieselbe Partei sind.
Geschichte
Für das Passwort gab es keinen Verzeichniseintrag zum Ändern: RFC 3062
2001 erreichte die gewöhnliche LDAP-Änderungsoperation nicht jedes Passwort. RFC 3062 führte einen eigenen Änderungsaufruf ein: Er konnte sich auf den Benutzer der aktuellen Sitzung oder auf eine Identität beziehen, die kein DN sein musste – selbst wenn das Passwort außerhalb des…