Resumo

  • A IETF redefiniu a carta da LAMPS para manter PKIX e S/MIME e avançar em estabelecimento híbrido de chaves, assinaturas duplas e processamento enxuto de certificados.
  • A carta confere autoridade de agenda; ela não adota um rascunho, publica uma RFC, entrega software, instala âncoras ou comprova interoperabilidade.

Uma autoassinatura não é uma concessão de confiança

A carta usa um certificado X.509 sem assinatura como exemplo de troca mais leve. Assinaturas pós-quânticas podem ser grandes; para um equipamento que recebe uma âncora por configuração protegida, carregar uma autoassinatura pode consumir recursos sem acrescentar a decisão de confiança.

A raiz assinar a si mesma não explica por que a parte verificadora deve aceitá-la. A RFC 5280 trata as informações da âncora como entrada da validação de caminho, obtida por procedimento confiável fora de banda. A RFC 5914 define o formato TrustAnchorInfo em separado.

O controle está no processo de instalação: quem autorizou, como o canal foi autenticado, qual nome e chave foram fixados, quais restrições viajaram, qual âncora antiga saiu e como reverter. Um contêiner menor pode ser adequado se essa trilha permanecer inteira. Sem ela, a economia também elimina a origem da autoridade.

Hoje, trata-se de um problema que a carta permite investigar. Não é um mecanismo padronizado nem uma implantação observada.

O anúncio de 21 de agosto mudou o mandato

Às 20h40 UTC de 21 de agosto de 2026, a IETF anunciou a nova carta do grupo Limited Additional Mechanisms for PKIX and SMIME. O Datatracker mostra a LAMPS ativa e a revisão 08 aprovada.

O grupo conserva mecanismos oriundos dos trabalhos encerrados de PKIX e S/MIME, incluindo CMP, CMC, EST, S/MIME e PKIX. Também prepara esses ambientes para algoritmos que possam substituir ou acompanhar RSA, Diffie-Hellman, ECDSA, ECDH e EdDSA.

O mandato não é aberto. A carta exige uma comunidade conhecida interessada em implantação real e pelo menos uma abordagem especificada o bastante para uma decisão de adoção. Isso legitima a análise; não valida a técnica. A proposta ainda pode falhar na revisão de segurança, dividir operadores ou não obter consenso.

O padrão do algoritmo não entrega o perfil

O NIST publicou FIPS 203 para ML-KEM, FIPS 204 para ML-DSA e FIPS 205 para SLH-DSA. A carta também admite algoritmos avaliados pela CFRG.

Esses padrões não definem sozinhos como certificados PKIX, objetos CMS, protocolos de inscrição e aplicações S/MIME vão codificar e aceitar os mecanismos. Faltam perfis, parâmetros, regras de validação e erro, vetores de teste e implementações.

As especificações devem usar OIDs atribuídos pelo NIST ou pela IANA. O identificador torna a construção nomeável; não instala suporte nem altera política local.

Por isso, “pronto para PQC” precisa ser desmontado em evidências: padrão, perfil, OID, estado documental, código, configuração, objeto emitido, objeto aceito e resultado observado.

Combinar segredos exige um método comum

O estabelecimento híbrido junta segredos de algoritmos tradicionais com resultados pós-quânticos elegíveis. A LAMPS deverá definir formatos, identificadores, inscrição e operação.

Não basta concatenar dois valores. As pontas precisam concordar sobre codificação e derivação. A carta cita HKDF, métodos do NIST SP 800-56C ou função avaliada pela CFRG. A separação entre extração e expansão na RFC 5869 torna sal, contexto e comprimento parte do protocolo.

Também é preciso dizer o que se preserva se um componente for quebrado, implementado incorretamente, substituído ou omitido. O texto de composite KEM continua um Internet-Draft ativo. Ele prova atividade de especificação, não concordância final entre produtos.

Duas assinaturas criam várias políticas de aceitação

O trabalho de assinaturas duplas combina mecanismos tradicionais e pós-quânticos. O documento de assinaturas compostas também permanece ativo como rascunho.

O verificador precisa saber se todos os componentes são obrigatórios, se uma fase transitória aceita apenas um, como OIDs vinculam chaves e assinaturas, e o que fazer quando uma biblioteca entende o invólucro mas não um componente. Uma regra permissiva pode reduzir a proteção combinada à autoridade tradicional.

Autoridade certificadora, produtor CMS, cliente de e-mail, biblioteca e aplicação podem estar em estágios diferentes. O serviço funciona na interseção. Contar certificados com material novo não demonstra que intermediários o preservam ou que o destinatário o aceita.

O mês é um instrumento de coordenação

A carta aponta outubro de 2026 para assinaturas compostas em PKIX/CMS, novembro para composite KEM e dezembro para CAA Security. São marcos de trabalho, não garantias de IETF Last Call, aprovação do IESG, RFC, versão de software ou implantação.

Um atraso pode revelar complexidade ou falta de revisão sem condenar a criptografia. Cumprir a data também não prova que o dispositivo suporta o tamanho ou que o repositório de confiança tem retorno seguro.

O relatório executivo deve separar o relógio institucional da evidência operacional.

A autoridade da carta termina na fronteira do grupo

Uma carta dá abrigo ao documento, atrai revisão e torna o problema parte legítima do trabalho. Não transforma a LAMPS em autoridade certificadora, reguladora de algoritmos ou administradora remota de âncoras.

O NIST responde pelos seus padrões; autoridades designadas atribuem identificadores; o processo IETF decide o estado do documento; fornecedores escrevem código; operadores e donos de produto configuram a aceitação. Mesmo descrita em uma RFC, a âncora instalada é uma concessão local.

Para cada item, preserve revisão da carta, problema, comunidade de implantação, versão do rascunho, adoção, objeções, consenso, análise de segurança, dependências, identificadores, testes, implementações independentes, inscrição, configuração verificadora, retorno e troca medida.

Sources