Resumo

  • O grupo OpenPGP abriu em 4 de setembro uma chamada de adoção para o rascunho que marca o material secreto como externo e permite uma dica opcional de localização. A consulta termina em 18 de setembro; ainda não há resultado declarado.
  • A dica é apenas consultiva. O consumidor pode fazer descoberta por melhor esforço mesmo quando ela existe, falha ou é desconhecida. A versão 03 não define um esquema concreto, e o registro atual da IANA não tem a entrada External proposta.
  • O stub preserva uma referência criptográfica, mas não carrega suporte do software, presença do dispositivo, autorização ou recuperação. Essas observações precisam de um recibo local separado e protegido.

A adoção ainda é uma pergunta

Stephen Farrell enviou a chamada em 4 de setembro, depois de o assunto ter sido apresentado na IETF 126. O grupo foi convidado a dizer se deve assumir draft-dkg-openpgp-external-secrets-03 como trabalho coletivo. O prazo informado é 18 de setembro.

O Datatracker registra Call For Adoption By WG Issued para o grupo e I-D Exists no IESG. A versão 03, datada de 22 de julho, continua sendo Internet-Draft individual, sem endosso formal do IETF, e expira em 23 de janeiro de 2027.

Daniel Kahn Gillmor, Andrew Gallagher e Heiko Schäfer manifestaram apoio. Paul Schaub confirmou que aceitaria coeditar se houver adoção. As mensagens mostram interesse e argumentos; não são votos nem permitem anunciar a conclusão que cabe aos presidentes registrar.

O mesmo cuidado vale para o código. O rascunho escreve 252? como possível novo S2K Usage Octet e propõe um registro de dicas. O registro OpenPGP publicado pela IANA ainda não mostra External em 252 nem o novo registro. A seção IANA de um rascunho é pedido futuro, não estado presente.

O que permanece dentro do arquivo

RFC 9580 define a estrutura de pacotes de chave secreta e de uma Transferable Secret Key. A versão 03 propõe manter os parâmetros públicos associados, definir o uso S2K como External e permitir dados adicionais com uma dica. Os parâmetros secretos não entram no pacote.

Assim, uma implementação pode perguntar aos subsistemas que conhece se algum deles lista material correspondente àquela chave pública. A identidade criptográfica oferece uma base mais robusta que um apelido local ou o número de uma gaveta.

A dica, porém, não é ordem de roteamento. O texto a chama de inteiramente consultiva. Sem dica, a descoberta é por melhor esforço. Se o formato for desconhecido ou apontar para um lugar que não funciona, o consumidor pode ignorá-lo e procurar entre os mecanismos suportados. Pode fazer isso até quando entende a dica.

A versão 03 não define nenhum esquema específico. O registro proposto começaria vazio, reservaria 96–111 para uso privado ou experimental e aplicaria Specification Required às demais atribuições. O documento cria um espaço para vocabulários posteriores, não uma lista universal de endereços.

Uma correspondência não concede acesso

Uma chave pode estar em dois dispositivos. O mesmo cartão USB pode ganhar outro caminho físico ao mudar de porta ou computador. Um programa fala com OpenPGP Card, outro com TPM, outro com HSM remoto. A URI PKCS #11 resolve identificação dentro de seu ambiente, mas não transforma todos os subsistemas em uma arquitetura única.

Quando a chave pública coincide, existe um candidato. Isso não prova propriedade legítima, autorização para aquela assinatura nem inexistência de outra cópia. O dispositivo ainda pode exigir PIN, senha, biometria ou botão; pode listar a chave e negar a operação; pode estar lento ou bloqueado.

Quando nada é encontrado, a conclusão também é limitada. Talvez o driver esteja ausente, o cartão desconectado, a conta vencida ou aquela classe de equipamento fora do alcance do programa. “Não acessível aqui agora” não equivale a “a chave deixou de existir”.

O rascunho recomenda que enumerar chaves públicas e verificar correspondência não exija autorização. Para a operação secreta, o desafio pode ser necessário. Se dois dispositivos oferecem a mesma chave, tentar primeiro aquele sem desafio pode evitar bloqueio por PINs errados. A aplicação deve informar a interação física esperada, usar tempo limite razoável e mostrar erros que levem a uma ação.

Uma migração confiável separa pelo menos quatro resultados: o stub foi lido; um subsistema compatível foi localizado; a autorização foi satisfeita; a operação terminou. Um backup pode passar pelo primeiro e falhar nos três seguintes.

O segredo protegido não protege todo o fluxo

Hardware externo pode reduzir extração do segredo. Alguns dispositivos limitam operações, exigem um gesto visível ou atestam geração interna. Um token móvel leva capacidade entre computadores sem copiar o material secreto para cada disco.

O texto preserva as ressalvas. Hardware pode ter falhas e sofrer ataque físico. Um computador comprometido pode roubar texto claro ou a chave simétrica de sessão após a descriptografia. Numa assinatura, a pessoa pode apertar o botão acreditando aprovar um documento enquanto o host fornece outro objeto ao dispositivo.

Gillmor escreveu em sua resposta que dispositivos não são uma troca sensata para quase todo usuário de OpenPGP, mas apoiou uma representação simples para quem os quer. Schäfer observou que certos contextos efetivamente precisam deles. A padronização da representação não transforma uma escolha de custódia em recomendação universal.

O recibo de entrega deve ficar separado

O pacote global não deve carregar inventário corporativo. Números de série, partições de HSM, contas, aprovadores e rotas de recuperação mudam e são sensíveis. A operação local, entretanto, precisa de um recibo de entrega de chave externa. Esta é minha proposta editorial, não requisito do IETF ou do OpenPGP.

O recibo protegido pode associar fingerprints do certificado e da subchave, versão do rascunho ou RFC, estado real do código, esquema de dica compreendido, implementação, classe de subsistema, horário, método de correspondência, desafio de autorização, operação tentada e resultado. Substituição ou recuperação deve ligar a observação antiga à nova.

Para divulgação bastam referência opaca, classe de capacidade e resultado verificado. Serial, PIN, biometria e topologia ficam sob controle de acesso. O recibo registra uma observação; não cria titularidade ou permissão.

O Policy Mirror de Heng Lu evita que um artefato fale ao mesmo tempo pelo ator, pela regra e pela prova. A Minimum Initial Specification permite manter estreito o núcleo comum e extensível o registro local. Why BTW Media Exists exige o tempo verbal certo: chamada aberta, código proposto, capacidade ainda dependente do ambiente.

O stub é valioso porque admite o que não possui. Ele transporta a referência; a organização ainda precisa provar que o segredo estará utilizável quando for chamado.

Fontes

  1. Chamada de adoção do grupo OpenPGP
  2. Registro atual no Datatracker
  3. OpenPGP External Secret Keys, versão 03
  4. Apresentação na IETF 126
  5. Resposta de Daniel Kahn Gillmor
  6. Resposta de Andrew Gallagher
  7. Resposta de Heiko Schäfer
  8. Resposta de Paul Schaub
  9. Registro OpenPGP da IANA
  10. RFC 9580 — OpenPGP
  11. RFC 8126 — política de registro
  12. RFC 7512 — URI PKCS #11
  13. Heng Lu — The Policy Mirror
  14. Heng Lu — Minimum Initial Specification
  15. Heng Lu — Why BTW Media Exists