Resumo

  • A RFC 9420 descreve a passagem de um grupo MLS entre épocas por meio de Proposals e de um Commit processado por clientes autenticados.
  • Essa passagem prova um estado de protocolo delimitado; não prova ciência humana, consenso, autoridade institucional, recebimento completo ou efeito de negócio.

É comum transformar uma evidência técnica elegante em uma frase administrativa ampla. Vê-se um Commit válido e conclui-se: “o grupo aprovou”. Mas aprovação pode significar coisas muito diferentes. Pode ser a entrega de uma mensagem, o processamento de uma atualização por um endpoint, uma regra de aplicação satisfeita, a confirmação de participantes designados, uma autorização formal ou uma ação já praticada. Esses fatos têm donos, tempos e provas próprios.

Messaging Layer Security, definido pela RFC 9420, resolve uma questão mais estreita: como clientes mantêm continuamente um estado criptográfico compartilhado e autenticado. Para o protocolo, um grupo é uma coleção lógica de clientes que compartilham um segredo comum. Sua história é uma sequência linear de épocas. Em cada época, um conjunto específico de clientes autenticados compartilha estado criptográfico.

O uso de “clientes” importa. A RFC define o cliente pelas chaves criptográficas que ele possui. Não o define como pessoa, funcionário, departamento, empresa ou agente com poder de vincular uma organização. O serviço de autenticação pode validar credenciais segundo a política que o sustenta. Isso pode apoiar uma afirmação sobre chaves e participantes admitidos naquele contexto. Não prova que alguém compreendeu uma Proposal, tinha mandato para decidir ou registrou consentimento em nome de terceiros.

A mudança de estado no MLS é concreta. Uma Proposal sugere mudança no grupo, como adicionar, atualizar ou remover um membro. Um Commit implementa as mudanças propostas em uma lista de Proposals. Quando um cliente cria ou processa um Commit, ele avança a ratchet tree e o GroupContext do estado anterior para o estado que inicia a nova época. O contexto inclui, entre outros valores, identificador do grupo, número da época, hash da árvore e hash confirmado do transcript. Se há clientes adicionados, quem cria o Commit forma simultaneamente o Welcome correspondente para que eles possam estabelecer sua cópia do estado resultante.

É uma base sólida para dizer que determinada transição MLS foi processada sob as regras do protocolo. Os mecanismos de transcript e confirmação relacionam o material de protocolo definido entre épocas. A evolução das chaves oferece as propriedades de segurança descritas no RFC. Porém, Commit é um termo técnico, não uma ata. Não significa que uma reunião ocorreu, que uma votação terminou, que um contrato foi aceito, que um gasto foi aprovado ou que uma alteração operacional entrou em produção. Ele incorpora Proposals ao estado criptográfico do grupo.

O modelo de entrega impede uma extrapolação confortável. MLS assume um Authentication Service confiável para validar credenciais e um Delivery Service que encaminha mensagens, mas é em larga medida não confiável. Um Delivery Service comprometido não consegue forjar mensagens MLS válidas. Mesmo assim, pode atrasar ou remover seletivamente mensagens, bloquear de modo permanente mensagens para ou de um membro e, se a aplicação usa o serviço para resolver Commits simultâneos, influenciar qual Commit será aplicado.

Logo, um Commit válido não é comprovante de que todos os destinatários necessários foram informados no prazo. Ele pode demonstrar uma transição de estado sem demonstrar circulação integral. Salvo o valor de geração nos dados do remetente, a detecção de perdas fica a cargo da aplicação. Quem precisa saber quais endpoints receberam, quando receberam ou quais ficaram fora deve guardar esse rastro na camada de entrega e na aplicação. A ausência de falsificação não é evidência de entrega completa.

A própria RFC marca outra fronteira: a de confirmação de processamento. Em uma aplicação assíncrona, os membros capazes de reconhecer um Commit malformado podem estar offline. O estado produzido pode sustentar Commits posteriores, e esses membros podem não conseguir recuperar o atraso quando voltarem. A aplicação pode exigir confirmações de processamento bem-sucedido antes de considerar um Commit aceito. MLS não traz um mecanismo interno para essas confirmações.

Assim, quatro afirmações não devem virar uma só: o Commit existe; a aplicação o aceitou; a aplicação reuniu o conjunto de confirmações que sua regra exige; uma organização autorizada tomou uma decisão. O protocolo trata da primeira em seu próprio escopo. A aplicação é dona da segunda e da terceira. A decisão que compromete recursos, obrigações ou efeitos externos pertence à instituição que a adota.

Um registro de controle que possa ser auditado separa grupo e época MLS, Commit e Proposals, contexto de credenciais, observações de entrega, regra/limiar/prazo de confirmação, decisão local e ação executada. Essa separação permite revisar o que realmente mudou no protocolo, o que os clientes processaram, o que a aplicação aceitou e o que de fato aconteceu fora dela.

A distinção de Lu Heng entre representação, decisão local e resultado executado ajuda como disciplina. A época MLS é uma representação técnica precisa e útil. Justamente por isso ela não deve tomar emprestada a autoridade que pertence a uma decisão local ou a seu efeito.

Sources