Resumen

  • BRSKI-AE reúne en la petición una prueba de posesión de la nueva clave y una prueba de origen basada en el IDevID de fábrica; ambas pueden verificarse lejos de la primera sesión.
  • El objeto firmado aporta evidencia para autorizar, pero no autoriza por sí solo. El registrador del dominio debe seguir participando aunque delegue las comprobaciones a una RA remota.
  • Voucher, consentimiento, decisión de la RA, emisión, confirmación, telemetría y acceso a producción son hechos distintos. Un estado único de “alta correcta” borra quién decidió cada uno.

El tren ya había salido del depósito cuando la plataforma central volvió a tener conectividad. Horas antes, un controlador nuevo había hablado con el registrador local y había dejado una solicitud de certificado. La infraestructura de clave pública estaba fuera de línea, de modo que el mensaje viajó más tarde. La sesión TLS original ya no existía. Sin embargo, la autoridad remota necesitaba comprobar que la solicitud seguía siendo la del dispositivo y no una reconstrucción del intermediario.

Ese es el problema práctico que ordena RFC 9733. BRSKI con inscripción alternativa sustituye la dependencia exclusiva de EST por mensajes de certificación autenticados y autocontenidos. La petición puede sobrevivir a saltos, almacenamiento y entrega diferida conservando la prueba de quién la originó.

La palabra decisiva es “prueba”, no “permiso”. Que un mensaje pueda defender su origen no significa que pueda concederse a sí mismo pertenencia al dominio, elegir sus atributos o obligar a una autoridad de certificación. La arquitectura gana flexibilidad precisamente porque mantiene separadas esas potestades.

Posesión e identidad no son el mismo examen

La primera prueba se refiere a la clave nueva. Una solicitud PKCS #10 suele firmarse con la clave privada cuya pública solicita certificar. CRMF admite mecanismos adicionales, incluso para claves sin capacidad de firma. El resultado demuestra posesión: quien construyó la petición tiene acceso al secreto correspondiente.

Esa firma no establece por sí sola una identidad. Cualquier actor puede crear una pareja nueva y demostrar que la posee. RFC 9733 exige además prueba de identidad o de origen, normalmente una protección firmada con el secreto IDevID instalado por el fabricante y ligada a un identificador fuerte del pledge.

Una petición puede superar una prueba y fallar la otra. También puede superar ambas y ser incompatible con la política: nombre no permitido, rol excesivo, propiedad desactualizada, algoritmo rechazado o dispositivo revocado. La criptografía verifica declaraciones concretas; la RA evalúa si esas declaraciones merecen un certificado en este dominio y en este momento.

Por eso, “firma válida” no es un resultado de alta. El registro debe guardar por separado posesión, origen, consentimiento y decisión.

Una evidencia que el backend puede volver a verificar

En BRSKI tradicional, EST puede ligar una solicitud PKCS #10 con la autenticación del pledge en el canal TLS hacia el registrador. La relación sirve al vecino inmediato, pero una RA situada detrás no necesariamente ve la sesión ni puede reproducir su comprobación. Recibe una afirmación del registrador.

BRSKI-AE permite usar un protocolo cuyo mensaje se proteja a sí mismo. Su realización normativa adopta CMP bajo el perfil ligero. La protección del PKIMessage liga el origen al IDevID; CRMF o PKCS #10 aporta la posesión de la clave LDevID. El registrador reenvía la petición original en vez de convertir una sesión efímera en una explicación no verificable.

Esto encaja en plantas con enlaces intermitentes y autoridades centrales. El registrador puede actuar como LRA, conservar el control local y delegar análisis más profundos. La RA puede estar fuera del sitio y aun así inspeccionar la prueba original. El transporte mueve el mensaje; no se convierte en fuente de identidad.

Pero un mensaje firmado no queda mágicamente oculto. RFC 9733 mantiene TLS o DTLS entre pledge y registrador. El intercambio desde allí hacia el backend queda fuera de alcance. CMP aporta autenticidad e integridad, no cifrado inherente. Sin protección del siguiente tramo, un observador puede conocer qué equipos se incorporan o bloquear algunos de manera selectiva.

El voucher fija a quién confiar; no entrega el certificado local

Antes de la solicitud LDevID, el pledge usa su IDevID en el intercambio de voucher entre registrador y MASA. El voucher establece la confianza del dispositivo en el dominio objetivo, mediante el certificado de dominio fijado. Esa operación evita que un aparato abandonado en una red acepte cualquier infraestructura que se presente.

El voucher no es el LDevID. Tampoco acredita que la RA aceptó la clave nueva, que la CA emitió o que el dispositivo fue admitido. Proporciona la base para autenticar a quienes responderán después.

