El fabricante firmó las nuevas raíces. El servidor que las entregó seguía sin autenticar.

Resumen

• draft-mittal-est-coap-ca-certs-00 propone que un ancla del fabricante instalada en fábrica valide un objeto CMS con certificados de CA operativas. Es un Internet-Draft individual, revisión 00, sin condición de RFC, consenso del IETF ni prueba de despliegue.
• El servidor de entrega puede no estar autenticado. Su conexión solo transporta el objeto; la autoridad procede de una firma acotada y además exige alias correcto, frescura, propósito del firmante y política local.
• La instalación de las raíces no vuelve fiable la conexión anterior. El cliente debe abrir una sesión TLS o DTLS nueva, autenticar allí al servidor operativo y mantener la matriculación como una transacción posterior y separada.

Un dispositivo recién encendido puede saber quién lo fabricó y no saber aún quién operará su infraestructura. Esa asimetría aparece en medidores, sensores y equipos industriales que salen de una línea meses antes de que el comprador elija su CA, su servidor EST o incluso su red final.

El borrador individual draft-mittal-est-coap-ca-certs-00 intenta cerrar ese hueco sin exigir que el servidor ya sea autenticable. El equipo conserva un ancla de confianza del fabricante. Más tarde obtiene un conjunto de certificados de CA operativas dentro de una estructura firmada con CMS por el fabricante o por una autoridad autorizada por él.

El servidor EST actúa como punto de distribución. Puede servir un objeto estático precomputado y no necesita la clave de firma en línea. El cliente, que todavía carece de la CA operativa, puede completar una conexión TLS o DTLS sin aceptar la identidad del servidor, exclusivamente para recuperar el paquete. Cuando el contenido es realmente público, el texto admite incluso HTTP o CoAP sin cifrado.

La firma resuelve la autenticidad del objeto. No resuelve todo lo que lo rodea. El mismo servidor sigue sin demostrar su identidad. El canal no puede transportar credenciales ni solicitudes de certificado. Y una CA válida para el fabricante puede ser inaceptable para la política del operador o estar obsoleta después de una rotación.

La firma no se propaga desde el objeto hacia el canal

ManufacturerSignedCACerts incorpora versión, alias, número de secuencia, comienzo y fin de vigencia y la lista de certificados. La firma CMS cubre la estructura completa. El cliente construye la ruta del certificado firmante hasta su ancla del fabricante y debe comprobar que esa clave estaba autorizada para este propósito concreto.

Si todo coincide, se puede afirmar que unos bytes determinados fueron aprobados por un firmante aceptable. No se puede afirmar que el operador del socket sea ese firmante, que el nombre DNS pertenezca al fabricante o que el relay esté autorizado para conocer secretos del dispositivo. Un espejo malicioso puede entregar un paquete genuino. La integridad sobrevive al relay; la identidad del relay no nace de ella.

Por eso la operación permitida es mínima. En HTTPS provisional solo se solicita /cacerts. En EST-coaps, /crts. El cliente no debe enviar CSR, identificadores de largo plazo, credenciales, solicitudes de reenrolamiento ni claves. El modo claro se limita a material público. DTLS puede ocultar el tráfico a terceros sin que el dispositivo haya aceptado al par como servidor operativo.

Esta distinción también cambia la auditoría. El registro del distribuidor demuestra que respondió. El registro de la ceremonia o servicio de firma demuestra quién autorizó el objeto. El dispositivo demuestra qué verificó e instaló. Un único evento “origen confiable” borraría las tres responsabilidades.

El alias es una coordenada, no una autorización

El paquete se publica bajo un alias del fabricante, por ejemplo en /.well-known/est/{manufacturer-alias}/cacerts. La variante de CoAP utiliza /crts. Un perfil podría derivarlo de un Private Enterprise Number de IANA, pero la revisión 00 no exige esa fórmula ni solicita un registro nuevo.

El texto insiste en que el alias del URI no autoriza la instalación. El mismo valor está protegido dentro del objeto y el cliente debe compararlo con el alias solicitado o con una equivalencia local explícita. Una firma perfectamente válida para otro alias debe ser rechazada.

La regla evita que un servidor multitenant entregue el conjunto de una marca a dispositivos de otra. También ofrece una lección general: el nombre exterior enruta, el contenido firmado vincula y la política local interpreta. El nombre no puede sustituir a la firma; la firma no puede sustituir a la política.

Para investigar una sustitución hay que conservar URI, alias configurado, alias firmado, regla de equivalencia, hash del CMS y resultado. Registrar solo “200 OK” o “firma correcta” deja sin respuesta la pregunta central: ¿por qué este conjunto podía modificar este almacén?

La frescura necesita memoria, no solo criptografía

Una firma antigua no deja de ser válida cuando se compromete una CA operativa. Un atacante puede reproducir el último paquete que todavía apuntaba a ella. El riesgo aumenta después de un reset: el equipo puede haber perdido el recuerdo de una secuencia superior.

El borrador incluye un contador creciente y un intervalo temporal. El cliente debería almacenar el mayor número aceptado para cada alias y rechazar cualquier retroceso. Si dispone de una hora fiable, debe aplicar notBefore y notAfter. Si todavía no la tiene, puede aplazar esa comprobación y basarse en la secuencia, para revisar la ventana cuando obtenga tiempo autenticado.

La persistencia del contador forma parte del perímetro. Guardarlo en la misma partición que borra el restablecimiento convierte la protección en una promesa débil. La organización debe definir el comportamiento ante secuencias iguales con hashes diferentes, una restauración de copia antigua, agotamiento del contador y recuperación de emergencia.

La caché añade otra versión del mismo problema. El objeto estático reduce CPU y amplificación, pero puede sobrevivir más que la decisión que lo autorizó. El CDN entrega fielmente un paquete retirado. La firma responde “no alterado”; no responde “todavía vigente”.

Un recibo de frescura debería enlazar hash, secuencia protegida, máximo anterior, calidad de la hora, decisión de intervalo, edad de caché y versión de política. Sin esa unión, el panel verde de firma oculta el ataque más sencillo.

El operador no puede delegar su veto sin darse cuenta

La propuesta permite añadir, sustituir o ampliar las raíces operativas, pero obliga a aplicar la política local de gestión. Esa política decide si una rotación elimina una raíz anterior, exige solapamiento, limita emisores o necesita aprobación humana.

El fabricante puede estar autorizado para firmar una propuesta de transición. No por ello se convierte en administrador permanente de la confianza del comprador. Si cualquier objeto válido se instala de manera incondicional, la relación de fabricación se transforma en un plano remoto de control sobre toda la vida útil.

La doctrina de Lu Heng sobre especificación inicial mínima ayuda a dibujar el límite. Deben ser comunes las reglas deterministas necesarias para reconocer el objeto: ruta del firmante, propósito, bytes exactos, alias, secuencia y vigencia. La selección futura de la CA, el calendario de rotación y el tratamiento de compromisos pertenecen al operador que soporta el daño.

Antes de modificar el almacén, el equipo debe calcular el conjunto actual y el propuesto, registrar altas y bajas, aplicar política y producir hashes anterior y posterior. Un rechazo tiene que detener el flujo. No puede convertirse en una excusa para seguir usando el servidor provisional.

Solo una conexión nueva pone a prueba las raíces nuevas

Después de instalar el conjunto, el cliente abre otra sesión TLS o DTLS. Allí presenta el servidor su certificado y allí las raíces recién aceptadas pueden validarlo. Esa segunda sesión es el momento en que la confianza del objeto se convierte, o no, en identidad del par.

Continuar en la conexión antigua mezclará dos épocas. El servidor apareció antes del cambio de política. El cifrado y los parámetros negociados pertenecen a ese contexto. Una reevaluación en memoria puede ser útil, pero la frontera clara es una nueva conexión para toda operación no bootstrap.

RFC 7030 ya contempla continuar TLS de forma provisional para obtener /cacerts, autorizar después esos datos por una vía fuera de banda y reconectar. El borrador propone una firma del fabricante para reemplazar la autorización manual del paquete, no para eliminar la reconexión.

RFC 9148 adapta EST a CoAP y DTLS. Su mapeo a /crts y sus reglas de revalidación no permiten tratar cualquier endpoint que responda como registrador legítimo. El recibo de la nueva sesión necesita nombre esperado, cadena, ancla utilizada, política y resultado.

Matricularse sigue siendo otra decisión

