Resumen

  • El grupo de trabajo OpenPGP abrió el 4 de septiembre una convocatoria de adopción para un borrador que marca el material secreto como externo y permite incluir una pista de localización. La consulta termina el día 18 y aún no tiene un resultado declarado.
  • La pista es orientativa: un receptor puede recurrir a búsqueda de mejor esfuerzo aunque exista, falle o resulte desconocida. La revisión 03 no define ningún esquema concreto, y el registro vigente de IANA todavía no contiene el valor External propuesto.
  • Llevar el stub conserva la referencia criptográfica, no el acceso operativo. Descubrimiento, autorización, resultado y recuperación necesitan un registro local separado y limitado por privacidad.

La decisión sigue abierta

La convocatoria enviada por Stephen Farrell dice que la discusión se había anticipado en IETF 126 y fija el 18 de septiembre como cierre. El objeto es draft-dkg-openpgp-external-secrets-03, una propuesta individual para representar material secreto alojado en hardware u otro subsistema que no entrega el secreto a la aplicación.

El Datatracker conserva una foto precisa: Call For Adoption By WG Issued en el grupo, I-D Exists ante el IESG, revisión 03 fechada el 22 de julio y vencimiento el 23 de enero de 2027. También advierte que un Internet-Draft individual no está avalado por el IETF.

Daniel Kahn Gillmor, Andrew Gallagher y Heiko Schäfer contestaron a favor. Paul Schaub confirmó su disposición a coeditar si el texto fuera adoptado. Sus intervenciones aportan razones y disponibilidad editorial; no son votos que permitan anticipar la constatación de consenso por parte de los presidentes.

Tampoco existe todavía la asignación solicitada. El texto propone de forma tentativa el octeto S2K 252 y un registro nuevo para las pistas. En el registro OpenPGP de IANA, actualizado antes de esta propuesta, no figura una entrada External ni el nuevo registro.

Identidad portable, localización aconsejada

RFC 9580 especifica cómo se estructura una clave secreta transferible. La revisión 03 conserva en el paquete los parámetros públicos y utiliza el nuevo valor para anunciar que los componentes secretos no están dentro. Tras el octeto puede aparecer una pista opcional sobre el subsistema externo.

La asociación utiliza la clave pública correspondiente. Si un token o servicio enumera material público coincidente, la implementación obtiene un candidato criptográficamente pertinente. Es mejor punto de partida que un nombre de dispositivo inventado para una sola máquina.

Pero la pista no manda. El borrador la llama enteramente orientativa. Sin pista se aplica el mejor esfuerzo. Si el consumidor no entiende el formato, o la ruta ya no conduce a un dispositivo útil, debe ignorar los datos desconocidos y puede buscar entre los mecanismos que sí soporta. Incluso ante una pista conocida mantiene esa libertad.

No hay en la revisión 03 un esquema de localización concreto. El borrador propone un registro inicialmente vacío, reserva 96–111 para uso privado o experimental y somete otras asignaciones a Specification Required. La estandarización crea el enchufe donde podrán encajar métodos futuros; no selecciona aún uno.

El mismo secreto puede tener más de una puerta

La falta de una dirección obligatoria no es descuido. Una clave puede residir en dos dispositivos. Un token USB cambia de ruta física al conectarse a otro puerto. Un identificador de ranura puede tener sentido en PKCS #11 y ser inútil para un TPM de plataforma. La URI de PKCS #11 resuelve bien la identificación dentro de su arquitectura, pero no convierte todos los subsistemas externos en uno solo.

Por eso “encontrado” es un resultado local. El dispositivo puede anunciar la parte pública y luego pedir PIN, huella, botón o contraseña. Puede denegar la operación, tardar demasiado o quedar bloqueado tras varios intentos. La aplicación puede no disponer del controlador aunque el dispositivo esté sobre la mesa.

“No encontrado” también es local. No demuestra que el secreto haya sido destruido, que nunca se generara o que no exista en otro dispositivo. Solo demuestra que una implementación no obtuvo la capacidad bajo un conjunto concreto de conexiones, proveedores y permisos.

El texto recomienda que enumerar claves públicas y probar la correspondencia no exija autorización. Para el uso secreto, en cambio, admite desafíos y analiza la caché de autorización. También pide mantener la interfaz receptiva, anunciar la interacción física, aplicar tiempos de espera sensatos y mostrar errores accionables.

Una migración debe separar entonces tres frases que suelen comprimirse en “la clave está disponible”: el stub se importó; se localizó un subsistema coincidente; se autorizó y completó la operación. Cada una tiene otra causa y otro responsable.

El hardware no absuelve al equipo anfitrión

Mantener el secreto fuera puede reducir la extracción. Algunos dispositivos limitan usos, muestran una acción al usuario o atestiguan que la clave nació dentro. Un token físico permite cambiar de ordenador sin copiar los parámetros secretos.

El borrador incluye la otra mitad. El hardware puede tener defectos y sufrir ataques físicos. Un anfitrión comprometido puede robar el texto claro o la clave simétrica de sesión después del descifrado. Para firmar, el usuario puede autorizar sinceramente mientras el software entrega al dispositivo un objeto distinto del mostrado.

En su respuesta, Gillmor afirma que el intercambio que supone el hardware no tiene sentido para casi todos los usuarios de OpenPGP, aunque apoya una representación sencilla para quienes lo quieren. Schäfer señala que ciertos contextos sí lo necesitan. Adoptar trabajo sobre interoperabilidad no equivale a recomendar la misma custodia a todo el mundo.

Un recibo de entrega fuera del paquete

La solución no es llenar el stub con inventario corporativo. Números de serie, cuentas de HSM, responsables, topología y reglas de recuperación cambian y pueden ser sensibles. El paquete global debe seguir siendo pequeño. La operación local puede mantener un recibo de entrega de clave externa por separado. Esta es mi propuesta editorial, no un requisito de OpenPGP ni del IETF.

El recibo protegido vincularía fingerprint del certificado y la subclave, versión del borrador o RFC, estado real del código, esquema de pista comprendido, implementación, clase de subsistema, hora, método de correspondencia, desafío de autorización, operación y resultado. Una sustitución debería enlazar la observación antigua y la nueva; no borrarla.

Hacia fuera basta con una referencia opaca, una clase de capacidad y un resultado verificado. Los seriales, PIN, biometría y ubicaciones permanecen bajo acceso controlado. El recibo no prueba propiedad ni concede permiso: documenta una observación para que la organización competente decida.

El Policy Mirror de Heng Lu ayuda a no confundir objeto, actor y regla. La especificación inicial mínima permite un núcleo común estrecho con evidencia local ampliable. Why BTW Media Exists impone el límite factual: la consulta sigue abierta, la asignación es propuesta y la capacidad universal no está demostrada.

El valor del stub está en su modestia. Puede decir qué secreto falta y ofrecer una pista. No debe fingir que sabe quién puede usarlo mañana.

Fuentes

  1. Convocatoria de adopción de OpenPGP
  2. Registro actual en Datatracker
  3. OpenPGP External Secret Keys, revisión 03
  4. Presentación de IETF 126
  5. Respuesta de Daniel Kahn Gillmor
  6. Respuesta de Andrew Gallagher
  7. Respuesta de Heiko Schäfer
  8. Respuesta de Paul Schaub
  9. Registro OpenPGP de IANA
  10. RFC 9580 — OpenPGP
  11. RFC 8126 — política de registros
  12. RFC 7512 — URI de PKCS #11
  13. Heng Lu — The Policy Mirror
  14. Heng Lu — Minimum Initial Specification
  15. Heng Lu — Why BTW Media Exists