Transparência de chaves não audita permissão de busca

Summary

A prova de busca do KEYTRANS autentica o resultado de uma operação já admitida e ajuda a verificar a consistência do log; a decisão anterior, tomada pela aplicação, fica fora do que a prova demonstra.
O rascunho de arquitetura permite controles de acesso definidos pelo serviço, como autenticação, propriedade, relacionamento e limitação de taxa. Essa liberdade protege a existência de identidades e dados após revogação, mas deixa uma superfície de poder sem evidência equivalente.
Daniel Kade propõe um recibo de política de consulta com versão da regra, classe de operação, requerente e relacionamento, código de decisão, época do log, exceção e correção, sem registrar nomes, rótulos brutos, chaves públicas, grafo de contatos ou histórico integral. É uma proposta de governança, não uma exigência do IETF.

A árvore transparente começa depois da portaria

Alice pede a chave de Bob. A aplicação considera a consulta permitida e a encaminha ao serviço KEYTRANS. A resposta inclui o caminho de verificação da árvore pesquisável e uma relação com o log somente-acréscimo. Alice valida a prova e passa a monitorar o estado relevante. O resultado que recebeu é compatível com a raiz autenticada.

Fred pede a mesma chave, mas a aplicação conclui que falta uma relação autorizadora. O pedido é interrompido na camada de transporte. Não há uma prova falsa para Fred; não há operação de protocolo para provar. Um auditor que observe apenas raízes, inclusões e consistência verá o caminho de Alice e não terá como distinguir a recusa de Fred de uma consulta que nunca existiu.

Essa assimetria define o problema. Transparência de dados responde se uma saída admitida pertence ao estado comprometido. Governança de acesso pergunta se a admissão foi feita sob uma regra estável, aplicável, proporcional e corrigível. Confundir as duas transforma uma garantia precisa em uma reputação institucional que o protocolo não prometeu.

O que a prova realmente cobre

O risco de fundo é concreto. Em sistemas de criptografia ponta a ponta, o serviço que distribui chaves públicas pode substituir uma chave e se inserir numa conversa que parece segura. KEYTRANS combina uma árvore de prefixos pesquisável com uma árvore de log somente-acréscimo para tornar verificáveis os vínculos entre rótulos e valores, as atualizações e a evolução do estado.

Quando cliente, serviço e monitores cumprem as suposições do desenho, uma prova corretamente verificada pode mostrar que o valor devolvido pertence à árvore comprometida e que o histórico observado é compatível com o que outros deveriam ver. A experiência de transparência de certificados nos RFCs 6962 e 9162 mostra por que compromissos e provas de consistência podem tornar detectável uma alteração que antes ficaria escondida.

Ainda assim, os documentos em foco não são padrões finais. draft-ietf-keytrans-architecture-09, de 30 de junho de 2026, é um Internet-Draft do grupo de trabalho, destinado à categoria Informational e com expiração indicada para 1º de janeiro de 2027. draft-ietf-keytrans-protocol-05 também permanece em elaboração. A carta aprovada delimita trabalho; não atesta implantação.

A arquitetura afirma que KEYTRANS não funciona como padrão isolado. Ele precisa ser integrado ao serviço, e essa integração conserva o controle de acesso da aplicação. Search, Update e Monitor são operações distintas. A prova de uma busca aceita não contém, por definição, a decisão externa que autorizou sua chegada.

Restringir a busca pode ser a opção correta

Uma política totalmente aberta criaria outro dano. Descobrir se uma identidade existe num serviço pode revelar associação, profissão, condição protegida ou vínculo com uma comunidade. O RFC 6973 oferece um vocabulário para avaliar essas exposições; o RFC 7258 adverte que a coleta e correlação em escala também são ameaças técnicas. Auditar não pode significar publicar o grafo social.

Por isso, a carta ativa do KEYTRANS prevê que a existência de identidades e dados de conta só seja exposta a clientes autorizados a perguntar. A arquitetura deixa a aplicação reaproveitar autenticação e autorização existentes e, com poucas exceções, aplicar regras próprias: usuário autenticado, proprietário do rótulo, relação de amizade, vínculo organizacional, limite de taxa ou outras condições do produto.

A flexibilidade é necessária porque um protocolo de diretório não conhece o significado social de cada relação. Mas ela também permite que decisões institucionalmente diferentes tenham a mesma aparência externa. Uma defesa legítima contra enumeração, um bloqueio temporário por abuso, uma exceção emergencial vencida, uma diferenciação comercial e uma falha podem terminar como simples ausência de busca no log.

Revogação transforma permissão em trajetória

Contact Monitoring mostra que acesso não é apenas um botão. Depois de consultar um contato, o cliente pode precisar continuar certas operações Monitor referentes a versões já vistas, mesmo que perca permissão para novas buscas ou atualizações. O protocolo descreve uma via estreita para essa continuidade e admite usar a abertura de um compromisso como prova de uma autorização anterior.

Há uma razão de segurança. Cortar todo monitoramento no instante da revogação pode impedir a detecção de uma troca de chave que afete uma conversa existente. Manter acesso irrestrito a novos dados, por outro lado, anularia a revogação. Os RFCs 9420, 9458 e 9614 também situam a segurança de mensagens em estados, credenciais e mudanças de membros ao longo do tempo, não em uma única decisão de login.

