Summary

  • RFC 10003 normaliza HTTP, archivos, correo y TCP para transportar CMC. El resultado del canal y el estado de la operación certificadora son hechos distintos.
  • Un HTTP 2XX, un mensaje aceptado por correo, un archivo presente o una escritura TCP terminada no demuestra que la CA o la RA haya concedido la petición ni que el certificado correcto esté activo.
  • Daniel Kade propone un recibo de transporte a decisión que una evidencias acotadas del canal con la respuesta CMC validada, el ciclo pendiente, la huella del certificado emitido y la instalación.

El acuse de recibo no firma la resolución

Una plataforma envía una solicitud de certificado y recibe HTTP 200. El monitor de red registra éxito. El orquestador cambia el estado a «emitido» y continúa con la rotación. El problema no está en el 200: está en la autoridad que el sistema le atribuyó.

RFC 10003 especifica cómo mover mensajes de Certificate Management over CMS. Incluye cuatro mecanismos: HTTP, archivos, correo electrónico y TCP. RFC 10004 exige que todas las entidades CMC implementen HTTP y deja los demás como opciones. La normalización permite que cliente y servidor coincidan en método, envoltura, tipos de contenido y secuencia.

La decisión vive en otro lugar. RFC 10002 define la respuesta PKI y sus estados. Una respuesta completa puede indicar éxito, fallo, espera, resultado parcial, operación no admitida, confirmación requerida o una prueba adicional. La emisión diferida puede necesitar varias rondas. Por tanto, finalizar un intercambio de transporte no equivale a cerrar la transacción certificadora.

El mensajero puede entregar el expediente y traer una respuesta; no decide su contenido.

Qué prueba realmente un 2XX

En HTTP, RFC 10003 ordena usar POST y reserva los códigos 2XX para respuestas exitosas. También fija la representación binaria y el Content-Type. Una solicitud PKI completa lleva application/pkcs7-mime; smime-type=CMC-Request; la respuesta completa cambia el parámetro a CMC-Response. Las formas simples tienen identificadores propios.

Con ello es posible construir una evidencia precisa de transporte: URI, método, instante, código, tipo declarado, referencia de política TLS y huellas de los cuerpos. El registro puede confirmar que un endpoint determinado recibió una petición y devolvió bytes con forma esperada.

No puede afirmar por sí solo que la operación fue concedida. Un 2XX puede transportar un estado CMC failed, pending o partial. El servidor HTTP hizo correctamente su trabajo al devolver una respuesta; la CA pudo rechazar la solicitud o aplazarla. La semántica HTTP y la semántica CMC no compiten: responden preguntas distintas.

Un código distinto de 2XX tampoco debe etiquetarse automáticamente como «rechazado por la CA». Quizá falló un proxy, la ruta, una autenticación de canal o el tratamiento del tipo de contenido antes de que la lógica CMC actuara. Si no hubo decisión, el registro debe decir «sin decisión observada».

Pendiente significa que la obligación continúa

Los sistemas de automatización prefieren estados terminales. CMC conserva estados que obligan a volver. Para pending y partial, PendInfo aporta un token y una hora sugerida de consulta. El solicitante es responsable de sondear. Cuando hay identificador de transacción, se mantiene hasta que una respuesta completa la cierre.

Ese diseño impide interpretar la espera como éxito anticipado. El primer recibo debe registrar que el canal funcionó y que el proceso sigue abierto. El recibo posterior debe enlazar la nueva consulta con el token, la transacción y la respuesta que resuelve el estado. Si el sondeo nunca ocurre, el hecho durable es una transacción abandonada, no una emisión silenciosa.

La repetición también necesita identidad. POST no es idempotente; RFC 10003 prohíbe 0-RTT cuando una implementación CMC usa TLS 1.3 o QUIC. Después de perder una respuesta, reenviar puede producir dos entregas. Sin hash, nonce e identificador de transacción, el operador no sabrá si ve un reintento, una repetición hostil o una nueva orden autorizada.

El falso atajo cambia con cada portador

En transporte por archivo, cada fichero debe contener una sola solicitud o respuesta binaria, y la especificación recomienda extensiones. La aparición de un archivo demuestra una escritura en un lugar. No demuestra que el receptor lo haya abierto, validado o aprobado. La extensión ayuda a identificar la forma; no certifica el contenido.

El correo usa envolturas MIME, nombres de fichero, tipos de medio y ejemplos base64. Un Message-Id, una aceptación SMTP o la llegada al buzón son hechos del correo. Todavía falta verificar el mensaje CMC. Además, RFC 10003 advierte que TLS con el primer agente de envío no garantiza autenticación ni cifrado en los siguientes saltos. REQUIRETLS puede pedir protección autenticada en los relés compatibles, pero también causar no entrega cuando alguno no soporta la extensión.

