Resumen

  • RFC 9810 reserva accepted para el caso en que el solicitante recibe exactamente lo pedido y usa grantedWithMods cuando recibe algo parecido cuyas diferencias debe averiguar.
  • Una transacción CMP autenticada no demuestra que sujeto, SAN, vigencia, Key Usage, EKU, restricciones o política del certificado conserven la intención autorizada.
  • Un recibo local de intención del certificado puede enlazar la plantilla solicitada, el objeto emitido, el delta material, la autoridad de cada cambio y la decisión de aceptar o rechazar sin guardar claves privadas. Es una propuesta editorial de Daniel Kade, no un campo de CMP.

Un sistema de alta suele tener una respuesta cómoda: verde o rojo. Verde significa que la autoridad contestó, que la protección del mensaje pasó y que llegó un certificado válido. Ese modelo oculta una bifurcación que RFC 9810 conserva deliberadamente. Una respuesta positiva puede ser exacta o puede venir con modificaciones.

grantedWithMods no acusa un fallo. Una autoridad de certificación puede aplicar su perfil, acortar la vigencia, normalizar un nombre, asignar el número de serie, rechazar una extensión o añadir un dato exigido por su política. La cuestión de gobierno aparece después: ¿quién comprobó que el certificado realmente emitido sigue sirviendo para el uso autorizado por el solicitante?

La CA firma su decisión, no una copia mecánica

RFC 9810 fue publicado en julio de 2025 como documento Standards Track del IETF. Define el protocolo CMP para crear y gestionar certificados X.509 entre entidades finales y componentes de PKI como autoridades de registro y de certificación. Sustituye a RFC 4210 y, junto con RFC 9811, también sustituye a RFC 9480.

La solicitud puede incluir un CertTemplate, estructura semejante a la parte que será firmada del certificado, con campos opcionales o situacionales. El cliente expresa así la clave pública, el sujeto, la vigencia o las extensiones deseadas. También puede pedir una plantilla previa para conocer qué espera la autoridad.

Esa precisión no obliga a la CA a reproducir cada campo. El propio RFC indica que puede modificar el certificado aun cuando el originador especificó por completo lo que quería. Por eso distingue accepted, “exactamente lo pedido”, de grantedWithMods, “algo parecido” cuyas diferencias son responsabilidad del solicitante.

El protocolo no entrega un veredicto universal sobre esas diferencias. Entrega un estado que conserva la necesidad de una decisión local. Si una interfaz junta ambos estados bajo “correcto” y despliega de inmediato, el software ejerce un poder que nadie le atribuyó de forma explícita.

Una diferencia puede cambiar para qué sirve la clave

RFC 5280 permite ver la sustancia del problema. La parte firmada contiene versión, serie, algoritmo, emisor, vigencia, sujeto, información de clave pública y extensiones. Un delta en esos campos puede ser administrativo, pero también puede cambiar identidad, duración o capacidad.

Key Usage distingue funciones como firma digital, cifrado, acuerdo de claves, firma de certificados y firma de listas de revocación. Extended Key Usage expresa propósitos adicionales. Basic Constraints separa una entidad final de una CA y puede limitar una ruta. Los nombres alternativos representan identidades de servicio. Las políticas de certificado dan contexto a quienes confían en el objeto.

No todo cambio exige el mismo tratamiento. La serie asignada por el emisor es normal. Un plazo más corto puede ser una mejora prudente. Una representación equivalente de nombre puede obedecer al perfil. En cambio, una EKU inesperada, otro SAN, una clave sustituida, capacidad de firmar certificados o una extensión crítica desconocida puede ampliar o alterar la autoridad.

RFC 9810 advierte expresamente que ciertas EKU de gestión de PKI delegan una autorización que originalmente reside en el certificado de la CA. La emisión es una acción sensible y la autoridad debe asegurarse de que solo la entidad legítima recibe ese uso. Aquí una diferencia de campo es una diferencia de poder.

La protección del mensaje responde otra pregunta

CMP usa protección de mensajes, identificadores de transacción y nonces. Según el perfil, puede apoyarse en secretos compartidos o firmas. La prueba de posesión demuestra control de la clave privada. Una RA puede validar y autorizar un mensaje, añadir protección, reenviarlo o modificarlo dentro del mecanismo previsto.

Esas propiedades impiden que cualquier respuesta sea tratada como auténtica. Sin ellas no habría base para comparar. Pero una respuesta de la CA correcta todavía puede contener un cambio que el dueño del servicio no aprobó. Autenticidad del canal y conformidad de la autoridad emitida son proposiciones diferentes.

Si una RA transforma la solicitud, la trazabilidad debe preservar qué vino de la entidad final, qué cambió la RA, qué firmó la CA y qué regla permitía cada modificación material. La etiqueta genérica “validado por RA” no basta: puede ocultar el punto donde se perdió una prueba o se amplió un uso.

Confirmar es aceptar un objeto concreto