Autenticar al servidor no obliga a la CA a emitir. El cliente debe construir un CSR, demostrar posesión de su clave y satisfacer las condiciones del dominio. Una emisión correcta tampoco garantiza que la identidad esté bien perfilada o que el servicio posterior funcione.

La revisión 00 no altera esos pasos. Se limita a entregar CA operativas. No valida al dispositivo, no aprueba la solicitud, no emite el certificado y no observa el resultado.

Una máquina de estados honesta conserva al menos: paquete recibido, firmante autorizado, frescura comprobada, política local aceptada, almacén modificado, nueva sesión autenticada, solicitud aprobada, credencial instalada y servicio comprobado. Reducirlos a “bootstrap completo” impide saber dónde reparar.

El fabricante responde por el firmante; el operador por su política; el servicio EST por su identidad; la CA por la emisión; el sistema en ejecución por el resultado. Una prueba no absorbe la autoridad de las demás.

El punto de concentración es la clave del fabricante

Si la clave de firma es comprometida, un atacante puede crear conjuntos de CA que todos los dispositivos del dominio acepten. El borrador recomienda HSM o KMS, protección contra exportación y un certificado dedicado que no se reutilice para TLS, firmware, emisión de CA u otras tareas.

La dedicación también hace posible que el cliente autorice una función. Una ruta válida hasta el fabricante no dice qué acto institucional puede ejecutar la clave. Política y key usage deben distinguir firma de bootstrap de identidad de servidor o firma de software.

El plan serio comienza con el fracaso: ¿cómo se bloquea una generación?, ¿quién autoriza el sucesor?, ¿cómo se localizan todos los conjuntos aceptados?, ¿qué ocurre si el fabricante entra en insolvencia? Si la recuperación solo puede venir por la misma clave sospechosa, no es recuperación.

RFC 8995 y RFC 8366 describen vouchers y vinculación de equipos a dominios. Son una comparación útil para sujeto, frescura y autorización, no una evidencia de que esta propuesta sea BRSKI ni de que exista un despliegue interoperable.

La disponibilidad obliga a mantener pequeño el endpoint

Las solicitudes llegan antes de la autenticación normal. El servicio debe resistirlas con objetos estáticos, sin consultas por cliente ni firma dinámica, límites por fuente, prefijo, alias e instancia, reintento sin estado, GET únicamente, límites de tamaño y control del estado Block-Wise.

Es una arquitectura de repositorio público firmado. Personalizar respuestas o pedir identidad anticipada convierte el mecanismo en algo distinto y expone base de datos, CPU o secretos. El alias debe poder deshabilitarse sin apagar todo el servicio.

El modo claro separa integridad de privacidad. CMS protege contra modificación y atribuye el objeto, pero cualquiera puede observar el alias y los certificados. Si revelan cliente, región o calendario de migración, el operador necesitará cifrado aunque el par no esté aún autorizado.

La cadena de evidencia necesita ocho registros

Registro	Prueba mínima	Límite
Fabricación	Ancla, clase, almacenamiento, regla de alias	No prueba control actual
Autoridad del objeto	Hash CMS, cadena y propósito del firmante	No identifica al servidor
Alcance/frescura	Alias, secuencia, fechas, hora fiable	No acepta la política
Mutación local	Regla, diferencias y hashes antes/después	No autentica al par
Transporte bootstrap	URI, certificado presentado, modo y caché	No autoriza EST
Nueva sesión	Nombre, cadena, ancla y validación	No aprueba el CSR
Matriculación	CSR, identidad, posesión y decisión	No prueba servicio
Resultado	Credencial y observación operativa	No legitima otro paquete

Con esta separación se puede recuperar una etapa sin destruir las demás. Una CA rechazada no obliga a desconocer la entrega. Un servidor falso no cambia la autoría del paquete. Una matrícula fallida no invalida necesariamente la rotación. Y una clave comprometida puede rastrearse hasta cada transición concreta.

La conclusión no es que el canal sin autenticar sea inherentemente inseguro. Es que solo puede utilizarse para un objeto que se verifica de manera independiente y cuyo efecto permanece acotado. El fabricante firmó las nuevas raíces. El servidor que las entregó seguía sin autenticar hasta la siguiente sesión.