Aller au contenu principal

Sujet

Identité numérique et justificatifs

Au sein de la facette Sujet, la veille thématique Identité numérique et justificatifs rassemble des articles qui partagent un même sujet, un même signal ou un même thème de suivi. Cette page offre aux lecteurs un parcours plus riche à travers les reportages associés, les preuves issues de sources publiques, les acteurs du marché et les implications pour l’infrastructure, avec suffisamment de contexte pour comprendre pourquoi le sujet compte pour les mouvements d’entreprises, les décisions de gouvernance, l’exposition régionale et le risque opérationnel. Les lecteurs peuvent comparer les signaux récurrents, les organisations concernées, les preuves publiques, le contexte du marché, la continuité de service, les achats, la concurrence, la conformité et les questions de planification stratégique liées au sujet, au lieu de se contenter d’une liste succincte d’articles correspondants. Elle explique ce que couvre le sujet, quels acteurs ou politiques de l’infrastructure sont impliqués, quelles preuves étayent la couverture et pourquoi le sujet peut être important pour les opérateurs, les clients, les investisseurs et les lecteurs de politiques publiques.

Le serveur n’avait pas besoin du texte clair pour contrôler la disponibilité : RFC 3157

Histoire d'Internet

Le serveur n’avait pas besoin du texte clair pour contrôler la disponibilité : RFC 3157

Un coffre peut ignorer le contenu de l’enveloppe qu’il garde et conserver pourtant le pouvoir de la rendre introuvable. En août 2001, RFC 3157 appliquait cette dissociation aux identifiants cryptographiques devenus mobiles. Chiffrer une clé privée pendant son stockage et son…

1 oct. 2026
Dans RPKI, une identité plus moderne ne réduit pas automatiquement le pouvoir

Récits

Dans RPKI, une identité plus moderne ne réduit pas automatiquement le pouvoir

Deux lignes du programme RPKI de RIPE NCC doivent être lues ensemble. La première annonce le remplacement progressif des clés d’API par des identifiants fondés sur OpenID Connect. La seconde explique pourquoi une balise de routage n’a pas été déployée: l’API envisagée aurait pu…

1 oct. 2026
Le serveur avait besoin d’un troisième défi : RFC 3163

Histoire d'Internet

Le serveur avait besoin d’un troisième défi : RFC 3163

Dans le mécanisme mutuel de RFC 3163, une troisième valeur aléatoire n’était pas un ornement. Elle répondait à un décalage d’ordre: le client avait déjà vu le premier défi du serveur lorsqu’il choisissait sa propre valeur aléatoire. La correction reste toutefois limitée, tout…

1 oct. 2026
L’enveloppe était signée. Le texte chiffré détaché ne l’était pas.

IETF

L’enveloppe était signée. Le texte chiffré détaché ne l’était pas.

Un entrepôt contient l’objet COSE, un autre conserve les octets chiffrés, et le tableau de bord n’affiche qu’un voyant « signature valide ». Cette simplification efface la question décisive: quels octets exacts sont entrés dans le calcul cryptographique, et lesquels ont seulement…

1 oct. 2026
Le calendrier l’appelait propriétaire. Aucun pouvoir ne lui avait encore été accordé.

IETF

Le calendrier l’appelait propriétaire. Aucun pouvoir ne lui avait encore été accordé.

Un calendrier portable peut attribuer à une personne le rôle de propriétaire sans faire d’elle un éditeur autorisé. Le libellé décrit une place dans l’événement; le protocole d’échange doit encore décider qui peut déplacer la réunion, changer les entités ou diffuser une mise à…

1 oct. 2026
La redirection a réussi. Le secret avait déjà circulé en clair.

IETF

La redirection a réussi. Le secret avait déjà circulé en clair.

Le journal se termine sur une URL HTTPS et l’appel produit le résultat attendu. Cette fin rassurante efface pourtant le début: avant de recevoir la redirection, le client avait déjà placé son jeton dans une requête HTTP lisible sur le réseau.

1 oct. 2026
La chaîne a validé l’ancre qu’elle apportait. Le destinataire ne lui avait pas accordé sa confiance.

IETF

La chaîne a validé l’ancre qu’elle apportait. Le destinataire ne lui avait pas accordé sa confiance.

Avec did:x509, une résolution impeccable peut s’achever avant que la décision essentielle ne commence. La chaîne fournie se tient, l’empreinte de l’autorité correspond et les prédicats de la feuille sont vrais; rien de tout cela ne dit encore que le destinataire reconnaît cette…

1 oct. 2026
La preuve à long terme devait survivre à la clé : RFC 3126

Histoire d'Internet

La preuve à long terme devait survivre à la clé : RFC 3126

La RFC 3126 aborda l’ancienne signature comme un problème de conservation des preuves. Un calcul valable en 2001 ne pouvait plus s’expliquer seul si certificats, données de révocation, octets signés ou algorithmes fiables avaient disparu. Sa réponse fut une chaîne renouvelable…

1 oct. 2026
Le message s’est ouvert, mais la mémoire du groupe manquait encore

IETF

Le message s’est ouvert, mais la mémoire du groupe manquait encore

