Resumen

  • RFC 9642 define un modelo YANG para claves simétricas y asimétricas, certificados, referencias centrales y definiciones inline, pero no emite un veredicto de recuperación.
  • Los objetos cifrados dependen de un grafo que une cada valor con su KEK, la clave primaria del servidor, el reenlace para el destino y la autorización que lo ejecutó.
  • La prueba termina en el consumidor: referencia resuelta, certificado correcto, operación permitida, usos prohibidos rechazados y efecto de servicio observado.

El inventario mostraba una clave llamada gateway-identity. Su llave pública coincidía con el certificado y la configuración del nuevo servidor había pasado validación. Sin embargo, el proceso que atendía conexiones seguía enlazado a una definición inline anterior.

El error no estaba en la sintaxis. Estaba en el salto entre una representación válida y la autoridad que el código había elegido. RFC 9642 reduce esa ambigüedad al dar a los sistemas un vocabulario compartido; no elimina la obligación de probar qué objeto llegó a operar.

Cuatro funciones, varias fronteras

El RFC separa el keystore central, las definiciones inline, las claves asimétricas y las simétricas mediante funciones declaradas. Los agrupamientos permiten que otro módulo ofrezca una elección entre material local y una referencia central, y admiten casos adicionales para ubicaciones propias del modelo.

Por eso, “implementa RFC 9642” no describe una superficie única. La recepción debe fijar revisión del módulo, funciones habilitadas, esquema, datastore, ruta y hash del objeto. También identifica el módulo consumidor. El nombre de lista sirve para localizar dentro de una instancia YANG; no demuestra unicidad global, custodia o uso.

Una referencia que resuelve prueba una unión de configuración. No prueba que el consumidor activo conserve esa revisión, que no haya una clave inline con prioridad o que el proceso haya realizado la operación esperada. La evidencia de estado y la evidencia de evento deben mantenerse separadas.

El origen del sistema es una clasificación

Con RFC 8342, una clave incorporada puede aparecer en <operational> o <system> con origen de sistema, mientras que la configuración del operador reside en <running> o la vista intended. La clave pudo instalarse en fabricación, nacer en el primer arranque o crearse al habilitar un servicio.

La anotación evita atribuir al operador un objeto que aportó el servidor. No acredita fabricante, ceremonia, entropía, hardware, imposibilidad de exportación ni vigencia del certificado. RFC 9642 deja fuera de alcance cómo se instala o modifica una clave incorporada.

Si después el operador añade un certificado de despliegue a esa clave, ambas procedencias deben sobrevivir. Una copia plana pierde la diferencia entre la autoridad de origen y la asociación posterior. La recuperación debe preservar qué parte aportó el sistema, cuál el operador y qué operación las enlazó.

Cifrado no equivale a portabilidad

Cada valor cifrado puede señalar la clave que lo protege. Esa arista encrypted-by forma parte del activo. El servidor necesita acceso al KEK o a una API que lo use; de otro modo conserva ciphertext, no capacidad criptográfica.

El patrón no normativo de migración de RFC 9642 usa un KEK compartido para muchas claves. Ese KEK puede estar cifrado bajo una clave primaria exclusiva de cada servidor. Para mover la configuración, se reemplaza la entrada del KEK por otra envuelta para la clave primaria del destino. Los demás valores pueden permanecer idénticos.

Esto reduce el volumen de cambio y concentra el riesgo. La pérdida del KEK detiene muchas identidades; su sustitución puede alterarlas a todas; una interfaz excesiva puede ampliar permisos. La copia sólo está cerrada cuando incluye cada ciphertext, referencia, autoridad de envoltura, formato, algoritmo y operación de reenlace validada para el destino.

El recibo nombra backup y hash, servidores origen y destino, claves primarias, KEK compartido, actor, doble control, resultado y rollback. No convierte el diagrama del estándar en prueba de que una implementación concreta lo ejecutó.

La protección declarada necesita evidencia del sistema

RFC 9640 aporta los tipos cleartext, hidden y encrypted. hidden limita la exposición por la interfaz modelada; no garantiza no extracción por memoria, consola, copia o hardware. encrypted describe un valor y su protección; no acredita que el KEK esté disponible ni protegido.

RFC 9642 recomienda cifrar la persistencia y borrar copias descifradas de memoria cuando dejan de usarse. Si la persistencia no está cifrada, debe ser inaccesible. El árbol no observa discos replicados, swap, volcados, logs, backups secundarios o usuarios privilegiados.

Por eso el expediente añade cobertura de almacenamiento, manejo de memoria, custodia, accesos y pruebas negativas. Cuando no existe evidencia de hardware, la conclusión se limita a la superficie observada.

Denegar escritura no documenta el cambio

Los nodos escribibles llevan nacm:default-deny-write. Los secretos legibles heredan restricciones adicionales. RFC 8341 decide acceso, pero la anotación no contiene el actor ni la regla efectiva.

La traza une sesión NETCONF o RESTCONF, autenticación, canal, versión NACM, regla coincidente, ruta, valores anterior y posterior, commit, aprobación y vista operacional. Enumera además los caminos locales, de proveedor o de hardware que no atraviesan YANG. RFC 6241 y RFC 8040 dan transporte de gestión, no una biografía completa de la clave.

RFC 9642 no define RPC ni action. Una clave puede generarse por módulos consumidores de SSH/TLS o fuera del servidor. Verla al final no demuestra cómo nació, quién autorizó el proceso o si el valor claro fue expuesto.

La pareja correcta aún necesita un consumidor

Una clave asimétrica puede asociar certificados. La selección de certificado de entidad final referencia tanto clave como certificado. El Errata 8441 corrige un comentario que, por copia, lo describía como clave simétrica; la estructura normativa siempre fue asimétrica.

Los modelos de RFC 9644 y RFC 9645 pueden consumir esas claves en SSH o TLS. El recibo debe resolver el enlace concreto, conservar la versión del consumidor y observar una firma, descifrado o establecimiento de sesión vinculado a la clave.

Además, el módulo no restringe por sí mismo los usos de la clave privada. El certificado puede limitar la clave pública, pero política, autorización y operación real siguen siendo capas separadas. Una prueba de recuperación positiva debe acompañarse de pruebas negativas de los usos no autorizados.

La caducidad no rota nada por sí sola

La notificación de expiración anuncia una condición temporal. No demuestra recepción, acuse, aprobación, sustitución, actualización de referencias o éxito posterior. Una restauración puede devolver un certificado antiguo aunque el inventario central ya contenga uno nuevo.

El seguimiento une evento, receptor, acuse, nuevo objeto, verificación de pareja, consumidor, despliegue y operación. También registra divergencias entre central e inline.

Un recibo de recuperación completo

Primero se fija el backup exacto, los módulos, funciones, datastores y orígenes. Se conservan huellas de claves y certificados, formatos y todas las aristas de cifrado. Después se registra el cambio de envoltura entre claves primarias y KEK con su autoridad y resultado.

En el destino se prueba que el KEK abre cada objeto requerido, que las referencias eligen la versión prevista, que el certificado está unido a la clave, que el consumidor realmente opera y que los usos prohibidos fallan. El último paso observa el resultado de servicio y la capacidad de rollback.

Así se respeta la especificación mínima: RFC 9642 coordina la forma. El código en ejecución ejerce el poder. La auditoría sólo declara recuperado aquello que consigue unir entre ambas capas.

Fuentes