PP pki data

Una firma no vale nada sin la clave pública que la verifica, y BIP70 enviaba esa clave dentro de un certificado y no por separado. El campo contenía un pequeño mensaje protobuf que envolvía una lista de certificados DER en bruto, ordenados desde el comerciante hacia fuera. Su contenido decidía si una billetera mostraba el nombre de una empresa o una simple advertencia.

Cómo funciona

Estado: histórico. PP pki data era el campo 3 de los cinco de un mensaje PaymentRequest, y Bitcoin Core eliminó el código que lo leía en la versión 0.20.0, publicada el 3 de junio de 2020.

Dentro de esos bytes había un mensaje protobuf llamado X509Certificates con exactamente un campo repetido, en el que cada elemento era un certificado completo en forma binaria. El orden estaba especificado en lugar de dejarse al gusto de cada cual: primero iba el propio certificado del comerciante y después los intermedios que hicieran falta para llegar a un certificado raíz público.

El propio certificado raíz faltaba a propósito, y el razonamiento se generaliza mucho más allá de BIP70. Un certificado raíz que se recibe de la misma parte a la que se intenta verificar no demuestra nada, ya que cualquiera puede generar uno y firmar con él lo que quiera. La confianza tiene que llegar desde una lista que su dispositivo ya tiene.

DER, la codificación utilizada, es la forma binaria canónica de ASN.1: una estructura, exactamente una secuencia de bytes válida. El conocido formato PEM, con sus líneas BEGIN CERTIFICATE, consiste en esos mismos bytes en base64, lo que ocupa alrededor de un tercio más de espacio, así que el formato en la red es siempre el que va en bruto.

Los certificados dominaban el tamaño de una solicitud. Las salidas, una marca de tiempo y una nota podían sumar un par de cientos de bytes, mientras que un certificado RSA-2048 por sí solo lleva un módulo de 256 bytes y una firma de 256 bytes antes de contar ningún nombre ni extensión, y dos de ellos seguidos llegan a miles de bytes. Cuando el pki type era "none", el campo simplemente quedaba vacío y una billetera no tenía nada que mostrar salvo el destino.

Dónde aparece

La misma lista de certificados, en el mismo orden, con el certificado de hoja primero, llega en cada conexión HTTPS que usted establece.

Un servidor TLS envía primero su propio certificado y después los intermedios, y omite el certificado raíz por la razón expuesta arriba. Usted puede leer la lista exacta que envía cualquier sitio con un solo comando, openssl s_client -showcerts -connect example.com:443, y lo que se imprime es exactamente el mismo material que transportaba BIP70, mostrado en PEM en lugar de en binario.

Para quien compra bitcoin, la lección está en lo que esos bytes no dicen. Una cadena de certificados válida demuestra que alguna autoridad comprobó el control de un nombre de dominio en el momento de la emisión. No dice nada sobre quién es el dueño de la empresa, si la página es un clon de un exchange o si ese exchange puede atender los retiros. Los sitios de phishing tienen certificados totalmente válidos, obtenidos gratis y en segundos, y el candado que producen es indistinguible del auténtico.

Así que lea el dominio, no el candado. Acceda a un exchange desde un marcador que usted creó una vez, no desde un anuncio en un buscador, y trate una advertencia de certificado en un sitio que guarda su dinero como un punto final y no como un simple aviso.

PP pki data frente a cadena de certificados

PP pki data era un contenedor; la cadena de certificados es lo que iba dentro. Hablar de pki data solo tiene sentido al leer documentación de BIP70 o código fuente archivado de billeteras, porque nada más ha usado nunca ese término. Una cadena de certificados, en cambio, es algo vivo de lo que usted depende a diario, y la regla de ordenación que BIP70 dejó por escrito, el certificado de hoja primero y el certificado raíz omitido, es la regla que TLS sigue aplicando.