Resumo

  • O IESG aprovou draft-ietf-lamps-cms-composite-kem-03 em 18 de setembro de 2026, mas o documento continua sendo um Internet-Draft. O Datatracker o mostra em RFC Ed Queue, com RFC Editor blocked: Reference Not Received; a revisão IANA está em IANA OK - Actions Needed e a ação em In Progress.
  • O bloqueio não é meramente editorial. O documento CMS depende normativamente de draft-ietf-lamps-pq-composite-kem-21, que define operações, transporte das chaves públicas em certificados X.509 e identificadores Composite ML-KEM. Essa dependência continua em IESG Evaluation::Revised I-D Needed, com dois DISCUSS registrados e trabalho IANA ainda necessário.
  • O risco operacional central é confundir marcos formais diferentes. Existência de OIDs, aprovação de um companion, código interoperável em determinadas condições ou um teste de laboratório não demonstra que duas implementações específicas, usando versões e combinações específicas, estejam prontas para produção.
  • Uma implantação controlada deveria exigir um companion-dependency receipt: um recibo verificável que congele versões e hashes, estados de padronização e IANA, identidade dos OIDs, suporte dos endpoints, vetores utilizados, resultado de interoperabilidade e política explícita de fallback, rollback e saída.

A aprovação resolveu uma etapa, não a cadeia

A Protocol Action de 18 de setembro é inequívoca: o IESG aprovou draft-ietf-lamps-cms-composite-kem-03 como Proposed Standard. O anúncio também descreve o texto como companion de draft-ietf-lamps-pq-composite-kem-21 e registra consenso no grupo de trabalho LAMPS. O mesmo anúncio aponta trabalho de implementação e hackathon como evidência de qualidade do documento.

Esses sinais têm valor, mas respondem a perguntas diferentes.

A aprovação do IESG responde à pergunta de governança de padrões: o documento passou pela decisão necessária para seguir em direção à publicação na trilha pretendida. Ela não responde se o RFC Editor já publicou o texto, se todas as referências normativas estão disponíveis, se todas as ações IANA foram concluídas ou se dois produtos comerciais conseguem executar a mesma combinação em produção.

O próprio estado operacional expõe essa diferença. O Datatracker mostra o documento CMS em RFC Ed Queue, enquanto o RFC Editor aparece como blocked: Reference Not Received. A IANA, por sua vez, ainda registra IANA OK - Actions Needed e ação In Progress. A página de desempenho da IANA também lista o draft CMS como In Progress, recebido em 18 de setembro.

Portanto, “aprovado” e “publicado” não são sinônimos. Muito menos são sinônimos de “implementado” ou “ativado”.

O gargalo está na referência normativa

A dependência é estrutural porque o companion CMS não redefine autonomamente o Composite ML-KEM.

draft-ietf-lamps-cms-composite-kem-03 explica como utilizar Composite ML-KEM dentro do CMS por meio de KEMRecipientInfo, estrutura já definida pelo RFC 9629. Mas as operações fundamentais de Composite ML-KEM são atribuídas ao documento dependente: KeyGen, Encaps e Decaps são definidos em draft-ietf-lamps-pq-composite-kem. O companion mapeia essas operações para a terminologia de Encapsulate() e Decapsulate() usada no RFC 9629 e explicita até uma diferença na ordem dos valores retornados pela função de encapsulação, um detalhe pequeno em aparência e relevante para implementações que cruzem as duas especificações.

A dependência continua no certificado. Para Composite ML-KEM, a chave pública estática do destinatário é obtida de um certificado, mas as convenções para transportar essa chave pública em X.509 são remetidas explicitamente ao draft de Composite ML-KEM para PKIX. Os identificadores Composite ML-KEM usados pelo CMS também vêm dessa especificação; o texto CMS os reproduz para conveniência, não cria uma origem independente para eles.

