Resumen

  • En RFC 10002, la petición firmada por la entidad final puede mantenerse intacta mientras una RA añade en una capa PKIData exterior testimonios de prueba o instrucciones para modificar campos.
  • Firma, prueba de posesión, prueba de identidad, testimonio de una RA, procesamiento de cambios y emisión por la CA son decisiones distintas; ninguna autoriza llamar «verificado» a todo el proceso.
  • La evidencia útil une la solicitud original, cada envoltura CMS, el alcance de cada RA, el orden de los controles, la política de la CA y el diff exacto del certificado finalmente emitido.

Una RA recibe una solicitud correcta y detecta que un atributo no se ajusta a la política corporativa. No toca los bytes firmados. Los envuelve, añade una instrucción de modificación, firma su propia capa y reenvía el conjunto. Más adelante, la CA descarta otra extensión y emite el certificado.

Si el sistema conserva solo la solicitud «normalizada» y el certificado, la actuación de la RA desaparece. Si conserva únicamente el resultado «firma válida», la decisión de la CA parece inevitable. En ambos casos, una arquitectura que permitía atribuir cada cambio acaba convertida en una caja negra administrativa.

RFC 10002, publicado por el IETF en julio de 2026 y sucesor de RFC 5272 y RFC 6402, define la estructura y los controles de Certificate Management over CMS. RFC 10003 define cómo se transportan los mensajes, y RFC 10004 reparte requisitos entre entidades finales, autoridades de registro y autoridades de certificación.

La firma delimita una afirmación, no el resultado entero

RFC 2986 organiza una petición PKCS #10 con el nombre del sujeto, su clave pública, atributos opcionales y una firma sobre esa información. Verificarla acredita la integridad de los datos protegidos y el uso de la clave privada de firma.

No acredita por sí sola que el solicitante tenga derecho al nombre, que posea otra clave incapaz de firmar, ni que la CA deba reproducir todos los campos. Tampoco concede autoridad a una RA.

Una Simple PKI Request de CMC puede ser el PKCS #10 sin más. Precisamente por eso no puede incluir la prueba de identidad ni los servicios avanzados, y no sirve para una clave privada que no firma. La petición completa introduce PKIData dentro de SignedData o AuthenticatedData de CMS.

RFC 5652 permite que CMS anide protecciones. Una RA puede colocar una capa firmada alrededor de contenido que ya estaba firmado. Así evita reescribir la petición PKCS #10 o CRMF y romper la prueba original. Con varias RA, aparecen varios niveles.

La capa interior permite saber qué protegió la entidad final. La exterior permite saber qué control añadió la RA. Aún falta comprobar que esa RA podía hacerlo, para ese campo y esa población.

Tener la clave y ser la persona declarada

Proof of Possession pregunta si el actor controla la clave privada asociada a la pública solicitada. Para claves de firma, una firma es una respuesta natural. Para claves de cifrado o establecimiento de claves, puede necesitarse un reto, una respuesta posterior o una confirmación. RFC 4211 define esas opciones en CRMF y reserva a la RA una declaración raVerified bajo condiciones específicas.

La prueba de identidad pregunta quién se asocia a la operación. Identity Proof Version 2 puede calcular un MAC sobre material de la petición mediante un secreto compartido. La antigua variante se conserva por compatibilidad; RFC 10004 establece la versión moderna como capacidad obligatoria.

Las dos pruebas pueden divergir. Un administrador puede controlar una clave y no estar autorizado para pedir el nombre de una filial. Un operador de registro puede confirmar un expediente laboral y no haber comprobado la clave del módulo criptográfico. Un indicador único elimina esa diferencia.

RA POP Witness permite que la RA declare ante la CA que realizó la prueba de posesión. RA Identity Proof Witness permite afirmar que verificó la identidad, incluso fuera de banda o con un secreto que la CA no conoce. La CA recibe una declaración delegada, no toda la prueba original. Debe conocer la RA, el método, el objeto, la vigencia de su mandato y la referencia a la evidencia subyacente.

Control Processed solo dice que un control fue tratado localmente o lo será después. Cuando importa cuál fue la prueba de identidad, RFC 10002 favorece el testimonio específico. «Procesado» no es una descripción suficiente de la confianza.

El cambio atribuible

