Resumo

  • draft-mcewan-adkm-problem-statement-00 delimita o problema de manter um identificador estável durante a evolução do estado de chaves sem exigir uma nova autorização administrativa para cada transição nem um consenso global obrigatório.
  • A chave autorizada para assinar operações correntes pode ser insuficiente, sozinha, para estabelecer um estado sucessor arbitrário. Essa separação impede que a perda da chave atual se transforme automaticamente em perda de todas as chaves futuras.
  • Validade do histórico, atualidade, observação de conflitos, participação de recuperação, autorização da aplicação e efeito real são comprovantes diferentes.

Comece pelo momento depois da contenção. A equipe bloqueou acessos, isolou o servidor e recebeu um evento de rotação. A chave antiga assinou a nova; o digest do estado anterior corresponde; a sequência não pulou; o formato é canônico. O procedimento parece completo.

Agora volte cinco minutos. Foi justamente a chave antiga que disparou o incidente.

Se ela tinha autoridade suficiente para nomear qualquer sucessora, o atacante pôde abandonar a credencial exposta e registrar outra. A cadeia perfeita não curou a invasão. Ela deu à persistência uma aparência regular.

O Internet-Draft individual Autonomous Decentralized Key Management Problem Statement, publicado em 20 de setembro de 2026, organiza esse risco como uma lacuna de interoperabilidade. Um identificador pode precisar sobreviver a rotação rotineira, substituição de emergência, mudança de limiar, delegação, recuperação e revogação. O draft pergunta como comprovar essa evolução sem depender de um emissor externo em cada passo ou de um único sistema mundial de consenso. Ele não escolhe a solução.

O verbo “assinar” esconde autoridades diferentes

Key State inclui chaves públicas, limiares, funções e demais parâmetros de autorização vigentes. Key Event estabelece ou altera esse estado. Controller só aprova as transições permitidas pelo estado atual e pelas regras do protocolo.

Uma chave pode, portanto, assinar mensagens de negócio e não poder reduzir um limiar. Pode iniciar a troca de uma chave operacional, mas depender de uma função de recuperação. Pode delegar um papel limitado sem apagar outros controladores. Pode revogar a si própria sem nomear, sozinha, um sucessor irrestrito.

Comprovante O que demonstra O que não demonstra sozinho
Assinatura da chave ativa A chave assinou os bytes Ela bastava para esse tipo de transição
Política de transição Papéis, limiares e versão usados As chaves ainda estavam sob controle legítimo
Histórico encadeado O estado segue transições permitidas É o estado mais novo e a única história
Aprovação de recuperação Uma capacidade separada participou Todas as capacidades permaneceram independentes
Evidência de consistência Um conflito foi observado no escopo Não existe uma ramificação ainda desconhecida
Decisão da aplicação A política local aceitou o estado A operação foi executada com sucesso

Prova local não é prova do presente

Local Evidence Verification permite validar o estado apresentado e o histórico autenticado usando material disponível localmente, sem consulta síncrona a uma autoridade designada. Isso ajuda um equipamento de borda, um ambiente isolado ou um local com conectividade intermitente.

O draft registra a limitação: a verificação local não prova que o estado apresentado é o mais recente. Um estado antigo pode manter assinaturas válidas. Duas histórias conflitantes podem ser internamente coerentes. O pacote portátil prova uma sequência; não leva consigo um relógio universal, todos os observadores ou a política da aplicação.

Três campos devem permanecer separados: histórico criptograficamente válido; estado suficientemente atual para o uso; nenhuma história conflitante observada no escopo informado. Uma consulta de diagnóstico pode tolerar evidência de ontem. Uma assinatura financeira pode exigir observação de minutos, checagem cruzada e um veto adicional.

A recuperação acaba onde todas as capacidades se perdem

O draft reconhece o ponto terminal. Nenhum protocolo garante recuperação quando o atacante obtém todos os segredos e todas as capacidades que o próprio protocolo considera suficientes para autorizar o futuro.

Por isso a revisão de arquitetura precisa de uma matriz: apenas a chave operacional; uma chave de um limiar; chave operacional mais parte da recuperação; controle do equipamento sem a capacidade offline; todas as capacidades operacionais e de recuperação; isolamento dos observadores durante o processo. Cada linha precisa dizer se a continuidade ainda é recuperável, quem pode vetar, qual atraso é exigido e quando a única saída é criar uma nova relação de confiança.

“Há suporte a rotação” não responde a essa matriz. A rotação conduzida pela chave comprometida pode ser a etapa que consolida o ataque.

Consistência sem um livro mundial único

ADKM não exige uma ordem total global. Isso evita que a continuidade do identificador dependa da disponibilidade, governança e finalização de um ledger específico. Também permite que um Controller malicioso apresente histórias diferentes a grupos diferentes.

Observadores independentes, gossip, checagem cruzada e transparência aparecem como possibilidades, não como escolha. Certificate Transparency e a Key Transparency Architecture mostram como cabeçalhos de árvore, provas de consistência, monitoramento e troca entre participantes podem revelar visões incompatíveis. Nenhum deles transforma silêncio em prova de unicidade global.

O recibo do observador deve guardar identidade, compromisso visto, horário, estado anterior lembrado, pares consultados e condição de rede. Eclipse, partição, atraso, divulgação seletiva e conluio reduzem o alcance da frase “nenhum conflito observado”.

Modelos vizinhos continuam válidos

RFC 5280 e RFC 6960 trabalham no modelo administrativo de CAs, trust anchors e status de certificado. ADKM não os substitui. RFC 9162 torna emissões auditáveis. RFC 7401 demonstra identificadores autocertificáveis. DID Core oferece um modelo comum, enquanto cada método define atualização, recuperação e versionamento.

A pergunta de ADKM é se continuidade, sucessão autorizada pelo controlador, histórico verificável, contenção de comprometimento e evidência explícita de consistência podem formar um modelo comum e independente da aplicação.

Bytes canônicos não concedem mandato

JCS, CBOR determinístico e dCBOR ajudam implementações a concordar com os bytes assinados. Sem isso, o mesmo evento lógico pode gerar hashes diferentes.

Essa disciplina não decide quem pode reduzir o limiar, não prova a independência da recuperação e não torna o estado atual. A codificação determinística resolve a representação, não a legitimidade da decisão.

O recibo de transição

Registre identificador e vínculo inicial, digest do estado anterior, sequência ou epoch, tipo do evento, chaves antigas e novas, funções e limiares, versão exata da política, cada aprovação com sua classe de autoridade, participação de recuperação, perfil de representação, digest do evento, referências de observação, escopo da busca por conflitos e fonte de atualidade com idade máxima.

Depois, a aplicação produz outro recibo: estado aceito, operação, política local e resultado. Estado autêntico não é autorização, e autorização não é prova de efeito.

Status do texto

A revisão 00 é um Internet-Draft individual, destinado a Informational e com expiração em 24 de março de 2027. Não comprova adoção por grupo, consenso do IETF, implementação, interoperabilidade, implantação, incidente ou segurança de produto. Também não escolhe formato, armazenamento, observador ou mecanismo de recuperação.

Fontes