Resumo

  • O draft-ietf-ocm-mls-federated-groups-00 foi publicado em 11 de setembro de 2026 como item do grupo Open Cloud Mesh. Continua sendo um Internet-Draft em evolução, não uma RFC nem evidência de operação em produção.
  • Um Remove Commit exclui o membro do novo epoch do MLS. No modo opcional de reutilização, porém, o servidor remetente mantém a mesma chave de arquivo e o mesmo conteúdo cifrado, apoiando a revogação na confiança entre participantes.
  • A credencial de transporte do Member Server tem uma revogação separada. Daniel Kade propõe um recibo protegido para registrar as três consequências sem misturá-las; a proposta não pertence ao IETF nem ao OCM.

A adoção define quem trabalha no texto

O histórico no Datatracker registra a versão 00 do grupo em 11 de setembro e aponta o rascunho individual que ela substitui. A mensagem dos chairs chama os dois documentos adotados de bons pontos de partida que continuarão evoluindo. A novidade institucional é a responsabilidade assumida pelo grupo OCM, não a aprovação final de cada escolha técnica.

O registro atual informa intenção de Standards Track e validade até março de 2027. O texto ainda reserva uma seção a problemas em aberto, entre eles descriptografia em fluxo, agrupamento de mensagens de distribuição e retransmissão de Commits perdidos. Os termos ocm-group-key e ocm_federated_group pedidos pelo rascunho não aparecem no registro MLS da IANA capturado; o número da extensão segue como TBD. Pedido futuro não é atribuição vigente.

O WG draft 00 transforma um grupo espalhado por vários servidores OCM no destinatário de um compartilhamento. Cada usuário ocupa uma folha na árvore MLS. Clientes de admins montam Commits; o Group Owner Server arbitra um por epoch; todos os Member Servers conferem se o signatário era admin no estado pertinente. O antecessor individual 02 já continha a alternativa entre rotação e reutilização. A mudança de nome leva essa alternativa ao processo do grupo, sem encerrá-la.

A árvore avança antes do arquivo

A remoção descrita na RFC 9420 acrescenta ao novo epoch entropia que o membro retirado não recebe. Quem pode retirar quem continua sendo política da aplicação. OCM exige aprovação explícita de um admin para acrescentar ou remover outra pessoa; saída voluntária e reentrada que preserva a identidade recebem tratamento próprio.

Depois do Commit aceito, a folha removida fica fora do estado corrente e não deriva os segredos do novo epoch. Cada servidor membro recalcula, a cada Commit, quais usuários locais devem enxergar o compartilhamento dirigido ao grupo. A baixa de associação, portanto, é um fato efetivo e verificável.

O arquivo segue outra linha. Uma File Key aleatória, a FK, cifra o recurso. A Group Key derivada do MLS envolve a FK para distribuí-la. Toda troca de epoch pede um novo envoltório, mas não obriga o remetente a trocar o segredo que está dentro dele.

Reembrulhar não é recifrar

No re-wrap, a FK existente apenas recebe um invólucro feito com a nova Group Key. Na rotação, o remetente gera outra FK, recifra o recurso, embrulha a nova chave para cada grupo que continua autorizado e distribui todos os resultados. Um Commit verde não demonstra que esse trabalho de armazenamento ocorreu.

A versão 00 usa SHOULD ao recomendar rotação quando alguém sai de um grupo que acessa o recurso. Há motivos operacionais para não torná-la absoluta. Um mesmo arquivo cifrado e uma mesma FK podem atender vários grupos, cada qual com seu invólucro. Quando a FK muda, todos os grupos restantes precisam receber o novo invólucro; uma falha deixa usuários legítimos sem acesso à versão corrente.

Além disso, a pessoa removida do Grupo A pode continuar no Grupo B, que tem direito ao mesmo arquivo. Nesse caso, a capacidade de decifrar por B é correta. O remetente pode comparar o conjunto único de usuários antes e depois e evitar a rotação se o conjunto não mudou. A associação a um grupo e o direito final sobre o recurso não são sinônimos.

A reutilização desloca a garantia para a governança

Em arquivos enormes ou alterados com frequência, recifrar tudo pode ser impraticável. O key-reuse mode permite que uma federação formal, com governança explícita e confiança mútua, conserve a FK. O epoch muda e os membros restantes recebem a chave antiga em um novo invólucro. O conteúdo cifrado não muda.

O antigo Member Server talvez retenha a Group Key do epoch anterior e o invólucro velho. Um dispositivo nativo pode já ter a FK aberta. Esses materiais continuam capazes de decifrar o mesmo ciphertext. A regra de que o acesso acompanha a associação depende, então, de servidores e dispositivos descartarem o que perderam o direito de guardar; não depende de inutilização criptográfica.

