Resumen

  • RFC 10004 asigna requisitos distintos a entidades, clientes, servidores, entidades finales, autoridades de registro y autoridades de certificación. Un mismo sistema puede ejercer varias funciones a la vez.
  • La conformidad útil debe quedar ligada a una versión, un grafo de funciones, condiciones activadas, algoritmos, configuración, recorrido de la transacción y resultado; no a una etiqueta comercial única.

El módulo criptográfico no podía firmar con una de sus claves. Durante años eso no afectó al perfil usado. Después, una nueva política movió la prueba de posesión a un intercambio de desafío y respuesta a través de una autoridad de registro. La ficha del producto seguía diciendo lo mismo. El conjunto de obligaciones ya no era el mismo.

No es un incidente real ni una afirmación sobre un HSM concreto. Es una forma de leer la RFC 10004: muchos requisitos dependen de la función y de una condición operativa. La conformidad no reside solo en el binario; también depende del uso que se activa.

CMC suele dibujarse como cliente y servidor. Si la entidad final habla directamente con la autoridad de certificación, el reparto parece sencillo. Al introducir una autoridad de registro, esta actúa como servidor frente al solicitante y como cliente frente a la CA. Se pueden insertar varias RA, el contenido puede determinar la ruta y no todas tienen por qué ver todas las solicitudes.

Por eso RFC 10004 organiza las obligaciones en seis clases que se solapan: todas las entidades, clientes, servidores, EE, RA y CA. Decir que un equipo “cumple CMC” sin nombrar esas funciones equivale a presentar una suma sin sus unidades.

La RFC 10002 define las estructuras y controles. La RFC 10003 define los transportes. RFC 10004 indica qué debe implementar cada clase. La ficha editorial y el registro de erratas delimitan la versión exacta de la evaluación.

Hay una base común. Todas las entidades deben soportar solicitudes PKI completas, respuestas simples y completas, CRMF y HTTP. Los servidores deberían soportar solicitudes simples y PKCS número 10. Pero la tabla de controles añade obligaciones diferentes y notas condicionales.

Una CA diseñada para trabajar con RA asume requisitos que no se desprenden de una prueba de laboratorio limitada a la ruta directa. Una EE debe soportar Response Body con mayor rigor si una RA valida la identidad o genera claves. Encrypted POP y Decrypted POP dependen del acuerdo de claves, de hardware que no firma o de cómo se delega POP. Cambiar la arquitectura puede convertir una capacidad antes irrelevante en condición de puesta en servicio.

El perfil de algoritmos también necesita contexto. RSA-SHA256 para SignedData, AES para EnvelopedData, AES-GCM con longitudes prescritas y transporte RSA forman el mínimo. DH, PBKDF2, AES Key Wrap y HMAC-SHA256 entran en caminos condicionales. El marco CMS procede de la RFC 5652, SHA-2 de la RFC 5754 y el cifrado autenticado de la RFC 5084.

El inventario de algoritmos no demuestra cuál se ejecutó. Tampoco prueba qué parámetros se usaron, qué control procesó cada agente o si la solicitud siguió el camino previsto. Capacidad, configuración y ejecución requieren registros distintos.

La prueba de posesión muestra la autoridad que falta. La CA debe imponer POP antes de emitir, aunque puede delegarla en una RA para casos delimitados. La RFC 6955 especifica una vía DH. El recibo necesario debe identificar la solicitud, el método, el agente, la regla de delegación y la decisión que recibió el siguiente actor.

También hay una época normativa. RFC 10004 sustituye a la RFC 5274 e incorpora la RFC 6402. Actualiza el suelo criptográfico desde opciones heredadas hacia SHA-256. Los algoritmos antiguos pueden ofrecerse por compatibilidad, pero la propia norma recomienda aprovechar las solicitudes CMC para localizar certificados que deban migrar.

Una compatibilidad permitida no es una garantía perpetua. Hay que saber qué cohortes dependen de ella, cuándo se usó y quién decide retirarla. De lo contrario, el requisito transitorio se convierte en bloqueo técnico.

La emisión tampoco cierra la cadena. La RFC 5280 gobierna la validación PKIX. Cumplir CMC no prueba identidad legal, derecho a un nombre, aceptación de la ruta, autorización de la aplicación ni resultado del servicio.

Las capas de realidad de Heng Lu separan la norma, la función disponible, la configuración, la transacción y el resultado. La primacía del código en ejecución exige observar lo ocurrido. La especificación inicial mínima mantiene pequeño el contrato común y atribuye las decisiones futuras al operador que las toma.

La evidencia adecuada es una matriz vinculada a la ruta. Debe conservar versión de software, RFC y erratas, funciones por enlace, opciones condicionales, algoritmos habilitados, política y configuración, RA atravesadas, controles ejecutados, decisión POP, respuesta y aceptación del certificado. Si ningún nodo posee una visión completa, la reconstrucción debe componerse con identidades y tiempos compatibles, no inventarse desde una marca verde.

Fuentes