Resumo

  • Em 28 de setembro, o IETF moveu Key Transparency Architecture para AD Evaluation::Revised I-D Needed após a diretora da Área de Segurança pedir a separação entre o dono do rótulo e a parte que confia nele.
  • Uma busca e uma cabeça de árvore podem ser criptograficamente válidas sem revelar quem autorizou a consulta, quem podia alterar o vínculo e quem ainda deve monitorá-lo.
  • O registro operacional precisa unir prova e contexto: papéis, decisão de acesso, modo de implantação, signatário, limites de tempo, estado anterior e dever futuro.

A biblioteca criptográfica vê uma sequência satisfatória: a prova fecha, a assinatura confere e a nova visão prolonga a anterior. Para ela, o evento terminou.

Para a organização, faltam as perguntas que decidem responsabilidade. O solicitante era dono do rótulo ou alguém usando a chave de outra pessoa para iniciar uma conversa? Qual regra permitiu a divulgação? Quem podia publicar uma nova versão? Quem deve voltar mais tarde para confirmar que um valor recém-observado não sumiu antes que seu dono pudesse percebê-lo? Nenhuma dessas respostas cabe em um simples “válido”.

Esse é o limite exposto em 28 de setembro de 2026 pelos comentários de Deb Cooley, diretora da Área de Segurança do IETF, à revisão 09 de Key Transparency Architecture. O histórico do Datatracker registra a mudança para AD Evaluation::Revised I-D Needed. O documento continua sendo um Internet-Draft que busca um RFC informativo; não é um padrão publicado nem evidência de implantação.

O pedido mais importante parece uma correção de vocabulário. A revisão define User / Account, mas depois distribui tarefas distintas entre o “label owner” e o usuário que consulta o rótulo alheio. Cooley sugere chamar este último de relying party. O dono é o sujeito do vínculo; a parte dependente toma uma decisão com base nele. Colocar ambos sob “usuário” esconde direitos e obrigações diferentes.

A transparência de chaves protege a entrada do sistema de criptografia ponta a ponta. O serviço costuma distribuir as chaves públicas dos participantes. Se associar ao nome de alguém uma chave controlada por um invasor, a cifra pode funcionar e proteger a relação errada. A arquitetura registra esses vínculos em um log criptograficamente protegido e somente anexável. Search, Update e Monitor produzem provas, e respostas posteriores precisam ser coerentes com a visão já guardada pelo cliente.

Uma bifurcação fica permanente, mas não se denuncia sozinha. O documento exige também um terceiro confiável, uma consulta anônima ou comparação entre pares. O terceiro assina uma cabeça recente da árvore, introduzindo a hipótese de que não cooperará com o log para legitimar uma bifurcação. Nos outros caminhos, o próprio cliente procura a contradição. A prova pertence a um processo contínuo de observação.

Os três modos de implantação alocam esse processo de formas distintas.

No Contact Monitoring, o dono verifica periodicamente seu valor mais recente. A parte que consultou uma versão nova retorna depois para confirmar que ela permaneceu visível. O draft exige que o Monitor necessário continue autorizado mesmo se Search ou Update já tiverem sido revogados. Cortar o acesso atual não apaga a obrigação probatória criada por uma observação anterior.

No Third-Party Auditing, o log mantém a maior parte da operação e um auditor assina visões periódicas. A utilidade da assinatura depende do ponto em que a auditoria começou e de seu atraso máximo. Uma assinatura autêntica ainda pode estar velha demais para a decisão.

No Third-Party Management, um gestor externo opera e armazena a maior parte do sistema, enquanto o operador do serviço mantém o controle de acesso e autentica novas versões. O modelo supõe ausência de conluio. A revisão pede que o diagrama inclua uma busca válida feita por quem depende da chave, pois mostrar apenas Alice operando sua própria entrada esconde o fluxo essencial.

O Key Transparency Protocol transforma essas diferenças em configuração: modo, chaves de assinatura e VRF, janela razoável de monitoramento e, quando há auditor, sua chave, posição inicial e atraso máximo. Dizer apenas que a assinatura passou elimina o contexto que define o alcance da prova.

O estado do cliente também é controle. A visão anterior obriga a seguinte a permanecer linear. Perder esse estado reduz a chance de detectar uma bifurcação ou um dado ocultado depois. Para páginas web efêmeras ou cenários em que um adversário pode causar a perda, a arquitetura recomenda gestão por terceiro. A revisão pede exemplos e uma explicação melhor do “estado inválido permanente”, cuja detecção ainda pode exigir presença online por um intervalo limitado.

O acesso fica sob a aplicação. Ela pode limitar busca a contatos, exigir login ou aplicar taxa. A prova demonstra o processamento do log, não o direito da aplicação de mostrar aquele rótulo àquela pessoa. Daí o pedido para abandonar a alternância entre “amigos” e “acesso” e usar linguagem consistente de ACL.

Privacidade e exclusão seguem outro relógio. Dados serializados podem ser removidos depois de expirarem ou se tornarem inacessíveis, enquanto material criptográfico necessário pode permanecer até o fim de sua vida máxima. Uma função aleatória verificável oculta rótulos. A revisão propõe tornar RFC 9381 normativa se o leitor precisa compreender VRF e reunir a discussão de privacidade.

Há ainda dependência entre documentos. O parecer do shepherd chama a arquitetura de base do protocolo; para publicá-la primeiro, referências ao protocolo devem ser exemplos. A revisão também pede explicar o uso de RFC 6962, versão implantada de Certificate Transparency, em relação a RFC 9162. MLS fornece contexto para credenciais, sem provar adoção de KT.

A resposta operacional é um recibo qualificado por papel. Além da prova e da versão do rótulo, ele deve guardar papel do solicitante, dono, política e versão, modo, signatário, tamanho e tempo da árvore, atraso aceito, estado anterior e Monitor pendente. Assim, a organização separa prova inválida, consulta não autorizada com prova válida, visão antiga do auditor, monitoramento omitido e perda de continuidade do cliente.

A revisão 10 pode resolver os comentários por outro desenho. O limite permanece: uma história append-only torna a fraude detectável; papéis explícitos dizem quem tem de detectá-la.

Fontes