Resumen

  • Un Key ID de OpenPGP ocupa 64 bits y puede coincidir en claves distintas; sirve para localizar candidatos, no para establecer una clave pública única.
  • El registro probatorio debe separar candidatos, paquete y huella completa, procedencia, certificaciones, vigencia, verificación criptográfica y autorización.

Dos equipos reciben el mismo identificador de clave. Uno consulta su almacén corporativo; el otro, un servidor público. Ambos obtienen una sola respuesta y ambos creen haber encontrado “la clave”. Si las respuestas no son la misma, ninguno de los dieciséis caracteres visibles explica la divergencia.

La interfaz convirtió una lista potencial en un registro singular. Ese detalle de producto importa más que el tamaño de la pantalla: borró la condición que OpenPGP dejó explícita. El identificador abre una búsqueda; no la cierra.

Jon Callas participó en la especificación de esta arquitectura. Su ficha de IETF enumera cinco RFC, entre ellas RFC 2440 y RFC 4880. La biografía publicada por ACLU relata una trayectoria en criptografía, ingeniería de software y diseño, pero sus cargos deben leerse como contexto fechado, no como empleo actual. La RFC 9580 que hoy sustituye a RFC 4880 fue escrita por otros autores.

Una reducción a 64 bits conserva ambigüedad

La RFC 4880 define el Key ID como ocho octetos y advierte que no se debe presuponer su unicidad. En una clave RSA versión 3 son los 64 bits bajos del módulo. En versión 4 son los 64 bits bajos de la huella. Dos procedimientos distintos terminan en el mismo espacio corto de valores.

La RFC 9580 mantiene la longitud y la advertencia. Para versión 4 conserva la parte baja de una huella SHA-1; para versión 6 toma la parte alta de una huella SHA-256. Por eso el campo necesita también una versión: el mismo nombre no implica la misma derivación.

Una colisión permite que dos paquetes distintos compartan el selector. No demuestra que se haya roto la firma ni que exista un atacante. El fallo práctico ocurre cuando el buscador descarta candidatos, el caché usa solo el Key ID o el sistema acepta el primer resultado sin comprobar el paquete completo.

Tampoco el material matemático ofrece un nombre estable entre versiones. Una clave RSA equivalente, serializada como versión 3, 4 o 6, puede adquirir huellas e identificadores diferentes. Registrar solo el fragmento corto impide reconstruir qué objeto se utilizó.

La huella necesita un canal

La huella completa es una referencia mucho más fuerte para un paquete de clave pública concreto. Debe calcularse sobre el paquete recuperado y compararse de forma mecánica. RFC 9580 cuestiona la fiabilidad de hacer que una persona lea y confronte cadenas largas; la mejora consiste en transportar la huella por un canal autenticado, no en sustituirla por un fragmento.

El origen de la huella esperada forma parte del resultado. Una configuración controlada, un directorio firmado y una conversación independiente no ofrecen la misma garantía que una página editable o el mismo servidor utilizado para descargar la clave. Una coincidencia exacta contra una referencia sin procedencia puede verificar con gran precisión el objeto equivocado.

Después queda la identidad. El paquete User ID contiene texto UTF-8, normalmente un nombre y un correo, pero no valida su contenido. Las firmas de certificación describen vínculos con intensidades distintas. Una certificación genérica no declara cuánto se comprobó; la de persona no declara comprobación; las modalidades casual y positive expresan revisiones más fuertes.

Ni el nombre ni la dirección convierten automáticamente al portador en empleado, representante o responsable. La parte que confía debe definir qué certificadores acepta, en qué ámbito y durante qué periodo.

Comprobar una firma no concede facultades

El subpaquete Issuer Key ID de una firma sigue siendo una pista de ocho bytes. RFC 9580 no permite usarla para claves posteriores a la versión 4 y recomienda incluir Issuer Fingerprint. Si ambas aparecen en una firma de versión 4, el identificador debe corresponder a los 64 bits bajos de la huella. La concordancia detecta incoherencias; no sustituye la resolución del paquete.

La operación criptográfica responde si una firma se verifica con una clave determinada sobre unos bytes determinados. Expiración, revocación, instante de evaluación, algoritmo admitido y key flags son comprobaciones posteriores y separadas. Una firma pudo ser válida técnicamente y estar fuera de la política aplicable.

La autorización empresarial está aún más lejos. La firma correcta de un manifiesto no demuestra que quien controla la clave tenga permiso para publicar, transferir fondos o cambiar una cuenta. Posesión, identidad certificada, función vigente y facultad concreta necesitan una cadena que el protocolo no puede inventar.

Un recibo que permite repetir la decisión

El recibo conserva primero el documento firmado y el paquete de firma exactos. Extrae el Key ID como indicio, registra todos los candidatos obtenidos y no oculta su orden ni su repositorio. Del candidato elegido guarda el paquete público, la versión y la huella completa calculada localmente, junto con la fuente y la hora de recuperación.

Luego identifica el User ID evaluado, las certificaciones y la regla de confianza; comprueba expiración, revocación, key flags y política algorítmica en el momento relevante; y anota el resultado criptográfico. La última columna es una decisión de autorización explícita con su propia fuente.

Si aparece un segundo candidato, no se borra. Si la huella llegó por un canal débil, se registra. Si el rol no está probado, queda sin afirmar. Así, dos equipos pueden explicar por qué llegaron a resultados distintos y corregir la entrada exacta que cambió.

Fuentes