En TCP, los mensajes viajan en binario sin una envoltura adicional. El servicio pkix-cmc usa el puerto 5318 y el cliente debe esperar la respuesta completa antes de enviar otra petición por la misma conexión. Un socket abierto o una escritura completa no dice si el cuerpo resultante es auténtico ni qué estado contiene.

El control común no consiste en fingir que los cuatro canales producen la misma telemetría. Consiste en impedir que cualquiera de ellos se atribuya la resolución PKI.

Proteger el mensaje no borra la ruta

Las estructuras CMS pueden dar integridad, autenticación y confidencialidad al objeto. HTTPS puede proteger la conexión. IPsec, EnvelopedData o AuthEnvelopedData ofrecen otras combinaciones. Cada mecanismo debe conservar el alcance exacto de su afirmación.

TLS no demuestra que el firmante estuviera autorizado para solicitar esos nombres, que la RA verificara la identidad o que la CA aprobara el perfil. Un mensaje CMS íntegro, por su parte, no indica sin evidencia adicional qué endpoint se usó, qué intermediario falló ni a qué intento corresponde la respuesta.

RFC 10003 también aclara que los clientes no tienen que implementar autenticación HTTP ni cookies. Los servidores no pueden suponer que existen. La confianza inicial y la política de emisión permanecen fuera de la simple mecánica de transporte.

Por eso un informe serio evita frases como «entregado de forma segura» sin sujeto ni capa. Puede decir «canal TLS validado», «objeto CMS autenticado», «solicitante autorizado», «respuesta CMC concedida», «certificado instalado». Esas proposiciones se pueden probar por separado.

Un recibo de transporte a decisión

Propongo un recibo CMC de transporte a decisión. Es una herramienta editorial de Daniel Kade, no una obligación del IETF ni de RFC 10003.

Su primer bloque registra el portador. En HTTP incluye endpoint, método, hora, código, tipo de contenido, referencia de política TLS y hashes acotados. En correo conserva el identificador de envío, destino, estado observado y alcance de la política de relé. En archivo o TCP identifica canal, dirección, tiempo y huella. No guarda cuerpos, credenciales ni topología sensible.

El segundo bloque acredita la interpretación: solicitud y respuesta simple o completa, identificador de transacción, referencias a las partes afectadas y resultado de integridad o autenticidad. Bytes recibidos pero no interpretados no son una decisión.

El tercero conserva los estados tal como son. pending mantiene una referencia protegida al token, el momento de consulta y el sondeo posterior. partial enumera de forma acotada lo resuelto y lo abierto. Un fallo incluye información útil sin copiar pruebas de identidad a paneles generales.

El cuarto aparece únicamente si existe un certificado emitido. Une su huella, emisor, serie, clave pública, nombres y vigencia a la solicitud. No presupone el orden de los certificados de la respuesta ni confía en uno autofirmado solo por estar incluido.

La instalación constituye un quinto hecho. El dispositivo puede cargar una cadena equivocada, mantener el certificado anterior o no activar el nuevo. Una sonda de parte usuaria confirma qué huella se presenta realmente y en qué momento.

El último estado demostrado

La gobernanza debería preguntar «¿qué etapa está probada?» en lugar de «¿está verde?». Un equipo de red prueba el intercambio. La implementación CMC prueba que decodificó y verificó la respuesta. La CA responde por la emisión. El propietario del sistema responde por la instalación. El servicio consumidor observa la aceptación.

Las alertas deben buscar uniones rotas: 2XX con cuerpo inválido, fallos CMC convertidos en éxito, tokens sin consulta posterior, cuerpos duplicados bajo transacciones distintas, certificado que no coincide con la clave o nombres esperados, emisión sin instalación y servicios que siguen presentando la credencial vieja.

Reducir todos estos verbos a «enrollment succeeded» premia la rapidez del primer sistema que contesta y oculta la demora de los demás. La métrica responsable es la proporción de transacciones para las que puede reconstruirse el último hecho cierto.

RFC 10003 ofrece carreteras compatibles para CMC. La disciplina de gobierno empieza al reconocer que llegar a destino no es obtener una decisión favorable.

Fuentes

  1. Lu Heng — Soberanía de datos: realidades técnicas y prácticas
  2. Lu Heng — Por qué existe BTW Media
  3. Lu Heng — Primacía del código en ejecución
  4. RFC 10003 — Protocolos de transporte CMC
  5. RFC 10002 — Certificate Management over CMS
  6. RFC 10004 — Requisitos de conformidad CMC
  7. RFC 5273 — Especificación anterior de transporte CMC
  8. RFC 5967 — Tipo de medio application/pkcs10
  9. RFC 8551 — Especificación S/MIME 4.0
  10. RFC 9110 — Semántica HTTP
  11. RFC 9205 — Construcción de protocolos con HTTP
  12. RFC 9325 — Uso seguro de TLS y DTLS
  13. RFC 8446 — TLS 1.3
  14. RFC 9000 — QUIC
  15. RFC 8689 — Opción SMTP REQUIRETLS
  16. RFC 3207 — SMTP seguro sobre TLS