Resumen

  • RFC 9908 es un Proposed Standard del IETF de enero de 2026 que actualiza RFC 7030 y RFC 9148.
  • Aclara la codificación de CSR Attributes, diferenciando el OID del atributo y el valor esperado, incluidos valores de extensiones X.509.
  • CertificationRequestInfoTemplate permite al servidor EST fijar partes de la solicitud y dejar valores explícitamente abiertos para el cliente.

Análisis de Theo March: la novedad decisiva no es que EST incorpore una aprobación. Es que /csrattrs puede describir una forma concreta de solicitud en lugar de ofrecer una lista ambigua de tipos de atributo. El servidor puede enviar un CertificationRequestInfoTemplate parcialmente cumplimentado. Puede proporcionar el valor de un RDN, que el cliente debe utilizar, o incluir el RDN sin valor para que el cliente aporte uno adecuado. El campo subject es opcional: aparece cuando el servidor tiene requisitos sobre los RDN.

La misma semántica de presencia y ausencia se aplica a la información de clave pública. subjectPKInfo está ausente cuando el servidor no tiene requisitos de clave; cuando aparece, su algoritmo identifica el tipo de par de claves esperado. subjectPublicKey normalmente está ausente. La excepción especial es un marcador de posición que expresa un requisito de longitud del módulo RSA. Ese marcador no es la clave pública final del cliente y no debe tratarse como tal.

El motivo práctico aparece en el alta ACP y BRSKI de RFC 8994 y RFC 8995: el servidor necesita transmitir un subjectAltName específico mediante /csrattrs. RFC 9908 aclara la codificación de ese requisito y de los requisitos de extensiones X.509. La plantilla limita la información de la CSR; no es una firma de CSR, una aprobación de certificado, una autenticación ni una sustitución de la política de la CA. La autenticación del alta EST y la decisión de la CA siguen siendo asuntos separados.

La interoperabilidad exige mirar los bytes, no aceptar una respuesta solo porque un decodificador la admite. Comparar el OID codificado con su valor asociado; comprobar la presencia o ausencia ASN.1 de subject, subjectPKInfo y subjectPublicKey; verificar si el valor de un RDN está codificado o se omitió deliberadamente; y confirmar que el marcador de longitud RSA no se reutiliza como clave generada. Después hay que generar la CSR y comparar su CertificationRequestInfo DER con los valores exigidos por la plantilla, incluido el subjectAltName, antes de evaluar la cadena de certificados.

Ruta de decisión del operador: conservar los bytes de la respuesta /csrattrs y su contexto autenticado. Enumerar cada valor fijo, cada espacio que debe completar el cliente y cada estructura ausente cuya semántica sea relevante. Rechazar un cliente que cambie un RDN suministrado, trate un RDN sin valor como si tuviera un valor fijo o convierta el marcador RSA en una clave pública. Por último, verificar la CSR y el certificado emitido frente a los requisitos. Que la plantilla pueda decodificarse no basta para aceptarla.

Fuentes