Données PKI de PP

Une signature ne vaut rien sans la clé publique qui la vérifie, et le BIP70 livrait cette clé à l'intérieur d'un certificat plutôt que seule. Le champ contenait un petit enrobage protobuf autour d'une liste de certificats DER bruts, ordonnés du marchand vers l'extérieur. Son contenu décidait si un portefeuille affichait un nom d'entreprise ou un simple avertissement.

Comment cela fonctionne

Statut : historique. Les données PKI de PP étaient le champ 3 des cinq d'un message PaymentRequest, et Bitcoin Core a supprimé le code qui le lisait dans la version 0.20.0, publiée le 3 juin 2020.

Dans ces octets se trouvait un message protobuf nommé X509Certificates avec exactement un champ répété, chaque entrée étant un certificat complet sous forme binaire. L'ordre était spécifié plutôt que laissé au choix : le propre certificat du marchand venait en premier, puis les intermédiaires nécessaires pour atteindre une racine publique.

La racine elle-même était volontairement absente, et le raisonnement dépasse largement le BIP70. Une racine reçue de la partie que vous cherchez à vérifier ne prouve rien, puisque n'importe qui peut en générer une et signer avec elle tout ce qu'il veut. La confiance doit venir d'une liste que votre appareil détient déjà.

DER, l'encodage utilisé, est la forme binaire canonique de l'ASN.1 : une structure, exactement une séquence d'octets légale. Le format PEM familier avec ses lignes BEGIN CERTIFICATE, ce sont ces mêmes octets en base64, ce qui coûte environ un tiers d'espace en plus, si bien que le format de transmission est toujours le format brut.

Les certificats dominaient la taille d'une demande. Des sorties, un horodatage et une note pouvaient atteindre quelques centaines d'octets, tandis qu'un certificat RSA-2048 porte à lui seul un module de 256 octets et une signature de 256 octets avant même de compter les noms ou les extensions, et deux d'entre eux à la suite se chiffrent en milliers. Là où le type pki valait « none », le champ était simplement vide et un portefeuille n'avait rien à afficher d'autre que la destination.

Où le voir

La même liste de certificats, dans le même ordre feuille en premier, arrive sur chaque connexion HTTPS que vous établissez.

Un serveur TLS envoie son propre certificat d'abord et les intermédiaires ensuite, en omettant la racine pour la raison ci-dessus. Vous pouvez lire la liste exacte qu'envoie un site avec une seule commande, openssl s_client -showcerts -connect example.com:443, et ce qui s'affiche est le matériel identique que transportait le BIP70, présenté en PEM plutôt qu'en binaire.

Pour qui achète du bitcoin, la leçon tient à ce que ces octets ne vous disent pas. Une chaîne valide prouve qu'une autorité a vérifié le contrôle d'un nom de domaine au moment de la délivrance. Elle ne dit rien sur la personne qui possède l'entreprise, sur le fait que la page soit un clone d'une plateforme d'échange, ni sur la capacité de cette plateforme à honorer les retraits. Les sites d'hameçonnage portent des certificats parfaitement valides, obtenus gratuitement et en quelques secondes, et le cadenas qu'ils produisent est indistinguable du vrai.

Lisez donc le domaine, pas le cadenas. Accédez à une plateforme d'échange par un favori que vous avez créé une fois plutôt que par une publicité de recherche, et traitez un avertissement de certificat sur un site qui détient votre argent comme un point final plutôt que comme une invite.

Données PKI de PP vs chaîne de certificats

Les données PKI de PP étaient un conteneur ; la chaîne de certificats est ce qui y entrait. Nommer les données pki n'a de sens que lorsqu'on lit la documentation du BIP70 ou le code source archivé d'un portefeuille, car rien d'autre n'a jamais employé ce terme. Une chaîne, en revanche, est une chose vivante dont vous dépendez chaque jour, et la règle d'ordre que le BIP70 a couchée par écrit, feuille en premier avec la racine omise, est celle que TLS suit encore.