Tras ese imprint, el pledge genera su secreto LDevID y forma la petición autocontenida. En CMP, valida la respuesta con el ancla que obtuvo por el voucher. Las etapas se apoyan sin sustituirse: una identifica el dominio confiable; otra pide una credencial concreta a la PKI de ese dominio.

Si el panel presenta “voucher válido” como “dispositivo operativo”, un rechazo posterior parecerá una anomalía. Si conserva ambas huellas, la organización puede saber si falló la asignación de dominio, la autorización, la emisión o el uso.

Delegar la RA no borra al registrador

RFC 9733 exige que el registrador participe en la decisión de aceptar o rechazar la unión al dominio. Puede delegar funciones de RA a un sistema central, pero el pledge no debe obtener el LDevID saltándose la puerta local.

El consentimiento admite varias representaciones: una relación implícita muy controlada, una entrada en base de datos, un mensaje adicional o una firma explícita. Con CMP, se recomienda que el registrador incluya la solicitud original dentro de un mensaje anidado y firmado por él. El backend recibe entonces el origen del pledge sin alteración y, además, el consentimiento del dominio.

Las dos firmas dicen cosas diferentes. El pledge dice “yo pedí este certificado para esta clave”. El registrador dice “este dominio permite que esta petición sea evaluada”. La RA aún puede decir no. La CA emite solo después de las verificaciones y autorizaciones aplicables. Una identidad de fabricación válida no da derecho automático a una identidad operativa local.

Esta distinción también permite atribuir un error. Una firma IDevID inválida pertenece al origen; un consentimiento ausente pertenece al registrador; un perfil incompatible pertenece a la RA; una emisión defectuosa pertenece a la CA. Comprimir todo en “PKI falló” impide corregir el control concreto.

Una cola también cambia el estado del mundo

La inscripción asíncrona resuelve una restricción real: el backend puede no estar disponible cuando el dispositivo llega. La prueba autocontenida mantiene su valor técnico durante el traslado. Sin embargo, el contexto alrededor de la prueba no queda congelado.

Puede cambiar la propiedad del equipo, caducar una aprobación, rotar un ancla o modificarse el perfil. Una petición duplicada puede llegar después de una primera emisión cuyo resultado se perdió. Una firma antigua aún puede validarse cuando el mandato que la acompañaba ya no existe.

El operador necesita una transacción durable que una identidad de voucher, huella de la clave, resultados de posesión y origen, consentimiento exacto, atributos solicitados, decisión RA, respuesta CA y certificado final. Debe definir cuánto puede esperar una petición, qué eventos la invalidan y qué significa repetirla. La idempotencia de transporte no sustituye la reconciliación de una decisión incierta.

La observación clave es temporal: autenticidad responde quién firmó un objeto; vigencia responde si todavía debe producir consecuencias. No son la misma propiedad.

Emitir no es terminar

Cuando la respuesta es positiva, incluye el certificado y puede adjuntar intermedios o anclas adicionales. CMP puede añadir una confirmación opcional. El pledge valida el resultado e informa si el certificado quedó inscrito y satisface sus necesidades. La PKI o el registrador confirma haber recibido ese mensaje.

BRSKI conserva además la telemetría obligatoria de estado de inscripción entre pledge y registrador. RFC 9733 aclara que es una fase separada. La confirmación CMP cuenta a la PKI cómo evaluó el pledge el certificado; la telemetría cuenta al registrador cómo terminó la inscripción. Un acuse de confirmación no demuestra uso operativo.

Después quedan instalación, control de acceso, configuración y servicio. Una CA puede emitir correctamente y el equipo no presentar nunca el certificado. El pledge puede confirmar y el NAC denegar. La red puede aceptar y la aplicación industrial permanecer rota.

La cadena de evidencia debe decir hasta dónde llegó: voucher aceptado, petición auténtica, consentimiento vigente, RA favorable, CA emitió, pledge confirmó, telemetría recibida, admisión observada o pendiente. Cualquier abreviatura debe conservar ese último límite.

Un nombre de servicio encuentra una función, no un soberano

RFC 9733 amplía los endpoints a /.well-known/<enrollment-protocol>/<request> y registra brski-reg-cmp como forma mínima de descubrir un registrador con CMP. El pledge puede probar el endpoint y usar el estado HTTP para reconocer soporte.

La existencia de esa puerta no certifica que sea la puerta correcta para ese dispositivo. El registro IANA no demuestra despliegue ni conformidad. El éxito HTTP puede reflejar recepción mientras CMP espera, rechaza o devuelve otro estado. Para explicar la operación hacen falta endpoint, par TLS, ancla fijada, protocolo, identificador interno y decisor.

Las fuentes congeladas no prueban que una empresa ferroviaria, eléctrica, inmobiliaria o de recarga concreta haya desplegado RFC 9733. Los ejemplos de la norma son escenarios de diseño. La afirmación defendible es sobre el mecanismo, no sobre un mercado observado.

Fuentes