El mensaje certConf permite aceptar o rechazar certificados. Para un certificado incluido, omitir statusInfo expresa aceptación. Omitir por completo su estructura de estado expresa rechazo; una secuencia vacía puede rechazar todos los certificados. También puede enviarse el hash del certificado con un estado explícito de rechazo.

La confirmación es más que el cierre ordenado de una conversación. Identifica el objeto que el solicitante está dispuesto a incorporar. La comparación debe realizarse contra el certificado recibido, no contra la expectativa de que una respuesta positiva “seguramente” coincide.

RFC 9483, el perfil ligero de CMP, muestra el flujo. Tras accepted o grantedWithMods, se envía certConf y se recibe pkiConf, salvo que la confirmación implícita haya sido solicitada y concedida. Si la confirmación esperada no llega, el sistema debe tratarlo como rechazo.

implicitConfirm ahorra una ida y vuelta. No autoriza a omitir la evaluación local. Cuando una flota lo usa, la lógica que compara campos debe existir antes de que la respuesta pase a instalación. De otro modo, una optimización temporal se convierte en consentimiento anticipado para cualquier modificación positiva.

La política asigna los derechos de modificación

RFC 3647 diferencia la política de certificado, que declara requisitos para una comunidad o clase de aplicaciones, de la declaración de prácticas de certificación, que explica cómo una CA opera sus controles. Esa capa institucional aclara por qué un cambio puede ser obligatorio, permitido o prohibido.

Imaginemos que la solicitud pide dos años y una sola EKU. El perfil de la CA limita la vigencia a un año y exige otra combinación para equipos gestionados. La emisión puede cumplir perfectamente la práctica publicada y ser inadecuada para el diseño local. La respuesta no se resuelve acusando a una parte; se resuelve demostrando si el solicitante había autorizado ese perfil.

Por eso el registro debe guardar el identificador y la versión del perfil. “Política de la CA” es demasiado impreciso cuando existen varias clases. También debe marcar los campos que pertenecen legítimamente al emisor, para no convertir diferencias esperadas en falsas alarmas. El objetivo es una asignación visible de competencia, no identidad binaria.

CT observa la emisión, no concede permiso de uso

Certificate Transparency registra la existencia de certificados de forma auditable. RFC 9162 permite vigilar la actividad de las CA y detectar emisiones sospechosas, pero aclara que los logs no impiden por sí mismos una emisión incorrecta.

Un certificado visible en CT no queda aceptado por su solicitante ni autorizado para producción. En una modalidad de prueba indirecta de posesión, RFC 9810 incluso prohíbe publicar el certificado final en CT antes de recibir el certConf que completa esa prueba. La secuencia distingue emitir, confirmar y publicar.

Después aparece otra separación. Un certificado confirmado puede no instalarse. Uno instalado puede quedar limitado a un servicio. Las partes que confían pueden rechazarlo por su propia política. La observabilidad pública es valiosa, pero no absorbe esas decisiones.

El recibo de intención conserva el delta

El recibo de intención del certificado propuesto guarda identificadores canónicos de la solicitud protegida, el CertTemplate, el perfil y el certificado emitido. Registra la transacción y el estado, pero excluye claves privadas, secretos, paquetes de clave descifrados y documentación de identidad innecesaria.

La comparación normalizada cubre clave pública, sujeto, SAN, vigencia, Key Usage, EKU, Basic Constraints, políticas, restricciones, criticidad y extensiones de las que depende la aplicación. Cada delta material se clasifica: esperado por perfil, aprobado por una función competente, rechazado o pendiente. Se conserva la versión del evaluador y de la política.

El recibo separa aceptación, publicación y despliegue. Señala si la confirmación fue explícita o implícita, quién podía aceptar para esa clase de servicio, cuándo vence una excepción y cuál es el objetivo de reversión. Si hay revocación o reemisión, la corrección añade un nuevo estado sin borrar el anterior.

Debe ser local y de acceso limitado. Los nombres internos, identificadores de equipos y excepciones pueden revelar una cartografía sensible aunque el certificado sea público. CT ya ofrece una superficie pública con propósito definido; el recibo conserva la genealogía de la decisión dentro de la organización.

El resultado operativo no nace del código de estado

La doctrina de Heng Lu separa especificación, decisión localizada, adopción, ejecución y resultado observado. CMP define la gramática. La CA decide qué firma. El solicitante decide qué acepta. El operador decide dónde instala. Las partes usuarias deciden si confían. Ninguna capa anterior puede hablar por todas las siguientes.

La primacía del código en ejecución exige observar la transición real. Si la política exige una comparación y el cliente convierte ambos estados positivos en un solo “sí”, el código ha borrado la frontera de responsabilidad. El Policy Mirror recuerda que una regla bien escrita no prueba su cumplimiento.

La solución no es revisión humana obligatoria para cada certificado. Es automatización fiel: diferencias esperadas autorizadas por perfil, cambios prohibidos rechazados, excepciones con dueño y caducidad, y despliegue como decisión separada. El estado verde puede cerrar el intercambio; no debe inventar el permiso.

Fuentes