O próprio texto limita essa confiança a federações formais e diz que ela não deve ser presumida em compartilhamentos abertos ou ad hoc. Também deixa a decisão de modo a cargo do servidor remetente e não a sinaliza no protocolo. Um parceiro que recebe o novo estado MLS não consegue distinguir rotação de reutilização por esse sinal.

Isso não autoriza concluir que um ex-participante descumprirá a regra. A análise precisa apenas registrar que a força da revogação mudou de categoria. O erro seria transformar “usuário ausente do epoch atual” em prova de que todo material antigo parou de funcionar.

O caminho de transporte fecha em outro momento

O compartilhamento cifrado usa uma credencial por Member Server para buscar o ciphertext. A FK e a Group Key controlam a abertura. Quando sai o último membro hospedado em um servidor, o remetente deveria revogar a credencial desse servidor e enviar SHARE_UNSHARED. O Remove Commit não faz isso sozinho.

Até a revogação, o servidor fora do novo epoch pode seguir buscando o conteúdo cifrado. Depois dela, ainda pode conservar cópias e chaves anteriores. Os dois controles dão defesa em profundidade, mas o resultado de um não prova o resultado do outro.

Em compartilhamentos sem criptografia, a credencial de transporte é a única barreira no remetente. A reavaliação local do grupo e a revogação pontual tornam-se a própria execução do acesso. O protocolo-base OCM 06 fornece compartilhamentos e notificações; a camada MLS acrescenta associação sem fundir os ciclos.

Nenhuma rotação chama de volta uma cópia

O limite mais importante vale para todos os modos. O rascunho reconhece que MLS não impede um membro autorizado de guardar ou divulgar plaintext, Group Keys ou FKs recebidas legitimamente. Uma FK nova pode impedir que a chave antiga abra o ciphertext corrente recifrado. Não alcança uma exportação anterior ou um par antigo de ciphertext e chave que foi salvo offline.

A arquitetura MLS da RFC 9750 separa o protocolo criptográfico das escolhas da aplicação e dos serviços auxiliares. O documento de MLS Virtual Clients 01 permite que vários dispositivos representem um único cliente lógico e mantenham estado secreto. A lista de locais que precisam apagar material pode ser maior do que a árvore de usuários sugere.

Recifrar continua útil: cria uma fronteira futura para a versão que o servidor passa a distribuir. A linguagem pública precisa respeitar essa dimensão temporal e não chamar proteção da nova versão de apagamento do passado.

Um recibo que não comprime os resultados

Daniel Kade propõe um recibo de consequências da remoção sob controle de acesso. O cabeçalho ligaria endereço do grupo, epochs anterior e posterior, OCM Address removido, aprovação, Commit aceito e horário efetivo. A lista seguinte identificaria os recursos afetados e todos os grupos ainda autorizados.

Para cada recurso, o recibo marcaria rotação ou reutilização, versões opacas de FK, conclusão da recifragem, versão do ciphertext e entrega dos novos invólucros. Uma parte autônoma trataria da versão da credencial de transporte, sua revogação e o envio de SHARE_UNSHARED. Se houver reutilização, a declaração de que chaves antigas foram apagadas permaneceria uma atestação organizacional, não uma prova criptográfica.

O documento ainda carregaria uma limitação fixa: plaintext e cópias offline já entregues não podem ser recolhidos. Nenhuma chave secreta entraria no recibo e o recibo não concederia acesso. A face pública mostraria somente identificador opaco, classes de consequência, horários e estados verificados.

O recibo é uma intervenção editorial de Daniel Kade; nenhum texto do IETF, do MLS ou do OCM o impõe. O Policy Mirror de Heng Lu impede que ator, norma e evidência representem uns aos outros. A Minimum Initial Specification acomoda um protocolo comum pequeno e registros locais mais fortes. Why BTW Media Exists orienta a relatar a troca real entre custo e força de revogação, sem convertê-la em campanha.

Fontes

  1. OCM MLS Federated Groups, versão WG 00
  2. Registro atual no Datatracker
  3. Histórico do documento
  4. Antecessor individual, versão 02
  5. Mensagem com o resultado da adoção
  6. Grupo de trabalho Open Cloud Mesh
  7. RFC 9420 — Messaging Layer Security
  8. RFC 9750 — Arquitetura MLS
  9. MLS Virtual Clients, versão 01
  10. Protocolo-base Open Cloud Mesh, versão WG 06
  11. Registros MLS da IANA
  12. Heng Lu — The Policy Mirror
  13. Heng Lu — Minimum Initial Specification
  14. Heng Lu — Why BTW Media Exists