Resumen

  • Con RFC 9908, el servidor EST puede fijar valores, exigir tipos de campo y dejar huecos para que el cliente complete una futura solicitud PKCS #10.
  • La respuesta prueba una instrucción de construcción; la firma, la posesión de la clave, la autenticación, la autorización de la CA, el certificado emitido y su uso necesitan registros propios.

Antes de que el dispositivo hubiera enviado una CSR, el portal ya mostraba «identidad aprobada». La única evidencia era la respuesta de /csrattrs: contenía una unidad organizativa fija, un nombre común por completar, un requisito de curva P-256 y una extensión de nombre alternativo con un campo vacío. El servidor había descrito una solicitud útil. No había autenticado todavía la petición de inscripción, comprobado la firma, autorizado esos nombres ni producido un certificado.

El ejemplo es deliberadamente hipotético. Señala un riesgo de diseño: cuando una instrucción llega codificada y firmemente estructurada, la organización puede confundirla con el poder de decidir. RFC 9908 reduce la ambigüedad técnica; el sistema de control debe evitar crear una ambigüedad institucional nueva.

La norma actualiza RFC 7030, que define Enrollment over Secure Transport, y RFC 9148, su adaptación a CoAP. EST ya ofrecía /csrattrs para que el cliente conociera los atributos esperados por el servidor o la CA. No existía una interpretación universal de cómo transportar valores concretos, en especial valores de extensiones X.509. RFC 9908 aclara la forma existente y añade una plantilla explícita.

CertificationRequestInfoTemplate se parece a la información de una solicitud PKCS #10, pero carece de la envoltura de firma y permite omitir campos con significado. Es una pieza previa a la solicitud completa. El parecido no la convierte en CSR y mucho menos en certificado.

Si el servidor no tiene requisitos sobre el nombre distinguido, omite subject. Si necesita un tipo de RDN, lo incluye. Cuando acompaña ese tipo con un valor, espera que el cliente lo conserve; cuando deja el valor vacío, espera que el cliente proporcione uno adecuado. En subjectPKInfo, la ausencia expresa que no se impone ahí una condición de clave. La presencia indica el algoritmo esperado, y una clave pública de relleno puede expresar la longitud requerida de un módulo RSA.

La extensión id-aa-extensionReqTemplate hace posible la misma distinción para las extensiones. El servidor identifica la extensión y puede entregar su valor, omitirlo o dejarlo parcialmente preparado. Un SAN puede combinar un nombre decidido por el servidor con una dirección que completará el cliente. Ese mecanismo responde, entre otros, al caso del Autonomic Control Plane de RFC 8994, donde el servidor necesita transmitir un subjectAltName concreto.

La mejora mantiene la estructura CsrAttrs en el cable. El modelo usa la versión v1 y no puede incluir dos atributos id-aa-extensionReqTemplate, ni mezclar ese atributo con id-ExtensionReq. La aclaración también alcanza el transporte CoAP. Son límites de sintaxis e interoperabilidad, no afirmaciones sobre la legitimidad de una identidad.

RFC 7030 mantiene una frontera contundente. Consultar los atributos es opcional y el servidor normalmente no debería exigir autenticación o autorización para responder a esa consulta. Con independencia de la respuesta, el servidor EST y la CA pueden rechazar después la inscripción por cualquier motivo. Saber qué formato se espera no equivale a superar la política de emisión.

La solicitud firmada abre otra fase. El servidor autentica al cliente y decide si está autorizado a usar el servicio pedido. La firma de la CSR proporciona prueba de posesión cuando la clave privada puede firmar. EST puede enlazar además esa prueba con la sesión TLS autenticada. RFC 5272 aporta el marco CMC más amplio para las pruebas de posesión y los controles de gestión de certificados.

Conviene formular tres preguntas separadas. ¿Controla el solicitante la clave privada? ¿Qué identidad fue autenticada en el canal de inscripción? ¿Puede esa identidad recibir un certificado con esos nombres, extensiones y usos? Una respuesta positiva a la primera no concede un nombre DNS; una respuesta positiva a la segunda tampoco autoriza todo el contenido propuesto.

La política local de la CA controla siempre la emisión. RFC 7030 permite incluso enviar una solicitud a revisión manual y responder 202 mientras la decisión queda pendiente. PKCS #10 explica que la CA autentica al solicitante, verifica la firma y, si considera válida la petición, construye el certificado usando la solicitud, sus propias elecciones y otra información. La CSR correcta puede ser rechazada, demorada o modificada por política.

El certificado firmado es un artefacto distinto y debe conservarse como tal. Su número de serie, vigencia, emisor, extensiones y restricciones no se prueban mediante la plantilla. Un cotejo entre la plantilla, la CSR final, la decisión y el certificado permite saber qué dato fue impuesto, completado, aceptado, cambiado o añadido.

Tampoco la emisión demuestra despliegue. RFC 5280 define el perfil X.509 y la validación de rutas que aplicarán después las partes confiantes. Un certificado puede permanecer sin instalar, terminar en el equipo equivocado, coexistir con otro o no superar la política del receptor. El inventario y los intercambios observados son capas posteriores.

Por eso el expediente mínimo no debería ser un estado «correcto», sino una secuencia enlazada. Debe guardar la respuesta exacta de /csrattrs, la identidad del servidor, la hora, la vigencia de caché y el hash de la plantilla. Debe marcar los valores fijos, los huecos del cliente y las ausencias. Luego debe enlazar la CSR terminada, la validación de firma, la prueba de posesión, la identidad autenticada, la versión de política, la decisión, la huella del certificado, el destino de instalación y la observación de uso.

La semántica negativa es importante. Si un campo no está en la plantilla, el servidor no formuló allí una exigencia; no demostró que cualquier valor futuro esté permitido. Si el servidor entrega un SAN fijo, queda probado que indicó al cliente que lo solicitara, pero no de dónde surgió el derecho sobre ese nombre. La procedencia debe figurar en la autorización, fuera del ASN.1.

La compatibilidad también tiene un plano operativo. Que el formato conserve la estructura de cable no garantiza que cada cliente antiguo comprenda los nuevos atributos. Antes de publicar plantillas enriquecidas hay que inventariar versiones, observar fallos y prohibir que los clientes descarten silenciosamente condiciones desconocidas. La vía heredada debe ser una decisión explícita, no un accidente.

El alcance de la marcha atrás depende del avance. Retirar la plantilla, invalidar la caché o rechazar una CSR pendiente puede ser suficiente antes de emitir. Después de firmar e instalar, volver al modelo anterior no retira las credenciales. Revocación, sustitución, equipos desconectados y comportamiento de las partes confiantes forman otro plan.

La primacía del código en ejecución de Heng Lu recuerda que el documento publicado no modifica por sí solo los clientes. El principio de especificación inicial mínima y decisión futura localizada ayuda a impedir que una semántica compartida se convierta en una autoridad que nunca se le otorgó.

Las capas de realidad separan aquí instrucción, solicitud, posesión, identidad, autorización, firma y uso observado. La reflexión sobre soberanía de datos añade que una capacidad técnica no crea por sí misma autoridad jurídica u organizativa. Poder insertar un nombre en una CSR no prueba el derecho a obtenerlo.

RFC 9908 fortalece EST porque permite decir con claridad qué debe construir el cliente. La arquitectura de control debe conservar esa modestia. La plantilla orienta; la firma prueba una relación con la clave; la autenticación identifica; la política decide; la CA firma; el operador instala; la parte confiante valida. La trazabilidad consiste en no saltarse ninguno de esos verbos.

Fuentes