Resumen

  • draft-ietf-anima-rfc8366bis-36 se publicó el 9 de septiembre de 2026 y continúa como Internet-Draft en evaluación del IESG. Aún no es RFC ni Proposed Standard aprobada.
  • La renovación ya no se describe como simple actualización de vigencia: el MASA verifica una solicitud fresca, el estado de revocación del certificado del Domain y los cambios de política que puedan impedir la continuidad.
  • El voucher firmado comunica el resultado autorizado al pledge. No contiene un formato común para identificar la observación de estado, la versión de política o la excepción utilizadas; nada en las fuentes permite afirmar qué guarda cada implementación.
  • Daniel Kade propone una constancia de decisión separada, compacta y protegida. No es un requisito del borrador y no sustituiría la autoridad del propietario del Domain ni del MASA.

Tres momentos que no conviene reducir a uno

El proceso tiene una historia. Primero hubo una comprobación inicial, potencialmente costosa, de identidad y pertenencia del equipo. Después existe una relación operativa entre un pledge y un Domain. Por último llega una renovación que pregunta si esa relación merece seguir produciendo vouchers.

La revisión 36, disponible desde el 9 de septiembre, hace visible ese tercer momento. El historial de Datatracker registra el nuevo texto y el paso de Revised I-D Needed a AD Followup. La ficha actual lo mantiene en IESG Evaluation, con Standards Track como destino solicitado. Que el encabezado diga que reemplazaría RFC 8366 y actualizaría RFC 8995 no significa que ya lo haya hecho.

La diferencia oficial entre 35 y 36 introduce una distinción precisa. La renovación no repite todas las comprobaciones de la primera emisión. Confirma que la relación establecida entonces sigue vigente.

Para ello, el Manufacturer Authorized Signing Authority verifica siempre la Registrar Voucher Request recién firmada. Esa firma demuestra que el Registrar todavía accede a la clave privada del Domain. El MASA también comprueba la revocación del certificado de identidad del Domain y aplica cualquier política modificada desde el voucher anterior. El texto menciona dos posibles cambios: el propietario puede ordenar que cesen las renovaciones y un contrato de soporte puede haber caducado.

Ninguna de esas comprobaciones es decoración administrativa. Cada una puede cambiar un sí por un no.

La solicitud conserva continuidad; no conserva toda la motivación

El Registrar incluye el voucher anterior en prior-signed-voucher-request y firma una solicitud nueva. El vínculo ayuda a saber qué autorización se intenta continuar. La prueba criptográfica de acceso a la clave es actual, no una copia de la primera ceremonia.

Cuando el MASA acepta, el voucher resultante es una orden firmada y utilizable por el pledge. Su función es indicar para qué Domain puede incorporarse ese equipo y bajo qué atributos. No tiene que cargar con la política comercial del fabricante ni con todos los datos usados para consultar OCSP o una lista de revocación conforme a RFC 5280.

El diseño protege al dispositivo de complejidad innecesaria y evita divulgar información. La propia revisión advierte que un atributo propietario del fabricante no debe contener datos que requieran confidencialidad, porque el voucher puede terminar almacenado por intermediarios.

La contrapartida aparece al auditar. Una firma demuestra que el MASA tomó una decisión positiva. No dice obligatoriamente qué fuente de estado consultó, a qué hora, con qué frescura, qué versión de la regla de renovación ejecutó ni si hubo una autorización excepcional. Es posible que un operador conserve todo eso. Es posible que lo distribuya entre varios sistemas. La documentación pública no permite generalizar.

Por eso el problema no es “no hay logs”. Es “el resultado no enlaza con una evidencia portable y comparable”.

La unidad de control es un solo pledge

La revisión 36 recupera una decisión de diseño que parece pequeña. El formato temprano podía abarcar grupos de dispositivos mediante patrones de números de serie. Se abandonó porque bloquear la renovación de todo el grupo sería excesivo si solo había cambiado la propiedad de un pledge.

Un voucher por pledge reduce el radio de la negativa. También deja claro que la continuidad se juzga por una relación concreta, no por una flota abstracta. El número de serie necesita su ámbito de emisor; no es una identidad mundial autosuficiente.

Esa misma unidad debe llegar al registro de decisión. Un porcentaje agregado de éxitos no explica por qué un dispositivo recibió autorización después de que cambió su propietario. La alternativa tampoco es publicar su ubicación o el contrato completo. Bastan identificadores estables, hashes y clases de resultado.

Renovar y saber la hora son responsabilidades distintas

El borrador favorece vouchers de corta vida, no revocables por sí mismos, con renovación programática. Cada protocolo de onboarding decide cuánto dura “corta”. La cadena de certificados sí puede verse afectada por revocación.

Para un voucher sin nonce, el pledge necesita una hora interna fiable con la que comparar expires-on. El texto nuevo advierte que un atacante puede controlar NTP durante el ingreso. Si el dispositivo carece de reloj seguro, puede usar un nonce y obtener un artefacto efímero.

Esta prueba de frescura ocurre en el consumidor. La decisión de renovación ocurre en el MASA. Mezclarlas en un único estado “válido” impediría saber si falló la emisión, la hora del dispositivo o la coincidencia con el Domain fijado.

Una constancia que no invada el voucher

Una constancia mínima podría quedar junto al sistema de decisión del MASA. Debería asociar el hash del voucher anterior y de la solicitud fresca; el pledge y su ámbito de emisor; el Domain fijado; el MASA; las horas de solicitud y decisión; el resultado de posesión de clave; el método, referencia, frescura y resultado del estado del certificado; el identificador y versión de la política; una clase de estado contractual cuando corresponda; cualquier excepción con su autoridad responsable; la decisión; la nueva vigencia; y el siguiente disparador de revisión o bloqueo.

El detalle protegido puede permanecer donde está. La constancia puede usar hashes y códigos controlados. Su objetivo no es uniformar contratos entre fabricantes, sino impedir que una política mutable sea sustituida después por una descripción de memoria.

La idea sigue la disciplina de especificación inicial mínima de Heng Lu: acordar la evidencia indispensable y dejar la política local a quien soporta el riesgo. The Policy Mirror recuerda que una automatización debe seguir reflejando la regla que le da autoridad.

Esta constancia es una propuesta editorial de Daniel Kade, no parte de la revisión 36.

Frontera de la evidencia

Los RFC vigentes y el borrador separado de operación del MASA permiten entender los roles. No ofrecen una estadística de despliegue ni documentan un ataque, una renovación indebida, un estado obsoleto de certificados o una disputa contractual. Tampoco certifican qué guarda cada proveedor.

La conclusión queda acotada: el nuevo texto describe una decisión de continuidad con varios insumos. El voucher conserva el resultado firmado. Una capa de evidencia aparte haría revisable esa decisión sin convertir el artefacto del dispositivo en un expediente interno.

Fuentes