Domaine principal
Sécurité
Au sein de la facette Domaine principal, l'analyse Sécurité regroupe les articles par domaine principal afin que les lecteurs puissent suivre un périmètre précis de l'infrastructure Internet, de la gouvernance, des marchés de connectivité ou du capital numérique. Cette page rassemble les articles associés, les preuves publiques, les institutions, les entreprises, les personnes, l'exposition régionale, les dépendances opérationnelles et le contexte de marché qui pourraient sinon être répartis entre différentes pages de catégories. Elle explique le domaine, la classe d'acteurs probable, le contexte de marché ou de gouvernance, ainsi que les sources que les lecteurs devraient utiliser pour comparer les signaux. Opérateurs, analystes et lecteurs de gouvernance peuvent voir comment un même domaine se manifeste à travers les événements, les profils, les évolutions de marché, les preuves issues de sources publiques, les dépendances régionales et les décisions d'infrastructure à plus long cycle au fil du temps.

Dossier
Le jeton est arrivé avant l’appel. La vérification a dû attendre : RFC 9888
Le service de destination détenait déjà l’assertion signée, mais aucun appel correspondant n’avait encore atteint son réseau. RFC 9888 ouvre une voie utile aux environnements où SIP ne transporte pas STIR de bout en bout. Elle ne transforme pourtant pas deux livraisons…

IETF
Dan Harkins et la clé d’amorçage qui ne pouvait pas prouver sa propre garde
Une preuve cryptographique peut établir qu’un appareil tient une clé privée sans dire comment la clé publique correspondante est arrivée sur le serveur, ni qui était habilité à l’y inscrire. C’est la limite que RFC 9966 rend lisible. Elle organise une preuve d’amorçage; elle ne…

Tendances institutionnelles Asie-Pacifique
C-DOT dévoile 14 produits de sécurité quantique
C-DOT a dévoilé 14 produits QKD et post-quantiques pour les réseaux de communication, faisant passer ses travaux sur la sécurité quantique à des systèmes matériels et logiciels précis.

Dossier
La demande était signée. L’autre clé privée restait déclarée : RFC 9883
Une signature parfaitement valide peut certifier l’auteur d’une déclaration sans prouver le fait déclaré. RFC 9883 applique exactement cette distinction à deux clés privées: l’une signe la demande, l’autre n’est jamais mise à l’épreuve. La confiance manquante devient alors une…

Dossier
RFC 9882 : le champ indiquait SHA-512, sans toujours agir sur la signature
Dans un objet CMS, une valeur obligatoire peut être exacte sans décrire le calcul qui a réellement eu lieu. RFC 9882 en donne un cas particulièrement net: sur l’un de ses deux chemins ML-DSA, le signataire doit annoncer SHA-512 et le vérificateur doit ne tenir aucun compte de…

Dossier
RFC 9879 modernise le MAC, sans faire disparaître le lecteur ancien
Un tableau de migration peut afficher trois cases vertes — fichier reconnu, secret déchiffré, import terminé — tout en omettant la question décisive: l’intégrité a-t-elle été vérifiée ? Avec RFC 9879, cette omission n’est pas théorique. Le nouveau format peut cohabiter avec un…

Dossier
Le paquet contenait deux formes, pas encore une seule clé : RFC 9935
Un paquet de clé privée ML-KEM peut réunir la graine compacte et la clé de décapsulation développée. Cette commodité ne vaut pas preuve d’identité: sans recalcul et comparaison, le destinataire n’a observé que deux valeurs bien encodées.

Dossier
L’OID a nommé le paquet de clés. Il n’en a pas autorisé l’usage : RFC 9939
Le paquet avait une étiquette CMS correcte et le parseur connaissait sa forme. C’est un fait de syntaxe. Cela ne répond pas à la question de savoir qui détient la clé, qui peut la déchiffrer ni qui peut autoriser son emploi.

Dossier
La ressource a nommé son serveur d’autorisation. Elle n’a pas accordé de droit : la frontière de découverte de RFC 9728
Une ressource peut indiquer correctement au client où poursuivre sa recherche sans l’avoir autorisé à agir. RFC 9728 organise cette découverte OAuth. Son document de métadonnées est un repère de coordination, non un jeton, non une décision du serveur de ressources et non une…