Un récepteur externe MLS peut déchiffrer exactement le même Commit ou Proposal que les membres sans disposer de l’état qui authentifie son auteur. La pièce manquante n’est pas une seconde couche de chiffrement: c’est le GroupContext qui relie époque, feuille d’envoi, credential…

1 oct. 2026
Une signature valide avait encore besoin d’une politique : RFC 3125

Histoire d'Internet

Une signature valide avait encore besoin d’une politique : RFC 3125

La RFC 3125 voulut rendre les règles entourant une signature électronique identifiables et, si nécessaire, exécutables par une machine. Le calcul cryptographique ne fermait pourtant qu’une première porte: la validité dépendait encore de la politique exacte, du type d’engagement…

1 oct. 2026
La clé active a signé sa remplaçante. C’était précisément le risque.

IETF

La clé active a signé sa remplaçante. C’était précisément le risque.

Une rotation peut être parfaitement signée et pourtant constituer la persistance de l’attaquant. La question décisive n’est pas seulement « la signature est-elle valide ? », mais « cette clé avait-elle, seule, le mandat de choisir tout l’avenir de l’identifiant ? »

1 oct. 2026
Le certificat était valide, pas encore sa délégation AS2

IETF

Le certificat était valide, pas encore sa délégation AS2

Le moment dangereux d'une rotation n'est pas toujours celui où la cryptographie échoue. C'est parfois celui où tout fonctionne, alors que personne ne peut encore produire l'acte qui autorise cette clé à parler au nom de ce partenaire précis.

1 oct. 2026
TrueMoney : ce que les chiffres publiés par Ascend Money permettent encore de vérifier

Entreprises institutionnelles Asie-Pacifique

TrueMoney : ce que les chiffres publiés par Ascend Money permettent encore de vérifier

La fintech du groupe CP, connue du public sous la marque TrueMoney, présente des millions d'utilisateurs, des dizaines de milliers d'agents et des milliards de dollars traités. Mais ces chiffres sont undatés, définis de façon variable, et parfois contradictoires entre les pages…

30 sept. 2026
Une date promettait un nouveau Voucher. Elle ne prouvait pas le renouvellement.

IETF

Une date promettait un nouveau Voucher. Elle ne prouvait pas le renouvellement.

Dans le projet ANIMA actuel, `last-renewal-date` indique jusqu’à quand le MASA prévoit de renouveler un Voucher. La révision 36 précise les contrôles ultérieurs; elle confirme surtout qu’une projection signée n’est ni le nouvel artefact, ni une preuve de disponibilité, ni…

30 sept. 2026
Deux numéros sont devenus réservés. Aucun parc n’a été inventorié.

IETF

Deux numéros sont devenus réservés. Aucun parc n’a été inventorié.

Le projet appelé à remplacer RFC 9180 ne conserve que les modes Base et PSK de HPKE. La table normative devient plus courte; elle ne dit toujours pas quels profils, binaires, archives ou partenaires utilisent encore les anciens chemins Auth et AuthPSK.

30 sept. 2026
Le tunnel a accepté le VLAN. Il n’en connaissait pas le sens

IETF

Le tunnel a accepté le VLAN. Il n’en connaissait pas le sens

Une trame étiquetée VLAN 37 traverse un tunnel CONNECT-ETHERNET parfaitement valide. À l’entrée, 37 désigne un laboratoire isolé; à la sortie, 37 ouvre le réseau d’exploitation. Le chiffrement, l’authentification HTTP et la réponse de succès peuvent tous être corrects: aucun…

30 sept. 2026
Le serveur a rendu l’ancien objet, pas une piste d’audit

IETF

Le serveur a rendu l’ancien objet, pas une piste d’audit

JMAP Entité History propose de récupérer des versions antérieures ou détruites d’un objet. Mais ses propres règles montrent pourquoi ces instantanés ne peuvent prouver ni chaque modification, ni son auteur, ni son autorisation, ni son résultat.

30 sept. 2026
Un groupe tient dans le handshake, pas dans la politique de confiance

IETF

Un groupe tient dans le handshake, pas dans la politique de confiance

Un identifiant de groupe peut faire gagner des centaines d’octets à une négociation TLS tout en englobant une autorité que le poste client a déjà cessé d’accepter. Le paradoxe est voulu: dans le projet de l’IETF, le groupe oriente le choix du certificat côté serveur; il ne…

30 sept. 2026
L’exportateur a produit 128 octets. Ils ne liaient pas le détenteur du jeton au tunnel

IETF

L’exportateur a produit 128 octets. Ils ne liaient pas le détenteur du jeton au tunnel

La révision 04 d’EAP-PPT supprime une sortie qui ressemblait à du matériel de clé fourni par la méthode interne. Un exportateur TLS peut fabriquer des octets propres à une session sans prouver que le détenteur du jeton au porteur est aussi l’extrémité du tunnel.

30 sept. 2026
Le mot de passe n’avait pas d’entrée dans l’annuaire : RFC 3062

Histoire d'Internet

Le mot de passe n’avait pas d’entrée dans l’annuaire : RFC 3062

En 2001, une modification LDAP classique ne pouvait pas atteindre tous les mots de passe. La RFC 3062 a ajouté une opération distincte, utilisable avec l’identité de la session ou une identité qui n’est pas nécessairement un DN, même si le secret résidait hors de l’annuaire. La…

30 sept. 2026