Resumen

  • El RFC 1805 describió un certificado de un tercero de confianza que vinculaba la huella de un archivo con una fecha y una declaración sobre su autor, sin depender del servidor que entregara el archivo.
  • El protocolo dejaba abierta la forma de verificar la identidad; Betsi, el ejemplo de Bellcore, consultaba el teléfono del autor y devolvía la llamada.

Un archivo descargado de un sitio dudoso puede ser exactamente el archivo que alguien certificó. También puede llevar un sello impecable de una persona a la que nunca se identificó bien. Esa tensión animaba el RFC 1805 de Aviel Rubin, publicado en junio de 1995. El sistema separaba tres papeles: quien creaba el archivo, quien lo recibía y un tercero de confianza. El archivo podía cambiar de ubicación. La comprobación de sus bytes y su fecha viajaba en un certificado firmado. La confianza en el nombre del autor necesitaba trabajo adicional. En la implementación Betsi de Bellcore, ese trabajo incluía buscar un número en el servicio telefónico y llamar.

La desconfianza del RFC alcanzaba incluso al programa verificador. Si un atacante altera el archivo y también la herramienta que dice revisarlo, el mensaje «todo bien» sólo multiplica el problema. Por eso Rubin propuso mensajes ASCII y técnicas de firma conocidas, de modo que el destinatario pudiera construir o conseguir una herramienta independiente. Ninguna aplicación descargada adquiría por sí sola el cargo de árbitro definitivo. La prueba se componía de operaciones separadas que otro lector podía repetir.

El recorrido tenía cinco fases: registrar al autor, comprobar su identidad, certificar el archivo, distribuirlo y verificar lo recibido. La segunda fase quedaba intencionadamente abierta. Cada aplicación podía escoger un método de identificación, pero el certificado debía revelar cuál utilizó. Es un detalle que cambia la autoridad de la firma. La clave puede firmar un mensaje; hace falta establecer a quién pertenece. Betsi, según el texto, funcionaba en Estados Unidos y utilizaba la información telefónica de la ciudad del autor para localizar un número. Luego llamaba y confirmaba los datos registrados, sobre todo la clave pública.

El RFC describe ese ejemplo, no una obligación universal de llamar por teléfono.

El autor registrado calculaba una huella criptográfica del contenido y enviaba al tercero una solicitud firmada. El tercero verificaba la solicitud, preparaba un certificado y lo sellaba con su firma. El documento incluía la huella, el algoritmo, la fecha, el nombre del autor y el método empleado para identificarlo. La ubicación del archivo era un campo opcional. Ahí estaba la idea central: lo certificado eran los bytes y una fecha, no la reputación de un directorio FTP. Archivo y certificado podían distribuirse juntos incluso por rutas inseguras.

Al llegar al destinatario empezaba otra lista, nada automática. Había que obtener por fuentes independientes la clave pública del tercero, comprobar la firma, juzgar si su método de identificación merecía confianza, calcular la huella del archivo recibido y compararla con la certificada. La fecha podía ser relevante para la decisión. También era obligatorio consultar una lista de revocación actual, completa y firmada por el tercero. Un sello sin control de revocación se parece demasiado a enseñar una entrada antigua para colarse en el concierto.

Cuando todos esos pasos encajaban, el lector podía afirmar algo concreto sobre la igualdad de los bytes y la fecha bajo una cadena de confianza determinada. La certificación no decidía si el programa era conveniente o seguro de ejecutar. El contraste entre Internet y teléfono resume la arquitectura: el archivo se desprendía de un lugar; la identidad del autor seguía exigiendo una comprobación con responsable, método y posibilidad de revisión.