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.
IETF
Quand la preuve est valide, à qui appartient encore l’étiquette ?
La transparence des clés sait rendre une réponse vérifiable. Elle ne décide pas, à elle seule, qui avait le droit d’agir ni qui devra surveiller l’étiquette demain. La dernière revue de l’IETF place précisément cette frontière au centre du dossier.
Dossier
Le jeton était actif pour ce serveur. La règle métier pouvait encore dire non : RFC 9701
Une réponse `active:true`, signée par le bon serveur d’autorisation et destinée au bon serveur de ressources, constitue une preuve précise. Elle s’arrête pourtant avant la décision locale: l’objet visé peut être verrouillé, l’opération trop risquée ou la preuve de possession…
IETF
Le certificat a rétréci. La décision de confiance, non
Le résumé de veille Le certificat a rétréci. La décision de confiance, non explique le développement, les preuves publiques disponibles, les organisations concernées, le contexte régional, l’exposition au marché et les conséquences possibles pour l’infrastructure. Le contexte…
IETF
Le certificat couvrait le numéro, pas la décision de répondre
Un appel peut arriver avec une signature valide, un certificat à jour et une réponse OCSP favorable pour le numéro présenté. Cette chaîne resserre utilement le champ du doute. Elle ne dit toujours pas qui parle, pourquoi cette personne appelle ni ce que le réseau destinataire…
Dossier
Le validateur a accepté la signature. L’archive avait déjà changé l’objet
Une chaîne CMS peut être valide à l’entrée puis devenir non conforme après une opération présentée comme neutre: décoder, normaliser et réencoder. RFC 9688 montre pourquoi le nom « SHA3 » ne suffit pas. Le champ de paramètres est lui-même un état de protocole, avec des règles…
IETF
Aucun conflit de normalisation n’a été constaté. La clé d’usine n’a toujours pas de note de sécurité
L’IESG n’a relevé aucun conflit empêchant la publication d’une taxonomie IRTF sur les clés et ancres de confiance installées en usine. Ce feu vert porte sur le parcours éditorial du document. Il ne classe ni les cinq méthodes de fabrication ni la sûreté d’un appareil livré.
IETF
Un destinataire a déchiffré le JWE. La règle de réception restait à trancher
Dans une enveloppe JWE à plusieurs destinataires, récupérer le texte en clair peut ne nécessiter qu’un chemin valide. La future norme HPKE expose précisément ce résultat; elle ne décide pas à la place de l’organisation si un succès suffit, si tous les destinataires étaient…
IETF
Le reçu final de SATP authentifie une déclaration, pas l’état de deux réseaux
Une signature peut rendre un message imputable sans transformer son auteur en observateur omniscient. C’est la distinction décisive du dernier appel sur SATP: la chaîne entre passerelles est commune, mais la preuve du burn, du mint et de la reprise après incident reste en dessous…
Dossier
Les deux pièces d’agenda se contredisaient. La seule bonne automatisation était de ne rien changer
Le RFC 9671 autorise Sieve à traiter des données de calendrier reçues par courriel, mais il impose d’abord une discipline rarement visible dans les tableaux de bord: lorsque plusieurs représentations MIME ne disent pas la même chose, l’action doit s’arrêter.
Dossier
Le partage avait été révoqué. Le fichier exporté n’appartenait déjà plus au serveur
RFC 9670 organise l’identité collaborative, les droits par objet et les notifications dans JMAP. Il permet de fermer proprement une autorisation vivante; il ne transforme pas cette fermeture en effacement rétroactif de ce qu’un destinataire a déjà obtenu.
Société des ressources numériques
« Setting up 2FA with Passkey » : ce que documente réellement le guide RIPE NCC sur les passkeys
Le libellé « Setting up 2FA with Passkey » a été enregistré dans un annuaire réseau comme une institution de la région TW. En réalité, il s'agit du titre exact d'une section de la documentation d'assistance du RIPE NCC sur la vérification en deux étapes. Derrière ce libellé se…
IETF
Le certificat est valide. La livraison reste à démontrer
RFC 9538 permet à un CDN aval d’obtenir un certificat avec sa propre clé sans recevoir la clé privée durable du CDN amont. Cette délégation ne constate ni la bascule DNS, ni l’activation sur tout le parc, ni le contenu réellement servi.
Dossier
RFC 9646 : la réponse 400 demandait un CSR, elle n’autorisait pas une identité
L’équipement d’usine reçut un `400 Bad Request`. Le superviseur conclut à un échec; le protocole, lui, venait de transmettre l’ordre de générer une clé et une forme précise de demande de certificat. Dans RFC 9646, le code rouge peut faire avancer l’enrôlement. Il ne dit encore…
Dossier
RFC 9645 : la configuration autorisait quatre identités, la session n’en a emprunté qu’une
Un tableau de conformité peut afficher un certificat valide alors que la connexion décisive a repris une session au moyen d’un PSK. Les deux constats peuvent être vrais. Ils ne racontent pas le même acte d’authentification. RFC 9645 organise avec rigueur les possibilités offertes…
Dossier
RFC 9644 : de l’algorithme autorisé à la preuve de session SSH
Un registre peut autoriser un nom à exister sans recommander son usage. Un équipement peut annoncer qu’il sait employer un algorithme sans l’avoir négocié. Une configuration peut ordonner des préférences sans révéler le choix du pair. La RFC 9644 rapproche ces trois plans dans un…
Dossier
Le magasin a été restauré. L’autorité de déchiffrement ne l’était pas : RFC 9642
RFC 9642 fournit un modèle YANG commun pour les clés centrales ou intégrées, les certificats et les valeurs chiffrées. Une sauvegarde peut repeupler chaque nœud sans rendre les secrets utilisables. La reprise exige la preuve du graphe KEK–clé primaire, de la liaison au serveur…
Dossier
Une ancre a changé, six services ont changé de confiance : RFC 9641
RFC 9641 permet à plusieurs services de référencer un même sac central de certificats ou de clés publiques. Cette mutualisation simplifie le renouvellement, mais elle concentre aussi le pouvoir de modifier ce que tous ces services peuvent accepter. Le nom du sac ne suffit donc…
Dossier
La carte des menaces des justificatifs ne dit pas qui tient les commandes
La nouvelle note de travail du W3C détaille les risques des justificatifs vérifiables. Elle permet surtout de distinguer les garanties du modèle de données des précautions que chaque acteur doit effectivement mettre en œuvre.
Dossier
Deux salles, une même horloge : la confidentialité incomplète de RFC 9614
Le relais travaille dans une salle, la passerelle dans une autre. Aucun écran ne montre à la fois l'abonné et sa requête. Pourtant, les deux journaux utilisent la même horloge: un paquet d'une taille rare quitte la première salle et apparaît quelques millisecondes plus tard dans…
IETF
L’échange sûr a échoué. Le repli a rendu le mot de passe testable
RFC 9588 ferme une voie de vérification hors ligne du mot de passe Kerberos; un client qui revient à l’horodatage chiffré après un échec peut la rouvrir.