Resumen

  • RFC 9646 intercala un HTTP 400 entre dos llamadas a get-bootstrapping-data: el anuncio de capacidad, la selección del servidor y el CSR devuelto no son el mismo comprobante.
  • Verificar la firma de un CSR demuestra posesión de la clave privada, pero no acredita por sí solo el origen del dispositivo, la aprobación de la CA ni el uso posterior del certificado.
  • Como la orden csr-request viaja dentro de un error HTTP que no puede firmarse como los datos de arranque, el mecanismo no sirve cuando el servidor de arranque no es de confianza.

El reintento borró la decisión correcta

RFC 9646 añade a SZTP la posibilidad de obtener un certificado de identidad pensado para el entorno de producción. La extensión utiliza una secuencia deliberada que un cliente HTTP genérico puede interpretar mal.

En la primera petición, el dispositivo publica csr-support. Declara si puede generar una nueva clave asimétrica, qué algoritmos admite y qué formatos de CSR sabe construir. Si el servidor quiere una solicitud, responde con HTTP 400 e introduce un csr-request dentro de error-info. Allí selecciona algoritmo y formato y puede aportar información para el certificado.

El dispositivo no debe repetir ciegamente la primera llamada. Debe realizar la acción seleccionada y enviar una segunda llamada con p10-csr, cmc-csr o cmp-csr. Después, el servidor, una autoridad de registro o una CA verifica y decide. La respuesta final de incorporación puede llevar el certificado firmado.

El 400 es por tanto un dato con dos lecturas simultáneas. Para HTTP pertenece a la clase de error del cliente. Para este estado de SZTP es el mensaje que solicita el siguiente trabajo. Ninguna de las dos lecturas equivale a una decisión de identidad.

Anunciar una opción no demuestra haberla ejecutado

El primer mensaje es un inventario de posibilidades. No prueba que se generara una clave, que el generador aleatorio fuera adecuado o que el secreto quedara dentro de un HSM. La respuesta del servidor reduce las opciones, pero sigue siendo una orden. El CSR de la segunda petición demuestra que se produjo un objeto; aún hay que establecer cómo se produjo y quién estaba autorizado a pedirlo.

Esta arquitectura coincide con la Especificación inicial mínima de Lu Heng: el protocolo común debe coordinar lo indispensable y dejar visibles las decisiones locales. RFC 9646 no impone una política universal de CA, ni un método único para entregar el certificado, ni la autorización del servicio que lo usará.

Un panel que resume todo como “CSR completado” destruye información. Ya no permite saber si el servidor seleccionó un algoritmo anunciado, si la clave era nueva o reutilizada, si la segunda petición pertenecía al mismo intercambio o si el certificado final llegó a la clave correcta.

Posesión y origen no son sinónimos

La prueba de posesión verifica la firma del CSR con la clave pública incluida en él. El resultado es importante y limitado: el creador controló la clave privada correspondiente cuando firmó la solicitud.

La prueba de origen pregunta por el dispositivo o principal del que procede esa solicitud. PKCS #10 sin envoltura no incorpora autenticación de origen. Puede apoyarse en la identidad TLS o HTTP del cliente, pero esa relación está fuera del objeto. Si el archivo del CSR se separa de la sesión, la organización conserva posesión y pierde origen.

CMC y CMP admiten autenticación de origen mediante PKI o secreto compartido. También admiten intervención de una autoridad de registro antes de la CA. Son rutas probatorias más expresivas, no permisos automáticos. La ruta IDevID, la referencia al secreto o la protección del protocolo deben verificarse y después someterse a la política de emisión.

Si se reutiliza la clave de fabricante, el servidor valida la ruta de certificación IDevID y comprueba que el CSR usa la misma pareja. Si se crea una clave local nueva, CMC o CMP puede vincularla a la clave de fabricante o a un secreto. Las dos rutas no deberían quedar bajo una sola casilla llamada “firma válida”.

La clave nueva aporta frescura sólo si existe

RFC 9646 recomienda una clave privada nueva para cada CSR. El material aleatorio de esa clave puede cumplir una función parecida a un nonce. Cuando el certificado devuelto contiene la clave pública recién creada, el dispositivo puede relacionar la respuesta con el intercambio actual y detectar ciertos reenvíos antiguos.

La propiedad depende de hechos. Una interfaz que afirma key-generation no demuestra frescura si la huella se repite. Además, producir una clave nueva no siempre es más seguro. Si el dispositivo no puede protegerla tan bien como la clave integrada del fabricante, el RFC recomienda reutilizar la clave mejor protegida. La frescura y la custodia resuelven riesgos distintos.

La clave dinámica debe quedar protegida frente a divulgación; se recomienda HSM o TPM. Sin esa frontera, conviene reducir su vida mediante renovación. Al restablecer el equipo a valores de fábrica, la identidad de despliegue y la clave generada se consideran datos del usuario y deberían eliminarse. Una bitácora que termina en la emisión deja incompleto el ciclo.

El servidor no confiable queda fuera

RFC 8572 permite un caso en que el dispositivo contacta a un servidor de arranque no confiable y exige datos de arranque firmados. La instrucción de RFC 9646 no puede recibir la misma protección. Está dentro de un error HTTP, y ese error no puede firmarse como dichos datos.

Por eso la extensión CSR no puede utilizarse en esa relación. El cliente no debería enviar csr-support al servidor no confiable y debería preferir signed-data-preferred. La ubicación del mensaje crea un límite de autoridad.

Ignorarlo significa aceptar que una parte no autenticada seleccione algoritmo, formato y contenido de la futura identidad. Que el dispositivo produzca después un CSR matemáticamente correcto sólo demuestra que obedeció. No demuestra que la instrucción fuera legítima.

Emitir, transportar, instalar y usar

Tras recibir el CSR, la infraestructura puede verificar posesión, origen, inventario, propiedad y atributos, y después aprobar o denegar. Esa decisión pertenece a la RA o CA y debe conservar su propio responsable y fundamento.

RFC 9646 deja fuera de alcance el modo exacto de llevar el certificado firmado dentro de la información de incorporación. Sus ejemplos muestran posibilidades, incluso la asociación con un keystore compatible con RFC 9642. No convierten una opción de transporte en resultado de instalación.

Instalar exige unir certificado y clave, confirmar el cambio y seleccionar la identidad en el servicio correcto. El primer uso con validación del par aporta otro comprobante. Incluso entonces, la autorización de la operación de negocio sigue siendo posterior a la autenticación.

La Primacía del código en ejecución ayuda a ordenar la evidencia. El modelo describe lo que los actores pueden intercambiar. La realidad operativa se encuentra en el mensaje procesado, la decisión tomada y el efecto observado.

Un recibo para toda la secuencia

La evidencia comienza con la identidad y cadena de confianza del servidor, los hechos TLS y HTTP y la elección entre csr-support y signed-data-preferred. La primera petición conserva nonce, información del dispositivo, algoritmos y formatos. El 400 conserva el csr-request exacto, su selección, la información solicitada, la hora y un identificador común.

El registro de la clave indica si fue generada o reutilizada, su huella pública, su frontera de custodia y la prueba de frescura. La segunda petición conserva el formato y hash del CSR. Posesión y origen se evalúan por separado. Luego se añaden la decisión RA/CA, la huella del certificado, su transporte, instalación, primera utilización y retirada.

Las capas de realidad evitan que un elemento tome prestada la autoridad del siguiente. Un 400 puede ser una orden correcta. Una firma puede demostrar posesión. Una CA puede emitir. Sólo la cadena completa explica qué identidad llegó a operar y bajo qué mandato.

Sources