Modify Certification Request autoriza a una RA a pedir que se reemplacen o eliminen campos. El diseño conserva la petición firmada en el interior y sitúa el cambio en una capa exterior también protegida.

La operación puede ser legítima: normalizar un nombre, retirar una extensión no permitida o adaptar un dato validado a la forma que exige la CA. La legitimidad operativa requiere conservar el body part afectado, el valor anterior, el propuesto, la regla y la identidad de la RA.

Las capas se procesan de dentro hacia fuera. Varios controles en el mismo nivel no tienen un orden definido por RFC 10002. Confiar en que el último elemento de una lista prevalece crea dependencia de la implementación. Si el orden cambia el resultado, la decisión debe consolidarse sin ambigüedad o separarse en capas ordenadas.

La CA toma todavía la decisión final. No está obligada a incorporar todas las extensiones solicitadas y puede modificar valores según su política, pero no puede invertir el sentido de una restricción pedida por el cliente. El certificado es un objeto nuevo firmado por la CA, no la copia certificada de la solicitud.

El control decisivo es comparar tres estados: la petición inmutable, los cambios de cada RA y el certificado. Toda diferencia debe señalar a un actor y una regla. La firma de la CA no explica por sí sola de dónde vino cada campo.

Una operación no termina en HTTP 2XX

RFC 10003 contempla archivos, correo y HTTP. Las solicitudes HTTP usan POST, y HTTPS protege el canal. El transporte no sustituye la semántica CMC: una respuesta 2XX no demuestra que todos los controles fueron entendidos ni que el certificado quedó emitido.

Una operación puede estar pendiente o completarse solo en parte. Query Pending permite continuarla; Confirm Certificate Acceptance mantiene estado después de entregar un certificado. Si el servidor final no reconoce o no puede procesar un control obligatorio, debe fallar todo el PKIData. Ignorarlo y devolver éxito fabricaría una conclusión que el mensaje no autoriza.

El identificador de transacción agrupa mensajes sucesivos. Los nonces de emisor y receptor ayudan a correlacionarlos y a detectar repetición. Siguen siendo necesarias reglas de idempotencia, pero sin este estado es difícil distinguir una retransmisión de una segunda solicitud.

RFC 10004 exige a las RA soporte para Modify Certification Request, Control Processed y RA Identity Proof Witness. Las CA creadas para trabajar con RA deben aceptar los controles correspondientes. La norma demuestra que el cambio y la delegación forman parte del modelo; no demuestra que un producto los ejecutó correctamente en un caso concreto.

El certificado emitido pasa luego al mundo de RFC 5280, donde las partes usuarias validan X.509 y consultan la política de la CA. La emisión no obliga a toda parte a confiar. RFC 7030 describe EST como otra arquitectura de matriculación, recordando que CMC es una elección técnica, no una autoridad inevitable.

Conservar la cadena sin conservar secretos

El expediente debe empezar por los bytes canónicos y el hash de la petición. Debe separar formato, clave, atributos, firma, método POP y método de identidad. Cada prueba conserva su verificador, objetivo, resultado, fecha, versión de política y referencia segura.

Por cada capa RA hacen falta la envoltura firmada, el certificado de la RA, el alcance de su mandato, los controles añadidos, cualquier capa retirada y el siguiente destinatario. Los cambios necesitan un antes y un después. Los testimonios deben nombrar la prueba que representan. No se registran claves privadas ni secretos compartidos sin procesar.

La CA añade su decisión por campo y el diff final. Transaction ID, nonces, reintentos, estados pendientes, aceptación, publicación y activación permanecen vinculados.

Esta evidencia permite reconocer un incidente sutil: una RA comprometida puede firmar una capa maliciosa mientras la solicitud original sigue siendo auténtica. No hubo falsificación de los bytes interiores, pero sí abuso de una autoridad válida. La revocación puede ser necesaria por esa razón.

Running-Code Primacy aporta un criterio editorial: el control existe en la realidad cuando el código valida la capa, verifica el alcance del actor y conserva la decisión. Minimum Initial Specification mantiene la mecánica compartida en su mínimo interoperable sin convertir a la RA en soberano de la política. La distinción entre capas de realidad y de símbolo impide que «firmado» o «emitido» se convierta en una promesa total.