Resumen
- RFC 9883 permite que una clave de firma ya certificada respalde una declaración de posesión sobre una clave privada distinta, destinada al establecimiento de claves, sin probar técnicamente esa posesión.
- La CA debe validar el certificado firmante, la firma y la identidad, además de aplicar una política que autorice expresamente la sustitución.
- Si la clave de firma se compromete, la respuesta alcanza a todos los certificados de establecimiento emitidos a partir de sus declaraciones.
En el expediente aparecen un CSR firmado, una clave pública nueva y un atributo cuyo nombre promete posesión. Sin embargo, la operación criptográfica la ejecutó la clave privada del certificado anterior. La clave privada asociada a la nueva clave pública no produjo ninguna prueba.
La secuencia de dos credenciales
El sujeto genera primero un par de firma, firma una solicitud normal y obtiene un certificado con uso de firma. Después genera un par de establecimiento. En la segunda solicitud PKCS#10 incluye la clave pública nueva y privateKeyPossessionStatement, identifica el certificado de firma por emisor y número de serie, y firma el conjunto con la clave privada anterior.
RFC 9883 define la semántica con una franqueza poco habitual: el sujeto declara, sin aportar prueba, que posee la clave privada de establecimiento. La CA puede admitirlo solo si su política de certificados lo permite. RFC 6955 ofrece pruebas técnicas para ciertos casos DH y ECDH, pero no encaja en PKCS#10 ni abarca KEM como ML-KEM. La declaración nueva puede viajar tanto en PKCS#10 como en CRMF.
El resultado separa dos hechos. La firma correcta demuestra control de la clave de firma en esa solicitud. También enlaza una identidad certificada con la afirmación. No demuestra que la clave de establecimiento exista en un dispositivo concreto, que no sea exportable, que no se haya perdido o que vaya a funcionar cuando se use el certificado.
La política no es un campo decorativo
Antes de emitir, la CA debe validar la ruta del certificado de firma conforme a RFC 5280 y verificar la firma de la solicitud. Debe rechazar cualquier fallo. Los nombres de sujeto deberían coincidir; si no coinciden ellos o los nombres alternativos, la política debe explicar cómo se determina que designan a la misma entidad. Si esa identidad no puede establecerse, la solicitud se rechaza.
El atributo puede contener el certificado de firma o solo su emisor y número de serie. Cuando el emisor es el mismo, se puede omitir el certificado, pero eso supone que la CA dispone de un mecanismo capaz de recuperar todos los certificados válidos que emitió. Esa recuperación es una condición operativa observable. El localizador no sustituye al certificado, a la ruta validada ni al estado que tenía en el instante de la decisión.
PKCS#10 inserta la clave nueva y el atributo dentro de la información firmada. CRMF exige el camino de firma en ProofOfPossession, poposkInput, el identificador del remitente y una copia de la clave pública, y guarda la declaración en regInfo. Son envoltorios distintos para la misma frontera: la clave de establecimiento sigue sin ejecutar la prueba.
Por eso el atributo no se puede usar para solicitar un certificado de firma. Una clave capaz de firmar puede demostrar directamente su posesión al firmar su propio CSR. La excepción solo responde al problema de las claves de establecimiento.
La emisión crea un grafo de revocación
Quien robe la clave de firma podrá generar afirmaciones nuevas. La protección descrita es la revocación oportuna del certificado de firma. Si la CA lo revoca por compromiso, RFC 9883 recomienda revocar también los certificados de establecimiento obtenidos mediante declaraciones firmadas por él.
No basta con guardar un resultado “firma válida”. La CA necesita un índice inverso que conecte la credencial firmante, los bytes de la solicitud, la política aplicada, la decisión de identidad y cada certificado emitido. Además, la clave firmante debería tener al menos la misma fortaleza que la de establecimiento para que el puente no rebaje la seguridad.
Fuentes
- https://www.rfc-editor.org/rfc/rfc9883.html
- https://www.rfc-editor.org/errata/eid8687
- https://www.rfc-editor.org/rfc/rfc2986.html
- https://www.rfc-editor.org/rfc/rfc4211.html
- https://www.rfc-editor.org/rfc/rfc5280.html
- https://www.rfc-editor.org/rfc/rfc6955.html
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance

