Resumen

  • La prueba de posesión de RFC 10002 confirma que la entidad final dispone de la clave privada correspondiente a una clave pública y puede utilizarla. No acredita por sí misma la identidad, el derecho sobre un nombre ni la autorización para emitir.
  • CMC mantiene separados la prueba de identidad y el control de la clave, y exige un vínculo contra sustituciones. Las autoridades de registro añaden sus actos en envolturas externas; la autoridad certificadora conserva la evaluación de política y la decisión final.
  • Para investigar una emisión hacen falta recibos enlazados: solicitud firmada, método de posesión, evidencia de identidad, vínculo, cambios de cada intermediario, respuesta CMC, certificado exacto, entrega, instalación, validación y revocación.

Una solicitud puede pedir seis nombres alternativos, dos usos de clave y una vigencia determinada. Su firma puede ser impecable. Ninguna de esas dos observaciones obliga a que el certificado contenga los seis nombres, los dos usos o esa vigencia. Tampoco demuestra que el solicitante tenga autoridad sobre ellos.

La diferencia no es semántica: distribuye poder. La entidad final controla una clave. La autoridad de registro comprueba y encamina. La autoridad certificadora decide qué afirmar bajo su firma. Un servicio que confía en el certificado decide, a su vez, qué permite. Si un sistema resume todo como «solicitud válida», la primera comprobación termina hablando en nombre de actores que todavía no han actuado.

RFC 10002 define la estructura actual de Certificate Management over CMS. RFC 10003 especifica cómo transportar los mensajes, y RFC 10004 ordena los requisitos de conformidad para distintas clases de agentes. Las tres se publicaron en julio de 2026 y señalan a Joseph Mandel y Sean Turner como editores. CMC es una obra colectiva asentada sobre CMS, PKCS #10, CRMF y la infraestructura X.509; no es una creación individual de Turner.

Su perfil de IETF aporta una escala biográfica, no una autoridad transaccional. A 1 de septiembre de 2026 registraba participación desde IETF 34, más de 50 RFC como autor o coautor, el cargo de Security Area Director entre 2007 y 2014 y varias presidencias de grupos. Ese recorrido permite entender la continuidad del trabajo. No convierte a Turner en quien aprueba solicitudes para una autoridad certificadora concreta.

La firma conserva la intención del solicitante

En PKCS #10, el solicitante firma una estructura que contiene la clave pública, el sujeto y atributos. La verificación detecta modificaciones y evita que un tercero sustituya la clave pública manteniendo una firma válida. Es una forma de demostrar que quien creó la solicitud podía usar la clave privada correspondiente.

RFC 2986 no se detiene ahí. Describe que la autoridad certificadora autentica a la entidad solicitante, verifica la firma y, si la petición resulta válida, construye un certificado. Son acciones acumulativas. La firma no autentica automáticamente a la entidad ni decide la política que hace válida la solicitud.

RFC 10002 denomina Proof-of-Possession, POP, al conjunto de mecanismos que demuestran posesión y uso de la clave privada. Puede haber prueba por firma, desafío directo, prueba indirecta, publicación o atestación, con distintas reglas de uso. La diversidad no amplía la conclusión: la POP informa del vínculo con la clave.

Una clave robada puede producir firmas correctas. Un equipo puede estar bien identificado pero solicitar un nombre que pertenece a otro servicio. Una persona puede custodiar una clave sin tener delegación de su organización. Un proceso automático puede presentar una clave nueva con un inventario antiguo. En todos esos casos, la POP puede ser verdadera y la emisión seguir siendo improcedente.

El punto delicado es unir identidad y clave

CMC define la prueba de identidad como una función distinta. Cuando se necesita incluirla, una Simple PKI Request no basta. Una Full PKI Request puede transportar un testigo derivado de un secreto compartido, apoyarse en un certificado existente u ofrecer otro mecanismo acordado bilateralmente.

Que las pruebas viajen separadas permite auditarlas, pero también abre la posibilidad de mezclarlas. El sistema debe impedir que la identidad válida de una entidad se combine con la POP válida de otra. RFC 10002 exige garantizar que ambas proceden de la misma entidad. La asociación entre secreto y nombre, el testigo criptográfico o el enlace a un certificado previo forman parte de esa garantía.

La operación de enlace merece un estado propio. Debe conservar qué identificadores se asociaron, qué datos quedaron cubiertos, quién verificó, qué defensa contra sustitución se aplicó y cuándo. Dos resultados PASS sin un identificador común no forman una prueba conjunta.

El secreto compartido tampoco nace dentro de CMC. Su entrega fuera de banda queda fuera del alcance de la RFC. Si se distribuyó a la persona equivocada, se copió entre activos o se reutilizó durante demasiados intentos, un testigo correcto demuestra conocimiento del secreto, no una identidad perfecta. El registro debe expresar esa limitación.

La autoridad de registro no puede editar el pasado

La entidad final, la autoridad de registro y la autoridad certificadora tienen funciones distinguibles. Una autoridad de registro puede realizar comprobaciones locales, generar o archivar claves, agrupar solicitudes, encaminarlas o procesar extensiones. Además, puede aparecer como servidor ante la entidad final y como cliente ante la autoridad certificadora. Esa posición técnica no le transfiere la capacidad de emitir.

La solicitud interior firmada no se modifica. Alterar PKCS #10 o CRMF invalidaría la firma y la POP. Cuando la autoridad de registro quiere proponer otro campo o añadir una extensión, lo hace mediante controles en una envoltura exterior. Si existen varias autoridades de registro, cada una puede dejar una capa anidada.

Así se preservan dos declaraciones: lo que solicitó la entidad y lo que cambió el intermediario. El diseño evita una ficción habitual en sistemas administrativos, donde el último formulario sustituye al original y hace parecer que el solicitante pidió el resultado final.

Las extensiones muestran la consecuencia. RFC 10002 exige procesar las extensiones definidas, pero no obliga a incluir todas las solicitadas en el certificado. El servidor puede modificarlas sin invertir su significado. La autoridad certificadora tiene que comparar la petición, los controles externos, la plantilla permitida y su política. El certificado final documenta su decisión, no la aprobación previa del solicitante a cada cambio.

Un 2xx solo cierra la operación HTTP

RFC 10003 admite HTTP, ficheros, correo y TCP. En HTTP se usa POST con tipos de contenido específicos. HTTPS puede proteger el canal, pero la norma de transporte no exige que todos los clientes implementen autenticación HTTP. TLS, autenticación del transporte, prueba de identidad CMC y POP no son sustitutos.

El código HTTP tampoco resume el mensaje interior. Un 2xx indica que el servidor atendió la operación HTTP. La respuesta CMC puede quedar pendiente o señalar badIdentity, popRequired, popFailed o una extensión no soportada. Para afirmar emisión hay que leer ese estado y conservar el certificado devuelto.

Incluso entonces conviene comparar bytes: clave pública, sujeto, nombres alternativos, usos, políticas y vigencia. La respuesta debe llegar al destinatario previsto. Una interfaz que muestra «completado» antes de esa comparación confunde transporte, protocolo y objeto.

La conformidad de RFC 10004 vive en otro nivel. Demuestra que una implementación declara y satisface capacidades de una clase; no prueba adopción, buen funcionamiento en una organización ni aprobación de una transacción particular.

Después de emitir, la confianza sigue siendo condicional

RFC 5280 organiza la validación de rutas, anclas de confianza, restricciones de nombres, políticas, vigencia y estado de revocación. Es una fase posterior. La entrega, la instalación, la custodia de la clave y la autorización de una aplicación introducen más estados.

Un certificado emitido puede no instalarse. Uno instalado puede corresponder a otra clave. Una ruta válida puede terminar en un ancla que el servicio no admite. Un certificado criptográficamente válido puede identificar a un cliente al que la política local niega una acción. La revocación puede modificar mañana el resultado observado hoy.

La primacía del código en funcionamiento de Heng Lu sugiere conservar el material que permite repetir cada comprobación. En la fase de solicitud: bytes, POP, identidad, vínculo, envolturas y política. En la fase operativa: certificado, correspondencia de clave, destino, ruta, fuente de estado y decisión local.

El recibo final no es una sola fila. Incluye solicitante y hora; clave y campos pedidos; método y resultado de POP; método y límites de identidad; enlace entre ambos; cambios y firmantes de cada autoridad de registro; autoridad certificadora y versión de política; estado CMC; certificado exacto; entrega e instalación; revocación, sustitución y corrección.

La contribución de Turner y Mandel resulta valiosa porque deja espacio para esas decisiones. CMC prueba lo que puede probar y evita convertir una clave utilizable en una autorización universal.

Fuentes