Um registro de governança precisa, portanto, representar transições: qual versão de política retirou Search, qual obrigação Monitor sobreviveu, qual evidência permitiu a continuidade e quando ela termina. Escrever apenas “negado” perderia a distinção que o próprio desenho do protocolo considera necessária.

Terceirizar não revela automaticamente o ponto cego

Na gestão por terceiro, o operador do serviço continua controlando a porta. O gestor pode receber rótulos e valores em texto claro, histórico e tráfego das operações aceitas. Pedidos recusados antes da integração talvez nunca cheguem a ele. Mesmo um gestor honesto consegue verificar somente o universo que lhe foi entregue.

Na auditoria por terceiro, a visibilidade é diferente. O auditor pode observar número, ordem e horário de mudanças enquanto rótulos e valores permanecem mascarados. Isso reduz exposição do conteúdo, porém não cria um censo das consultas negadas fora do log. Operador, gestor e auditor podem cumprir seus papéis e, ainda assim, compartilhar um vazio entre as interfaces.

A arquitetura também considera situações em que uma entidade controla vários serviços. Um proxy pode reduzir a ligação entre identidades, e o texto recomenda não combinar ou espelhar logs de maneira que interfira nas políticas. Uma base central com todos os pedidos recusados contrariaria esse cuidado se permitisse recompor relações entre serviços.

Um recibo mínimo para a política de consulta

O complemento adequado não é um dossiê público de pesquisas. É um recibo de decisão, produzido no momento em que a aplicação permite ou recusa a operação e ligado à versão de política em vigor. Sua finalidade é permitir testes delimitados por auditores autorizados, sem revelar quem procurou quem.

O recibo poderia guardar: classe da operação — Search, Update ou Monitor —, classe ampla do requerente, classe do relacionamento, resumo do alvo calculado com chave rotativa, código da decisão, época do log, categoria da regra ou evidência, autoridade e vencimento de uma exceção, estado de correção, prazo de retenção e identificador de teste agregado. A rotação reduz a capacidade de correlacionar o mesmo alvo por anos.

Deveriam ficar de fora nomes de usuário, rótulos brutos, material de chave pública, credenciais, mensagens, endereços IP completos, identificadores persistentes de dispositivo, relações em texto claro e o histórico total de busca de uma pessoa. O recibo requer controle de acesso, separação de chaves, modelo de ameaça e eliminação programada; não é licença para ampliar vigilância.

Com esse desenho, perguntas estreitas tornam-se possíveis. Pedidos da mesma classe e mesma versão de política receberam tratamento consistente? Exceções expiradas continuaram em uso? O Monitor necessário após revogação foi preservado? Uma contestação aceita resultou em correção? Nenhuma dessas respostas exige publicar a identidade de Alice, Fred ou Bob.

Comprometer hashes de recibos numa árvore também não basta. Uma raiz prova a integridade dos recibos apresentados, não a existência de recibos para todas as decisões. Cobertura exige reconciliação com contadores da entrada, amostragem independente, detecção de lacunas ou execução sob controles adicionais. Evidência verificável e evidência completa são propriedades diferentes.

Exclusão de dados confirma a divisão de responsabilidades

A arquitetura separa valores que podem ser apagados quando a política da aplicação os torna permanentemente inacessíveis do material criptográfico necessário ao protocolo. O log não conhece a razão normativa da exclusão. Cabe à aplicação coordenar inacessibilidade, retenção, exceções e obrigações Monitor.

O mesmo princípio deve reger o recibo. Ele pode expirar, ser agregado e perder seu vínculo por rotação sem que a organização perca toda capacidade de testar decisões recentes. Uma trilha eterna seria perigosa; ausência total de trilha tornaria erros e exceções invisíveis. A governança útil mora nessa faixa estreita.

Limites do que se sabe

As fontes congeladas não demonstram que um serviço nomeado tenha implantado os rascunhos. Também não fornecem taxa de negação, incidência de erro, caso de discriminação, incidente de privacidade, custo de desempenho ou conclusão jurídica. Este artigo não acusa um operador e não trata texto de grupo de trabalho como fato de mercado.

Os rascunhos podem mudar antes de qualquer publicação como RFC. A carta define objetivos e entregáveis, não adoção. A proposta de recibo é uma inferência de governança baseada na separação descrita nos documentos, e não linguagem normativa retirada deles.

A conclusão comprovável é mais modesta. KEYTRANS pode autenticar a resposta dada a uma consulta autorizada. Não autentica a regra que decidiu quem tinha autorização para consultar. Proteger a privacidade exige uma porta; proteger a legitimidade exige que a porta deixe uma evidência mínima, limitada e testável.

Uma prova de transparência de chaves não audita quem podia consultar

Por que isso importa

Summary

A árvore transparente começa depois da portaria

O que a prova realmente cobre

Restringir a busca pode ser a opção correta

Revogação transforma permissão em trajetória

Terceirizar não revela automaticamente o ponto cego

Um recibo mínimo para a política de consulta

Exclusão de dados confirma a divisão de responsabilidades

Limites do que se sabe

Sources

Contexto aprofundado do perfil

Strategic Circle

Leadership Alliance

Briefing do Strategic Circle

Briefing da Leadership Alliance