Resumen
- El 11 de septiembre de 2026 apareció
draft-ietf-ocm-mls-federated-groups-00como trabajo del grupo Open Cloud Mesh. La adopción abre la edición colectiva; no convierte el texto en RFC ni demuestra una implantación. - El Commit de retirada excluye al usuario del nuevo epoch de MLS. Aun así, el servidor emisor puede conservar la clave del archivo mediante el modo opcional de reutilización, una decisión local que no se anuncia por el protocolo.
- La credencial que permite a un servidor descargar el objeto constituye otra barrera. Daniel Kade propone un comprobante de consecuencias que no mezcle membresía, recifrado y transporte; no es un requisito de IETF u OCM.
El cambio institucional tiene un alcance preciso
El historial del Datatracker registra la versión 00 del grupo de trabajo el 11 de septiembre y la vincula con la serie individual anterior. El anuncio de los presidentes dice que los dos documentos adoptados son puntos de partida que seguirán evolucionando. A partir de ahora, el grupo OCM conduce la discusión. Eso no equivale a consenso final del IETF.
La ficha actual lo presenta como Internet-Draft con destino Standards Track y vencimiento en marzo de 2027. Todavía enumera problemas abiertos: descifrado en flujo, agrupación de mensajes que reparten claves y recuperación de Commits perdidos. En los registros MLS de IANA no figuran las cadenas exactas ocm-group-key y ocm_federated_group, y el propio borrador deja el valor de extensión como TBD. La petición de un número futuro no es una asignación presente.
El texto 00 hace que un grupo distribuido entre varios servidores sea destinatario de un recurso OCM. Cada persona tiene una hoja MLS. Los clientes administradores preparan los cambios; el servidor propietario arbitra un Commit por epoch; todos los servidores miembros verifican que el firmante tuviera función administrativa. La versión individual 02 ya describía el dilema entre rotación y reutilización. La adopción no lo resuelve: lo entrega a la revisión del grupo.
La primera consecuencia vive en el árbol MLS
Según RFC 9420, un Commit de retirada introduce material nuevo que el miembro excluido no conoce. La aplicación conserva la responsabilidad de decidir quién puede expulsar a quién. OCM exige aprobación explícita de un administrador para añadir o quitar a otra persona; la salida propia y el reingreso que mantiene la identidad tienen reglas específicas.
Cuando el Commit aceptado establece el epoch siguiente, la hoja retirada ya no puede obtener sus secretos. Cada servidor vuelve a resolver el reparto dirigido al grupo y deja de presentarlo al usuario local que salió. Esta es una baja real, pero limitada: demuestra la membresía vigente, no el destino de todas las claves de recursos entregadas en el pasado.
El diseño utiliza dos clases de clave. La clave de grupo deriva del estado MLS. La clave de archivo, FK, cifra un recurso concreto. El servidor envuelve la FK con la clave del grupo para distribuirla. Por eso cambiar de epoch y cambiar la FK son operaciones distintas.
Un sobre nuevo puede contener la misma clave
Después de cada transición de epoch, el emisor debe volver a envolver la FK vigente y enviar ese envoltorio a los servidores que permanecen. La rotación completa hace mucho más: genera otra FK, cifra de nuevo el archivo y reparte envoltorios de la nueva clave a todos los grupos autorizados.
El borrador recomienda rotar cuando un miembro abandona alguno de los grupos con acceso. La palabra normativa es SHOULD, no MUST. Además, un recurso puede estar compartido con varios grupos usando un solo texto cifrado. Si cambia la FK, todos esos grupos necesitan un envoltorio actualizado. Una distribución incompleta deja a usuarios legítimos con una clave envuelta que ya no abre la versión presente.
También puede ocurrir que la persona expulsada de un grupo siga perteneciendo a otro que conserva el mismo archivo. Su acceso continúa de forma legítima. El emisor puede comparar el conjunto único de usuarios antes y después del cambio y omitir la rotación si no varía. Un evento de grupo no basta para conocer el alcance sobre el recurso.
La reutilización depende de una promesa operativa
El modo de reutilización existe para federaciones formales donde recifrar archivos enormes o sometidos a cambios frecuentes no resulta práctico. El epoch avanza y los miembros restantes reciben la FK existente bajo una envoltura nueva. El contenido cifrado y la FK permanecen iguales.
Eso significa que el servidor del antiguo miembro puede guardar la clave de grupo previa y la envoltura anterior. Un dispositivo nativo puede tener la FK ya desenvuelta. Mientras el texto cifrado no cambie, ese material sigue funcionando. El borrador lo formula con claridad: el acceso sigue a la membresía por confianza, no por revocación criptográfica, y los participantes deben eliminar las claves que dejaron de corresponderles.
No se trata de una acusación contra una federación. Es una condición declarada del modelo. El límite apropiado es contractual y operativo: reglas explícitas, confianza mutua y capacidad de comprobar la eliminación. Fuera de una federación formal, el propio documento desaconseja esa suposición.
La asimetría informativa es más delicada: la selección entre rotar y reutilizar pertenece a la política del servidor emisor y no viaja en el protocolo. Ver el nuevo epoch confirma la baja del árbol. No permite inferir si el archivo actual tiene una nueva clave.
Descargar y descifrar son permisos distintos
Una compartición cifrada añade una credencial de transporte por servidor. Esa credencial autoriza a obtener el texto cifrado; las claves determinan si puede abrirse. Cuando sale el último usuario alojado en un servidor, el emisor debería revocar su credencial y mandar SHARE_UNSHARED. La recepción del Commit no ejecuta automáticamente esas acciones.
Durante el intervalo, un servidor que ya no tiene miembros puede seguir descargando el objeto. Después de la revocación de transporte, puede seguir conservando una copia anterior junto con material criptográfico. De nuevo, una luz verde describe una barrera y no las demás.
En las comparticiones sin cifrado, la credencial de transporte es la única defensa en el lado emisor. La reevaluación de usuarios en el receptor y la revocación puntual cobran entonces aún más peso. El borrador base de OCM aporta el transporte y las notificaciones; la extensión de grupos no convierte la baja en una transacción indivisible.
Ni siquiera una clave nueva borra el pasado
La seguridad de MLS no puede impedir que un miembro autorizado conserve el texto claro, una clave de grupo o una FK que recibió legítimamente. Esa advertencia del documento evita una promesa imposible. Una rotación bien terminada impide que las claves viejas abran el nuevo texto cifrado servido por el emisor. No borra una exportación ni una copia sin conexión.
La arquitectura MLS separa el protocolo criptográfico de las decisiones de aplicación. El modelo de clientes virtuales MLS permite que varios dispositivos actúen como un solo cliente lógico y compartan estado sensible. El inventario de custodios es, por tanto, parte de la baja, aunque nunca pueda garantizar la recuperación de todo lo que un usuario vio.
La conclusión no es que recifrar carezca de valor. Crea una frontera hacia delante para la versión actual. La precisión consiste en declarar exactamente eso, sin disfrazarlo de borrado retroactivo.
Un comprobante con tres resultados
Daniel Kade propone un comprobante de consecuencias de la retirada protegido. Su cabecera enlazaría la dirección del grupo, ambos epochs, la identidad OCM retirada, la aprobación y el Commit aceptado. Después enumeraría los recursos afectados y los grupos que todavía tienen derecho.
Cada fila de recurso indicaría rotación o reutilización, versiones opacas de FK, resultado del recifrado, versión del texto cifrado y entrega de envoltorios a todos los grupos restantes. Otra fila registraría versión y revocación de la credencial de transporte, junto con la entrega de SHARE_UNSHARED. En reutilización, una constancia de borrado de claves seguiría siendo una declaración de confianza, no una prueba criptográfica.
El comprobante incluiría una limitación permanente: no recupera textos claros ni copias fuera de línea ya entregadas. No almacena claves secretas ni concede autoridad. Una vista pública podría mostrar solo identificador, clases de consecuencia, tiempos y estados; la topología y las identidades quedarían restringidas.
La idea es editorial, no una obligación de IETF, MLS u OCM. Sigue The Policy Mirror de Heng Lu al impedir que actor, regla y evidencia se sustituyan. Su Minimum Initial Specification permite combinar un mínimo común con registros locales. Y Why BTW Media Exists exige contar tanto la utilidad como el límite sin convertir la noticia en campaña.
Fuentes
- Grupos federados OCM con MLS, versión WG 00
- Registro actual del Datatracker
- Historial del documento
- Predecesor individual, versión 02
- Mensaje con el resultado de adopción
- Grupo de trabajo Open Cloud Mesh
- RFC 9420 — Messaging Layer Security
- RFC 9750 — Arquitectura MLS
- Clientes virtuales MLS, versión 01
- Protocolo base OCM, versión WG 06
- Registros MLS de IANA
- Heng Lu — The Policy Mirror
- Heng Lu — Minimum Initial Specification
- Heng Lu — Why BTW Media Exists
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance