Resumen

  • La portabilidad de CMC resuelve cómo se mueve un objeto, no quién puede decidir su efecto.
  • RFC 10003 ofrece evidencia precisa de archivo, correo, HTTP y TCP; la prueba de autoridad exige un registro distinto.

Una misma solicitud no adquiere una identidad distinta por cambiar de envoltorio. Puede quedar en un archivo binario, pasar por correo, entrar en un POST HTTP o recorrer una conexión TCP. Esta versatilidad es el trabajo de RFC 10003. La norma actualiza los transportes de CMC y da a cada uno un comportamiento operativo definido. No declara que un canal sea una autoridad de certificación ni que la recepción técnica del objeto cierre el proceso de certificación.

El perfil de archivo es la demostración más limpia. Un archivo contiene una petición CMC binaria o una respuesta CMC binaria. Ese archivo permite conservar, entregar o inspeccionar un objeto determinado. Lo que no puede aportar por sí solo es el contexto de decisión: qué institución recibió la solicitud, qué rol estaba facultado para actuar, qué controles se aplicaron o si existió un certificado como resultado.

HTTP tampoco borra esa diferencia. RFC 10003 usa POST del cliente y considera una respuesta 2XX como procesamiento exitoso del transporte. Para observabilidad, esto es una pieza valiosa: el cliente presentó el objeto y el servidor completó la interacción de la forma prevista. Convertirla en “certificado aprobado” añade hechos que el estado HTTP no contiene. La respuesta de CMC puede conducir a pruebas posteriores; el código de transporte no sustituye esas pruebas.

TCP define otra clase de orden, no otra fuente de legitimidad. Los mensajes binarios se transmiten sin una envoltura adicional y el cliente debe esperar la respuesta completa antes de cursar la siguiente solicitud por esa conexión. El puerto de servicio registrado facilita el descubrimiento de un servicio CMC. Ni la secuencia correcta ni un puerto abierto identifican por sí mismos al titular de la autoridad de certificación.

La especificación incluso dibuja límites que una lectura simplista suele ignorar. HTTP no exige autenticación HTTP ni cookies. En TLS 1.3 o QUIC no se permite 0-RTT para solicitudes CMC sobre HTTP, porque POST no es idempotente. La defensa frente a repeticiones puede depender del entorno. Cada límite habla de comportamiento de transporte y del riesgo de repetir una acción; ninguno convierte el transporte en la política que autoriza la acción.

En correo, el límite se extiende a la ruta. TLS en el primer salto SMTP no permite afirmar que los saltos posteriores estén autenticados o cifrados. CMS o S/MIME pueden resguardar el contenido, algo importante, pero una envoltura confidencial no lleva dentro una atribución automática de autoridad. La institución que toma la decisión debe seguir siendo visible como institución, no inferida del contenedor.

La consecuencia práctica es pequeña en diseño y grande en auditoría: mantenga los hechos de transporte y los hechos de decisión en campos distintos. El primero puede probar qué se envió y qué volvió. El segundo debe probar quién decidió, bajo qué reglas y cuál fue el resultado de certificado que una parte usuaria puede aceptar.