O companion acrescenta então a camada propriamente CMS: regras para KEMRecipientInfo, relacionamento com KDF e key wrapping, convenções de certificado no contexto CMS e anúncio de capacidades por SMIMECapabilities. Nesse último caso, uma implementação pode anunciar suporte a um ou mais identificadores Composite ML-KEM; o OID correspondente deve ocupar capabilityID, sem parâmetros associados.

Essa separação cria uma cadeia clara:

Composite ML-KEM base → chave e OID em PKIX → certificado do destinatário → KEMRecipientInfo → processamento CMS → anúncio de capacidade → interoperabilidade entre endpoints.

Se uma camada permanece móvel, o fato de uma camada superior já ter sido aprovada não elimina essa mobilidade.

A dependência ainda está em avaliação

Em 21 de setembro, o Datatracker continua mostrando draft-ietf-lamps-pq-composite-kem-21 como IESG Evaluation::Revised I-D Needed. A página declara explicitamente dois DISCUSS e informa que há posições suficientes para a aprovação quando essas posições forem resolvidas. Também registra IANA OK - Actions Needed.

Os DISCUSS visíveis foram lançados durante a revisão da versão -20, incluindo questões sobre normatividade de apêndice e referência formal para sintaxe ASN.1. A existência da revisão -21 não autoriza concluir, sem mudança correspondente do estado no Datatracker, que essas posições foram encerradas. O indicador operacional relevante é o estado publicado pelo processo, não a simples existência de uma nova versão.

O companion CMS, por sua vez, referencia normativamente exatamente draft-ietf-lamps-pq-composite-kem-21, de 1º de setembro de 2026. Isso é importante para rastreabilidade: “a dependência” não deveria ser tratada como um nome flutuante. Para reproduzir uma decisão técnica é necessário saber qual revisão forneceu as definições utilizadas.

Há ainda um vínculo material dentro do ASN.1. O módulo do companion CMS contém placeholders a serem substituídos e uma instrução para que o RFC Editor use o número de módulo atribuído ao módulo Composite ML-KEM da especificação dependente. Em outras palavras, a dependência está embutida também na resolução final do namespace, não apenas na bibliografia.

Sete estados que não devem ser comprimidos em um único “pronto”

Para operadores, fornecedores e compradores, a forma mais segura de acompanhar esse trabalho é abandonar uma variável binária de prontidão. Há pelo menos sete estados independentes.

Estado Evidência apropriada O que não demonstra
Aprovação de padrão decisão e estado do IESG publicação de RFC
Publicação número RFC e conclusão da fila editorial suporte em produtos
Trabalho IANA registro e ações concluídas implementação correta
Definição algoritmo/OID especificação e procedência exatas disponibilidade bilateral
Suporte de implementação versão, build e combinação suportada interoperabilidade com outro fornecedor
Interoperabilidade bilateral teste entre endpoints identificados, com vetor e escopo definidos adequação ao ambiente produtivo inteiro
Ativação em produção política, configuração, certificados, monitoramento e rollback efetivamente habilitados adoção universal ou segurança de qualquer outra combinação

Essa decomposição elimina uma fonte frequente de erro gerencial: usar um artefato verdadeiro para responder a uma pergunta que ele não cobre.

Um OID pode existir e ainda não haver dois endpoints compatíveis. Dois endpoints podem interoperar num hackathon sem que sua cadeia corporativa de certificados esteja preparada. Um produto pode conter código e mantê-lo desativado. Uma organização pode ativá-lo apenas para parceiros específicos. E uma implantação funcional pode ainda carecer de condições de rollback aceitáveis.

O registro IANA é infraestrutura de identidade, não certificado de implantação

A presença dos identificadores no registro SMI da IANA é relevante porque estabelece um ponto de coordenação para identidade algorítmica. Os identificadores 55–65 já aparecem no registro SMI Security for PKIX Algorithms, e as entradas exibidas pela IANA remetem a uma revisão anterior, draft-ietf-lamps-pq-composite-kem-10.

