Resumen

  • RFC 9883 permite que una clave de firma certificada respalde una declaración para otra clave de establecimiento.
  • La declaración es una afirmación de posesión, no una prueba técnica de la clave privada nueva.
  • La CA debe validar la ruta del certificado firmante y la firma de la solicitud; las diferencias de identidad se resuelven conforme a una política de equivalencia.

La trampa operativa es confundir dos preguntas: una firma válida demuestra quién autorizó el mensaje; no demuestra quién controla la clave privada incluida en la nueva solicitud. El atributo privateKeyPossessionStatement transfiere una parte de la confianza de una clave ya certificada a otra clave, mediante una afirmación firmada.

El OID del atributo es 1.3.6.1.4.1.22112.2.1. Su estructura completa es PrivateKeyPossessionStatement ::= SEQUENCE { signer IssuerAndSerialNumber, cert Certificate OPTIONAL }: signer identifica el certificado de firma por emisor y número de serie, mientras que el campo opcional cert contiene ese certificado. Este último solo puede omitirse cuando la CA también es la emisora del certificado de firma y puede recuperar todos los certificados válidos que emitió. Es una excepción limitada de recuperación, no una licencia para inferir la identidad.

La CA debe validar la ruta de certificación del certificado de firma y rechazar la solicitud si la ruta no es válida. También debe validar la firma de la solicitud con la clave pública de ese certificado y rechazar un fallo. El nombre del sujeto y los SAN deberían coincidir con los del certificado firmante. Si son diferentes, la política de certificados debe explicar la equivalencia; si la CA no puede establecerla, debe rechazar la solicitud. El atributo no puede utilizarse para obtener un certificado de firma.

En PKCS#10, subjectPublicKeyInfo contiene la clave pública de establecimiento, los atributos contienen la declaración y la firma de la solicitud se valida con el certificado de firma. En CRMF, la solicitud contiene el sujeto y la clave pública de establecimiento; la prueba de posesión del formato usa la opción de firma y la identidad del remitente, mientras regInfo transporta la declaración. La misma intención no implica una estructura de codificación idéntica.

RFC 5280 aporta la base para la ruta de certificación y los usos de clave. RFC 6955 sirve como contraste: describe mecanismos que proporcionan prueba técnica de posesión para claves Diffie-Hellman. RFC 9883 no convierte su atributo en una prueba criptográfica de la segunda clave privada. Su objeto también difiere de RFC 9881, sobre identificadores ML-DSA en PKIX, y de RFC 9882, sobre los bytes firmados en CMS.

Análisis de Theo March: puede entenderse la clave de firma como una raíz delegada de aseguramiento. Esa es una interpretación operativa, no un mandato de RFC 9883. Conviene enlazar en auditoría cada certificado derivado con el certificado autorizador, registrar la decisión de equivalencia y vigilar volumen por firmante, cambios de identidad, repeticiones y errores. Así se hace visible la transferencia.

La dependencia tiene efecto sobre la revocación. RFC 9883 señala que, si se compromete el certificado de firma, la revocación oportuna es la única protección identificada, y que la CA debería revocar los certificados de establecimiento obtenidos mediante declaraciones firmadas por ese certificado. El inventario de derivados, la propagación automática y la secuencia de alertas son análisis de Theo March, no un esquema obligatorio. La clave de firma debería tener una fuerza de seguridad al menos igual a la de la clave de establecimiento. En una migración, hay que probar paridad, algoritmos y equivalencia de sujetos y SAN.

Casos de prueba concretos: ruta y firma válidas; ruta inválida; firma modificada; certificado ausente cuando la CA no es emisora; certificado omitido con recuperación válida; sujetos o SAN distintos con equivalencia documentada y sin ella; intento de pedir un certificado de firma; firmante más débil; y mensajes PKCS#10 y CRMF verificados en sus ubicaciones específicas. Registrar emisor, serie, huellas de solicitud y clave, decisión de política y certificado emitido.

Ante un incidente, detener la emisión del certificado firmante sospechoso y conservar las evidencias. Confirmar el alcance, revocar pronto el certificado de firma, enumerar todos los certificados derivados por sus declaraciones y revocarlos conforme a la política de la CA. Después, renovar las claves necesarias, revisar las decisiones de equivalencia y fuerza, y vigilar nuevos intentos o repeticiones. Este camino es análisis operativo, no un flujo completo impuesto por RFC 9883.

Fuentes