Le protocole ACME, normalisé dans le RFC 8555, permet d'automatiser le processus de création et de renouvellement de certificats utilisables, par exemple, pour TLS. L'extension normalisée dans ce nouveau RFC permet d'obtenir et de renouveler des certificats pour un service utilisant le ".onion" de Tor. Si vous voulez passer à la télévision en disant « j'ai obtenu un certificat pour le Dark Web », ce RFC est la bonne lecture.

Si vous utilisez Let's Encrypt (et tout le monde l'utilise, de nos jours), vous avez sans doute reçu les messages « Let's Encrypt Expiration Emails Update » qui vous préviennent que cette AC n'enverra plus de rappels (https://letsencrypt.org/2025/01/22/ending-expiration-emails/) que vos certificats vont bientôt expirer. C'est parce qu'un meilleur système est maintenant disponible, ARI (ACME Renewal Information). ARI permet à une AC utilisant le protocole ACME d'indiquer à ses clients des suggestions sur le renouvellement des certificats. Il est décrit dans ce RFC.

La cryptographie post-quantique vise à développer des algorithmes de cryptographie qui résistent à des ordinateurs quantiques. Mais ces algorithmes sont relativement récents et peuvent avoir des faiblesses, voire des failles, que la cryptanalyse classique pourra exploiter. La tendance actuelle est donc aux protocoles et formats hybrides, combinant algorithmes classiques et post-quantiques. Ce RFC spécifie la terminologie de ces protocoles hybrides.

Traditionnellement, les registres de noms de domaine publiaient toutes les informations des sous-domaines avec la même durée de vie maximale (TTL : Time To Live). Certain·es client·es demandent à pouvoir choisir un TTL plus court (ou, parfois, plus long) et ce RFC décrit comment faire cela avec le protocole EPP.

Les API réseau, c'est très bien. Tout le monde en fait aujourd'hui, typiquement bâties au-dessus de HTTP. Mais il est parfois difficile de s'y retrouver parmi toutes les API. « Je suis sûr que l'INSEE avait une API pour faire ça mais où est-elle exactement et où est sa documentation ? La solution pour cela ? Les catalogues d'API, rassemblant nom, description, URL, etc, des API. Il ne reste plus qu'à trouver le catalogue… Ce RFC fournit pour cela un URL standard et un mécanisme de lien. Il fournit également un format standard pour écrire ce catalogue, bâti sur Linkset (RFC 9264, section 4.2).

C'est un passionnant livre d'histoire de la communication et des médias que le résultat de la recherche menée par l'auteur sur la rubrique « La clinique des rumeurs », publiée par le Boston Herald pendant la Deuxième Guerre mondiale. Ce premier essai de fact-checking, comme on ne disait pas encore à l'époque, posait déjà toutes les questions liées à la vérification des informations, et à l'attitude à avoir face à la propagande de l'adversaire.

Le dispositif de censure de l'Internet en Chine comprend de nombreux composants. L'un d'eux est une injection de fausses réponses DNS par des équipements réseau (et pas, comme c'est courant en Europe (https://labs.ripe.net/author/stephane_bortzmeyer/dns-censorship-dns-lies-as-seen-by-ripe-atlas/), par un résolveur (resolveur-dns.html) menteur). Comme tout logiciel, il a des bogues, et même des bogues menant à des failles de sécurité. C'est le cas de Wallbleed (https://gfw.report/publications/ndss25/en/), une intéressante bogue, étudiée dans un article détaillé (https://www.ndss-symposium.org/ndss-paper/wallbleed-a-memory-disclosure-vulnerability-in-the-great-firewall-of-china/). Cette bogue permet d'observer plusieurs choses sur le système de censure chinois, par exemple ses pratiques de correction des bogues.