O draft -21, entretanto, continua carregando ações IANA. Seu texto afirma que os OIDs de algoritmos já foram registrados, ao mesmo tempo que ainda solicita registro para o identificador do módulo ASN.1, marcado com placeholder. Isso é consistente com uma transição em que algumas peças do namespace já existem e outras ações necessárias para fechar a publicação permanecem abertas.

O ponto econômico-operacional é que registro reduz ambiguidade de coordenação; não elimina custo de integração.

OID define como identificar determinada construção. Não prova que uma biblioteca consiga gerá-la, que outra consiga decodificá-la, que o certificado esteja emitido na forma esperada, que a política corporativa aceite a combinação, que o KEMRecipientInfo seja processado corretamente ou que o fallback seja seguro.

Por isso, “está na IANA” é uma afirmação sobre controle de identidade, não sobre alcance de implantação.

Código interoperável é sinal; prontidão produtiva exige outra evidência

O anúncio da aprovação relata que muito código foi escrito e que trabalho de hackathon foi dedicado à interoperabilidade de diferentes implementações. Isso é evidência útil. Mostra que o documento não foi analisado apenas como construção abstrata e que houve esforço concreto de implementação.

Mas a extensão da conclusão precisa acompanhar a extensão da evidência.

Trabalho em hackathon não demonstra automaticamente todas as combinações algorítmicas, todas as implementações, todos os formatos de certificado, todas as cadeias de confiança, todos os caminhos CMS nem todos os ambientes produtivos. Da mesma forma, um vetor de teste aprovado demonstra o comportamento coberto por aquele vetor; não transforma duas stacks desconhecidas em pares interoperáveis.

A unidade operacional correta é o par de endpoints, naquelas versões, usando aquela combinação, aquela cadeia de certificado e aquele caminho de processamento.

Esse detalhe muda a economia da adoção. O custo deixa de ser apenas “adicionar Composite ML-KEM à biblioteca”. Passa a incluir coordenação de versão, emissão de certificados, negociação ou anúncio de capacidades, tratamento de mensagens, testes cruzados, observabilidade e política de recuperação. Quanto mais bilateral for a dependência, menos informativa será uma declaração unilateral de suporte.

Um companion-dependency receipt para transformar estado documental em controle operacional

Uma forma de reduzir a diferença entre “o padrão avançou” e “esta implantação é reproduzível” seria produzir, para cada decisão relevante, um companion-dependency receipt.

Esse recibo não precisaria ser um novo protocolo. Poderia ser um artefato assinado, versionado ou armazenado no sistema de change management. Sua função seria unir em um único registro as condições que hoje podem estar dispersas entre Datatracker, RFC Editor, IANA, código, certificados e relatórios de interoperabilidade.

Um recibo verificável deveria registrar pelo menos:

  1. Identidade dos documentos: nome exato, revisão exata e hash criptográfico dos bytes utilizados de ambos os drafts.
  2. Estado institucional: estado IESG, RFC Editor e IANA de cada documento, acompanhado de data e horário da consulta.
  3. Referência normativa: revisão exata da dependência usada pelo companion e todos os placeholders editoriais ainda presentes.
  4. Procedência de algoritmo e OID: especificação de origem para cada combinação e OID efetivamente usado.
  5. Estado de revisão do IESG: DISCUSS pendentes ou encerrados, revisão em que foram tratados e evidência da mudança de estado.
  6. Identidade final de publicação: números RFC quando publicados e alocações IANA finais, sem presumir que os valores preliminares encerram o processo.
  7. Matriz de suporte: combinações Composite ML-KEM que cada implementação realmente suporta, sem converter suporte parcial em alegação genérica.
  8. Processamento CMS: implementação e teste do caminho KEMRecipientInfo, incluindo KDF, algoritmo de key wrapping e demais parâmetros aplicáveis.
  9. Certificados: formato e OID presentes nos certificados usados no teste ou na produção.
  10. SMIMECapabilities: o que cada endpoint anuncia e como o peer interpreta essa declaração.
  11. Endpoints: fornecedor, produto, versão, build e configuração de ambos os lados.
  12. Interoperabilidade: identidade dos vetores ou casos utilizados, resultado obtido e limite explícito do que o teste cobriu.
  13. Política produtiva: onde a combinação está autorizada, quando o fallback é permitido e como ele é auditado.
  14. Rollback: condição de acionamento, configuração de retorno e dependências necessárias para desfazer a ativação.
  15. Condição de saída: eventos que tornam o receipt obsoleto — nova revisão, novo RFC, mudança de OID, atualização de biblioteca, troca de certificado ou alteração de política.

