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 défi a traversé le délai, pas l’autorité : RFC 9891
RFC 9891 permet à ACME d’éprouver le contrôle d’un identifiant de nœud dans un réseau tolérant aux délais. Cette réussite reste une preuve circonstanciée, et non un titre sur le nom, la route ou l’infrastructure.
IETF
Rich Salz et l’exigence TLS 1.3 qui n’était pas une preuve de déploiement
Une norme peut imposer une règle nette sans produire par elle-même la preuve que cette règle est devenue vraie dans chaque système en fonctionnement. Cette distinction ne diminue pas la norme; elle permet de ne pas confondre une décision de protocole fondée avec une affirmation…
IETF
Nancy Cam-Winget et l’événement SCIM qui n’était pas un reçu de rapprochement
Entre deux domaines d’identité, annoncer un changement ne revient pas à démontrer qu’il a été assimilé de l’autre côté. Il faut encore identifier la ressource, concilier les schémas, décider d’un éventuel rappel, appliquer une règle locale et constater l’état propre du récepteur.…
IETF
Chris Wendt et la réponse signée qui n’authentifiait pas le média
Une sonnerie suivie d’une réponse n’établit pas, à elle seule, qui parlera ensuite ni quelle règle doit gouverner l’appel. Le travail de Chris Wendt dans RFC 9970 apporte un élément de preuve utile à cette séquence: une réponse SIP peut porter une identité signée du côté atteint.…
IETF
Michael Prorock et l’identifiant d’algorithme qui ne choisissait pas une politique de confiance
Nommer correctement une clé et l’algorithme auquel elle appartient rend un échange interopérable. Cela ne dit pas pourquoi la clé est arrivée, quelle autorité l’a distribuée, quelles affirmations elle peut étayer ni quelle décision un vérificateur peut prendre. RFC 9964, coécrit…
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…