Dossier
La conversation d’autorisation restait en attente. Ce n’était pas encore un droit d’API : la frontière de continuation de GNAP
Un client peut avoir le droit de poursuivre une conversation d’autorisation sans avoir le droit d’appeler l’API demandée. RFC 9635 distingue ces deux faits: le jeton de continuation fait avancer une demande auprès du serveur d’autorisation; un droit d’accès à la ressource ne…

IETF
Sean Turner et la preuve de clé privée qui n’autorisait pas le certificat
Une requête signée est une enveloppe dont on peut vérifier l’intégrité. Ce n’est pas un mandat donné à l’autorité de certification: le porteur de la clé, l’identité revendiquée, les changements de l’intermédiaire et la décision d’émettre restent quatre objets distincts.

IETF
Panos Kampanakis et la session SSH aux trois preuves de sécurité
Une connexion SSH n'accorde pas un certificat global de sécurité parce qu'elle a choisi un échange de clés hybride. Elle établit successivement un secret de transport, l'identité de la machine distante, puis le droit d'un utilisateur à ouvrir une session. Chacune de ces décisions…

IETF
Bas Westerbaan : l’accord de clé hybride TLS n’a pas rendu le certificat post-quantique
Dans un comité de sécurité, la case « post-quantique » appelle une réponse binaire. Une connexion TLS 1.3 en fournit pourtant au moins deux: oui pour l’accord de clé hybride, peut-être non pour la signature du certificat. Réunir ces réponses dans un seul voyant vert fait…

IETF
Daniel Fett : la MFA a authentifié l’utilisateur, pas le contexte du QR code
Sur le téléphone, tout est légitime: le bon service, le vrai mot de passe, le second facteur et le bouton d’autorisation officiel. Le piège se trouve avant cet écran. La demande n’est pas partie de l’appareil que l’utilisateur croit être en train d’activer.

Dossier
Le certificat a vérifié le pair. La PSK externe attendait toujours un gardien : RFC 9973 et l’autorité TLS
Lors d’une revue de filière, l’équipe de sécurité peut montrer le certificat, le journal TLS et l’état « succès » du déploiement. La question qui résiste n’est pas cryptographique au premier chef: quelle organisation a pu créer, dupliquer, injecter, archiver ou réutiliser le…

Dossier
Le cookie accompagnait la demande. Il n’avait pas autorisé la décision : RFC 10025 et le pouvoir ambiant
Lors d’une revue après incident, la phrase la plus trompeuse est souvent la plus courte: « la requête était authentifiée ». Elle veut parfois dire seulement qu’un navigateur a joint un cookie, et que le serveur a reconnu une session. Entre ce fait et une décision valable, il…

Dossier
Le chiffrement a atteint la clé. Il n’a pas désigné son expéditeur : RFC 9180 et l’autorité absente du mode Base de HPKE
Un service peut déchiffrer correctement un message HPKE et ne toujours pas savoir qui l’a produit, quel ordre extérieur il portait, s’il est encore valable ou si son contenu autorise une action. RFC 9180 règle la mécanique cryptographique; il laisse volontairement ces décisions à…

Dossier
Décrire une sensation ne donne pas le droit de l’imposer : RFC 9993 et l’autorité de rendu haptique
Décoder une unité haptique signifie comprendre une représentation. Faire vibrer, chauffer, déplacer ou presser un actionneur signifie agir dans le monde physique. Entre les deux, il y a le dispositif, la personne, les limites locales et le droit d’interrompre. RFC 9993 organise…

Dossier
L’échec DMARC était réel. Le droit de divulguer restait à établir : RFC 9991 et le rapport forensique
Un incident d’authentification et une décision de divulgation ne sont pas le même événement. Le premier naît de SPF, DKIM et de l’alignement DMARC. La seconde engage le destinataire, le contenu, un éventuel prestataire et la durée de conservation. RFC 9991 relie ces opérations…

IETF
Russ Housley et l’adresse MAC qu’un certificat pouvait nommer sans la rendre unique
Inscrire une adresse MAC dans X.509 résout une question de grammaire. Cela ne transforme pas le certificat en registre IEEE, en sonde de couche 2, ni en décision d’admission du réseau.
