Resumo

  • Em draft-ietf-keytrans-architecture-09, o tombstone no log antigo conduz a busca ao novo e evita aceitar um valor anterior só porque o destino está fora do ar.
  • O mesmo texto mantém os dois logs sob monitoramento e exige que o antigo continue operacional por tempo suficiente para usuários, inclusive os que ficaram muito tempo offline, concluírem a verificação.
  • Um recibo de aposentadoria deve ligar a cabeça final, o canal de distribuição, grupos de clientes, evidências de conclusão, exceções, autoridade e condição de restauração. O recibo é uma proposta deste artigo, não texto normativo do KEYTRANS.

Os primeiros aparelhos a migrar contam a parte fácil da história. A parte difícil chega meses depois, quando um telefone restaurado de backup apresenta uma cabeça de árvore anterior à troca. O aplicativo já conhece o log novo, mas o endereço antigo foi removido. O usuário consegue procurar a chave corrente; não consegue provar que o estado guardado por ele conduz, sem desvio, à última história do log anterior.

O rascunho de arquitetura identifica a perda: se o log antigo for desligado antes de um usuário completar o monitoramento, esse usuário pode ficar incapaz de detectar certas formas de má conduta daquele log. Copiar os valores e redirecionar as consultas não encerra essa obrigação.

O tombstone governa precedência. Não é uma ata de encerramento.

Uma regra contra a ressurreição de valores antigos

Mesmo num serviço com criptografia de ponta a ponta, o provedor costuma distribuir a associação entre identidade e chave pública. Um provedor comprometido pode substituir uma chave ou mostrar visões diferentes. Key Transparency usa um log pesquisável e protegido criptograficamente para que titulares e contatos verifiquem uma visão globalmente coerente.

A carta do KEYTRANS chama o mecanismo de componente. Ela não promete interoperabilidade completa entre serviços nem resolve recuperação de conta, autenticação e suporte a aparelhos. Essa contenção importa: o protocolo pode definir uma história verificável, mas o período de suporte é uma responsabilidade do aplicativo.

Há bons motivos para trocar de log: nova chave, suíte criptográfica ou forma de implantação, aumento de capacidade e recuperação de falha. Por isso, a arquitetura recomenda clientes preparados para vários logs independentes. Ela também exige uma política uniforme para Search, Update e Monitor.

Na migração gradual, Search consulta primeiro o log antigo. Só passa ao novo se a versão mais recente do rótulo for um tombstone definido pelo aplicativo. Updates normais entram no novo; o antigo recebe apenas o tombstone ausente. Assim, uma pane no destino não autoriza o retorno à chave pré-migração.

O marcador prova onde procurar a versão mais nova. Não prova que o conteúdo migrado está correto, que seu titular o conferiu, que todos os clientes o receberam ou que o histórico anterior já pode desaparecer.

Dois logs deixam duas tarefas em aberto

O documento manda monitorar ambos como serviços independentes. O antigo deve parar de aceitar modificações em um ponto conhecido e permanecer disponível enquanto clientes ligam o estado que guardaram à cabeça final. O novo deve apresentar as versões migradas; o titular precisa processar o Update e confirmar o próprio rótulo.

“Aplicativo atualizado” não equivale a isso. O pacote pode estar instalado e nunca aberto. Um contato com o log novo pode ocorrer sem verificação do rótulo. O aparelho principal pode ter concluído enquanto um backup antigo retorna depois. Conta inativa tampouco significa renúncia.

O rascunho não escolhe uma quantidade universal de dias. Pede tempo suficiente e lembra que alguns usuários ficam offline por muito tempo. Um mensageiro empresarial crítico, um produto de consumo e um cliente web efêmero têm compromissos diferentes. Colocar um único prazo na especificação comum esconderia a decisão local.

O modo de monitoramento também altera a evidência. Auditor ou gestor externo, canal anônimo e troca entre pares têm pressupostos próprios de não conluio, frequência e retenção de estado. Uptime sozinho não demonstra capacidade de detectar bifurcações.

A cabeça final não toma decisões

Na migração imediata, a arquitetura pede que tamanho final e raiz do log antigo sejam distribuídos por canal confiável. Usuários fazem a última consulta Monitor até esse ponto. Titulares iniciam o estado no log novo processando o Update da versão migrada e verificando seu conteúdo.

O ponto pode viajar num rótulo conhecido do log novo ou com o código do aplicativo. Isso cria um término criptográfico comum, mas não identifica quem escolheu a data, quais versões o receberam ou como tratar quem voltar com cabeça anterior.

O protocolo inclui max_ahead, max_behind, uma reasonable_monitoring_window obrigatória e maximum_lifetime opcional. A janela expressa a frequência geral esperada de monitoramento e organiza referências comuns. Não mede usuários reais. A vida máxima ajuda a limitar armazenamento; não vira automaticamente um contrato de suporte.

Um recibo de aposentadoria

O recibo pode preservar privacidade e ainda permitir revisão.

Limite antigo. Configuração, identidade de assinatura, último instante de modificação, tamanho e raiz finais, modo e prova de consistência com a cabeça anterior.

Regra de migração. Identidades dos logs, destino de Search, Update e Monitor, significado do tombstone e versões que aplicam a regra. Redirecionar busca não significa apagar dever probatório.

Distribuição. Canais autenticados da cabeça final e entrega por versão, plataforma, frota administrada, conta adormecida e backup restaurado. Downloads agregados não bastam.

Conclusão. Contato com o novo log, verificação do rótulo, Monitor final do antigo e teste de recuperação precisam de colunas separadas.

Ausência. Prazo de retorno suportado, reinstalação, múltiplos aparelhos, idade de backup, contas inacessíveis e via de exceção, distinguindo medição de estimativa.

Autoridade e reversão. Segurança atesta fechamento criptográfico; o dono do serviço aceita risco de disponibilidade; privacidade ou jurídico limita retenção; um papel nomeado aprova o desligamento. Cabeça conflitante ou cliente sem ponte exige extensão, restauração ou investigação.

Não chamar rascunho de padrão publicado

A revisão 09 é um Internet-Draft com intenção Informational e pedido de publicação no IESG. A revisão do shepherd registra consenso sem objeções relevantes numa comunidade especializada relativamente pequena. Isso demonstra avanço, não um RFC final nem adoção comercial.

O protocolo ainda muda. As atas do IETF 126 registram proposta de novo formato para UpdateRequest porque o anterior não era implementável, além do alerta de que a liberdade de formatos de transporte pode gerar não interoperabilidade. A conversa não é consenso normativo. Ela confirma que arquitetura, versão, código em execução e decisão de aposentadoria têm evidências próprias.

O mínimo comum é claro: a falha do log novo não pode reanimar uma chave velha, e o fechamento do antigo não deve destruir sem justificativa o caminho de monitoramento. O prazo concreto pertence a uma instituição identificável, não ao tombstone.

Fontes

  1. Arquitetura KEYTRANS, revisão 09
  2. Histórico e revisão do shepherd
  3. Protocolo KEYTRANS, revisão 05
  4. Carta do grupo KEYTRANS
  5. Atas do KEYTRANS no IETF 126
  6. Lu Heng, “Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption”
  7. Lu Heng, “Running Code Primary”