O valor desse mecanismo seria impedir que a organização retenha apenas o resultado — “teste passou” — e perca o conjunto de versões e premissas que tornou aquele resultado verdadeiro.

O ponto de controle é a fronteira entre dois sistemas

O Composite ML-KEM em CMS é especialmente sensível a esse problema porque o sucesso não é unilateral.

O originador precisa processar corretamente a chave pública do destinatário, executar a operação de encapsulação compatível, formar a estrutura KEMRecipientInfo e aplicar as convenções CMS correspondentes. O destinatário precisa possuir a chave privada adequada, reconhecer a identidade algorítmica e executar decapsulação e processamento CMS compatíveis. O RFC 9629 já estabelece essa assimetria operacional básica: o originador precisa da função de encapsulação; o destinatário precisa de geração de chave e decapsulação.

No caso Composite ML-KEM, acrescenta-se a dependência sobre como as chaves compostas e seus OIDs são representados. A declaração SMIMECapabilities pode informar capacidade, mas uma declaração de capacidade continua sendo metadado de coordenação. Ela não substitui a verificação da combinação efetivamente executada.

Por isso, o ponto de decisão deveria ser bilateral: “endpoint A e endpoint B, nessas versões e configurações, completaram o caminho exigido”. Uma declaração como “produto A suporta Composite ML-KEM” é operacionalmente mais fraca.

Consenso de padrão não equivale a demanda universal

O anúncio do IESG registra que houve debate sobre o número de combinações e que, ao final, existiam interessados nas combinações especificadas, com consenso no grupo de trabalho.

Isso sustenta a decisão de especificação; não mede demanda econômica universal.

Não há, nesses registros, base para concluir que todas as organizações pretendem habilitar todas as combinações, que todos os fornecedores as entregarão no mesmo cronograma ou que uma combinação presente na especificação será igualmente relevante em todos os segmentos.

Essa distinção importa para planejamento. Um catálogo normativo pode ser mais amplo que a matriz operacional de qualquer implantação individual. A governança interna deve, portanto, registrar exatamente quais combinações são necessárias e suportadas, em vez de transformar o conjunto permitido pela especificação em requisito automático de produção.

A incerteza está concentrada nas transições

O quadro atual não indica falha do processo. Indica que o processo ainda possui transições abertas.

O companion CMS passou pela aprovação do IESG, mas aguarda referência. A referência normativa continua necessitando revisão. Há ações IANA pendentes. Há placeholders editoriais que só podem ser resolvidos no contexto de alocações e publicação. E, além da cadeia documental, existe uma camada de implementação cuja evidência pública é necessariamente mais limitada que a diversidade de ambientes que pode surgir em produção.

A análise, portanto, deve evitar dois extremos.

O primeiro é tratar a aprovação como irrelevante porque ainda não há RFC. Isso perderia um marco institucional concreto.

O segundo é tratá-la como conclusão da transição operacional. Isso comprimiria etapas que os próprios sistemas do IETF, RFC Editor e IANA ainda apresentam separadamente.

O estado mais preciso é intermediário: a camada CMS recebeu aprovação formal, enquanto a cadeia normativa e operacional da qual sua utilização depende ainda não alcançou um estado final único.

Fontes