Stéphane Bortzmeyer a écrit 645 commentaires

Oui, normalement, en HTTPS, la demande d'un certificat client est faite par TLS, pas par HTTP. (Message CertificateRequest, RFC 8446, section 4.3.2.)

CT a des défauts (par exemple il facilite le renseignement économique, en surveillant les certificats des concurrents) mais, si, il résoud un problème : avant, n'importe quelle AC pouvait émettre un certificat pour n'importe qui. Maintenant, elle peut toujours mais ça se voit.

Et ce n'est pas que Google, un RFC a été publié https://www.bortzmeyer.org/6962.html et la version normalisée est en cours https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ les objections étant surtout du détail https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ballot/

Oui, le but, c'est de distribuer de l'information. (Comme le Web à l'origine.) Par exemple une encyclopédie en ligne, une documentation, des textes politiques ou littéraires.

C'est en effet l'un des gros problèmes du TOFU, le remplacement de clé.

Non, Gemini ne recommande pas cela (tout le monde peut vérifier que le site de référence a un certificat Let's Encrypt), c'est juste l'opinion de DeVault.

Tout a un impact énergétique et déplacer les messages vers encore un autre espace de stockage n'est certainement pas gratuit énergétiquement non plus.

Problème connu (XMPP l'a expérimenté) : les spams dans les invitations.

Cela ne respecte pas le cahier des charges, qui est de permettre à un inconnu de vous écrire (sinon, la solution au problème du spam est trop facile).

Si quelqu'un sait comment faire un système de messagerie électronique simple pour un réseau mondial, sans chef, et qui permette à toute Alice de parler à tout Bob, les propositions sont les bienvenues :-)

Plus sérieusement, les gens font des sites Web alors que c'est certainement bien plus complexe que de gérer un serveur de courrier.

Le Tao est aussi une bonne lecture https://www.ietf.org/about/participate/tao/

On peut aussi préciser qu'OpenPGP est une norme ouverte, spécifiée dans le RFC 4880.

Oui, mais cette idée d'une « carte d'identité numérique pour toute la population » étant mauvaise (et je rappelle que la carte d'identité n'est pas obligatoire en France), qu'elle ne soit pas réalisée ne me gêne pas.

C'est un témoignage concernant un des fournisseurs d'identité qui peut utiliser FranceConnect (personnellement, j'ai utilisé Ameli et les impôts). Le principe de FranceConnect étant de séparer le service d'authentification du fournisseur d'identité, il me semble qu'un problème chez un des fournisseurs d'identité ne remet pas en cause FranceConnect.

La remarque sur FranceConnect est curieuse. En quoi a-t-il « échoué » ? Je trouve que c'est une bonne idée, bien mise en œuvre, et qui semble largement utilisée.

Ce n'est pas correct de mentionner uniquement FreeOTP. Il s'appuie sur des normes ouvertes (comme TOTP) donc si ça marche avec FreeOTP, ça marchera avec n'importe lequel des très nombreux logiciels qui font du TOTP. FreeOTP n'est qu'un logiciel, pas un protocole.

(Et TOTP n'utilise pas de clé publique, contrairement à ce qui est écrit.)

Bon, mais ils n'ont rien de "rogue", ces résolveurs.

Cela risque-t-il d'impacter les rogues DNS ?

Euh, il faudrait expliquer la question.

Il y a de nombreuses années (2013 !) qu'asso.fr est fermé (les noms existants continuent mais il n'y a plus de créations)

PS : l'article cité a plus de dix-huit ans…

Une bonne réputation ? Venue d'où ? Évaluée par qui ?

Ceci dit, une fois installé, un résolveur ne tombe que très rarement en panne. Il n'y a que DNSSEC qui nécessite du soin.

Ce qui est justement une mauvaise idée.

Ce problème a été remonté aux développpeurs de RIPE Atlas, et ils cherchent une solution.

Je ne suis pas convaincu qu'il y a un problème. C'est plutôt l'affichage Web d'Atlas qui est trompeur. Quand on regarde le JSON des résultats (https://atlas.ripe.net/api/v2/measurements/22766270/results/), on n'a au contraire que des succès.

Par exemple, la sonde 12774 est marquée comme "undefined" dans l'interface graphique alors que, dans le fichier JSON, on voit qu'elle a eu un résultat positif d'un de ses résolveurs.

Je soupçonne que l'affichage trompeur vient des erreurs de connexion vers les résolveurs IPv6. C'est en tout cas ce qu'on voit dans les résultats bruts :

     {
        "dst_name": "fe80::3e81:d8ff:fede:fbf8",
        "error": {
          "socket": "connect failed Invalid argument"
        },

Toujours se méfier des jolies affichages graphiques !

https://labs.ripe.net/Members/stephane_bortzmeyer/creating-ripe-atlas-one-off-measurements-with-blaeu

« Tout le monde n'a pas une machine qu'il contrôle sur internet (moi personnellement je n'en ai pas, je fais comment alors?) » OU BIEN VERS UNE MACHINE PRÉVUE POUR CELA, c'était écrit. Les ancres Atlas, par exemple. https://labs.ripe.net/Members/stephane_bortzmeyer/checking-your-internet-connectivity-with-ripe-atlas-anchors

« si ca marche, je teste un ping sur www.google.Fr » C'est très sommaire comme test :

• ping ne donnera pas de message d'erreur détaillé s'il y a un problème DNS (juste du binaire ça marche / ça marche pas). Pour tester le DNS, il vaut mieux utiliser dig.
• s'il y a une panne, comment savoir si elle est de la faute de Google, de l'AFNIC ou du résolveur ?