Questões em aberto

O Label 309 v1 está congelado. O formato de transmissão sob o rótulo de metadados 309, a codificação canônica em CBOR, os catálogos de algoritmos, o envelope de prova de existência selada e a construção das assinaturas estão consolidados: um verificador v1 conforme lê todo registro v1, e um produtor v1 conforme emite registros que todo verificador v1 aceita. Esta página não trata de mudar isso. Ela é o registro do que já está confirmado no padrão hoje e do que permanece voltado ao futuro — construções criptográficas candidatas, reservadas para uma possível revisão futura, e o procedimento disciplinado para alterar uma constante criptográfica quando uma delas se concretizar.

Nada aqui é um roteiro de produto. Cada item é uma decisão técnica no nível do protocolo: um identificador de algoritmo, uma derivação, uma política de verificador ou uma regra de versionamento. Quem implementa o padrão precisa da metade consolidada para construir uma implementação v1 hoje, e da metade voltada ao futuro para construí-la de modo que um sucessor pós-quântico ou restrito a RFCs seja apenas uma nova entrada de catálogo, e nunca uma reescrita.

Construções consolidadas

Estas já estão decididas. Aparecem aqui de forma direta porque são as escolhas estruturais que quem implementa mais costuma querer confirmar em um único lugar; as páginas referenciadas trazem a construção completa.

O KEM pós-quântico já vem no v1

O KEM híbrido X-Wing (ML-KEM-768 combinado com X25519) está registrado sob o identificador mlkem768x25519 no catálogo enc.kem desde a primeira versão. Não é um candidato para o futuro: ele vive em enc.scheme: 1 ao lado do KEM clássico x25519, e o campo enc.kem, transmitido junto ao registro, seleciona o KEM de cada slot, o formato do slot e a derivação da chave de criptografia de chave por registro.

O X-Wing é consumido como uma caixa preta: a construção usa apenas sua interface pública — encapsular, desencapsular e o segredo compartilhado de 32 bytes — e não faz suposição alguma sobre o hashing interno do combinador. Ambos os KEMs derivam a KEK por slot sob uma única forma de salt de hash rotulado, SHA-256(label || enc.nonce || <material de KEM do slot> || pub_R), calculada sobre os próprios bytes de transmissão do slot: no caminho híbrido, SHA-256("cardano-poe-xwing-kek-salt-v1" || enc.nonce || kem_ct || pub_R). Reduzir por hash a 32 bytes fixos vincula o nonce do envelope, o texto cifrado e a chave pública do destinatário à KEK, ao mesmo tempo que elimina a ambiguidade de análise que um texto cifrado pós-quântico de comprimento variável criaria sob um salt de concatenação simples. Apenas a variante híbrida é exposta — o ML-KEM puro é deliberadamente omitido, para que a perna X25519 preserve a segurança clássica caso o ML-KEM-768 algum dia seja quebrado. Veja Prova de existência selada e Catálogos de algoritmos.

O compromisso da chave selada vincula o cabeçalho e a alegação de hash

Ambos os caminhos selados comprometem a chave de criptografia de conteúdo a uma transcrição fechada, serializada com a mesma função de CBOR canônico que o restante do envelope usa, que fixa os campos do cabeçalho e a alegação de hash do texto claro do item (hashes_hash). No caminho endereçado ao destinatário (enc.slots), o compromisso fica on-chain: slots_mac é um HMAC firmado com a chave CEK sobre uma transcrição que carrega os identificadores de scheme, path, AEAD e KEM, o nonce, o conjunto de slots embaralhado e hashes_hash — de modo que um relay não consegue colar um texto cifrado em um conjunto de slots diferente ou em uma alegação de hash diferente sem que a verificação do MAC on-chain falhe, antes de qualquer busca de texto cifrado. O caminho da frase secreta (enc.passphrase) carrega um compromisso equivalente em um cabeçalho de 32 bytes dentro do blob de texto cifrado, sobre uma transcrição que acrescenta o salt e os parâmetros do Argon2id — de modo que adulterar as entradas do KDF faz a verificação do compromisso falhar. O conteúdo em si é então selado em um STREAM segmentado sob uma chave de conteúdo derivada da CEK; o AAD por bloco é vazio, porque todo campo do cabeçalho já está vinculado a essa chave de forma transitiva. Construção completa em Prova de existência selada.

A profundidade de confirmação é política do verificador

Um registro fica ancorado no instante em que sua transação é incluída, mas um verificador que decide quanto assentamento exigir antes de emitir um veredito aplica um limiar de profundidade de confirmação. O Label 309 trata isso como política do verificador, e não como um MUST normativo. O padrão define a superfície legível por máquina — uma transação abaixo do limiar é reportada como pending (o código tipado INSUFFICIENT_CONFIRMATIONS), nunca failed, e pode resolver para valid em uma nova tentativa — enquanto o próprio limiar (RECOMENDADO ≥ 15 blocos) é uma entrada definida na implantação, não uma constante gravada no formato de transmissão. Um verificador que exija assentamento mais profundo para alegações de alto valor é plenamente conforme. Veja Verificação.

A verificação de Ed25519 é estrita

As assinaturas no nível do registro MUST ser verificadas sob as regras estritas da RFC 8032 §5.1.7, e não sob a tolerância mais permissiva da verificação em lote do ZIP-215. A verificação estrita rejeita codificações não canônicas e pontos de ordem pequena que um verificador tolerante aceitaria, de modo que dois verificadores conformes sempre chegam ao mesmo veredito sobre a mesma assinatura. Quem implementa precisa confirmar que seu backend de Ed25519 está em modo estrito; algumas bibliotecas adotam a variante tolerante por padrão. Veja Assinaturas.

O CBOR canônico é o contrato de determinismo

Todo registro é codificado como CBOR canônico conforme a RFC 8949 §4.2.1: formas inteiras preferenciais, arrays e mapas de comprimento definido, chaves de mapa ordenadas byte a byte, sem chaves duplicadas, sem tags. É o determinismo que permite que uma assinatura calculada sobre o corpo por uma implementação seja verificada por outra, e que dois produtores do mesmo registro lógico emitam bytes idênticos. Isso não é negociável em nenhuma implementação conforme e é a base do contrato de paridade entre linguagens.

Candidatos voltados ao futuro

Os itens abaixo são candidatos, não construções já lançadas. Nenhum deles é um defeito do v1; nenhum está comprometido. Estão registrados para que uma implementação feita hoje deixe espaço para acomodá-los como novas entradas de catálogo, e para que um revisor futuro veja quais evoluções o desenho ágil quanto a algoritmos já antecipa.

Um perfil alternativo de AEAD de conteúdo reservado

A camada de conteúdo da prova de existência selada no v1 é o chacha20-poly1305-stream64k — ChaCha20-Poly1305 da RFC 8439 no layout STREAM segmentado —, que já é respaldado por RFC, de modo que não há questão em aberto sobre o status formal da cifra de conteúdo atual. O que permanece reservado é um caminho para um AEAD de conteúdo diferente, caso algum contexto de implantação venha a exigir um. O identificador aes-256-gcm (NIST SP 800-38D) está reservado no registro AEAD para esse fim e não faz parte do enc.scheme: 1: um registro que o nomeie segue hoje a regra do envelope desconhecido.

Introduzi-lo seria uma construção futura enc.scheme: 2 que preserva os modelos existentes de slots[] + slots_mac e de compromisso de frase secreta, mas troca a camada de conteúdo, fixando o novo tamanho de bloco, a derivação da chave de conteúdo, a construção do nonce por bloco, o AAD por bloco e a autenticação do bloco final para essa cifra. É um perfil de contingência, não um substituto: registros enc.scheme: 1 existentes continuam válidos, e o perfil não deve ser implementado antes que exista uma definição normativa de enc.scheme: 2 e seus vetores de teste.

Algoritmos de assinatura pós-quânticos reservados

A metade da trajetória pós-quântica relativa ao KEM já vem no v1 (acima). A metade das assinaturas está reservada, mas ainda não implementada. Duas famílias são candidatas a entrar no catálogo de assinaturas existente assim que o IETF COSE estabilizar os identificadores de algoritmos pós-quânticos:

Como o algoritmo de assinatura é um identificador nomeado no cabeçalho protegido do COSE, registrar um sucessor é puramente aditivo: os registros Ed25519 existentes continuam sendo verificados, e um verificador que não reconheça um novo algoritmo de assinatura emite um sinal de algoritmo não suportado em vez de rejeitar a alegação de conteúdo. Uma assinatura não reconhecida nunca invalida a prova de existência subjacente. Veja Assinaturas.

Um possível caminho de publicação v: 2

Adições isoladas — um novo KEM, um novo AEAD de conteúdo, um novo algoritmo de assinatura — são entradas de catálogo que não alteram o esquema de registro de nível superior. Uma adição de KEM, em particular, é uma entrada de catálogo sob enc.scheme: 1, não um incremento de scheme; um incremento de enc.scheme fica reservado para uma mudança de construção que abrange vários KEMs (um novo slots_mac ou AEAD de conteúdo que se aplique a todos os KEMs de uma só vez).

Se candidatos que alteram o esquema do registro se acumularem em número suficiente, a mudança somada pode justificar um registro de nível superior v: 2 publicado ao lado do v1. As duas versões permaneceriam como esquemas de metadados válidos sob o rótulo 309; um verificador seleciona pelo discriminador v dentro do registro. As etapas do caminho até a padronização se repetem para a nova revisão. Esta é a evolução de maior abrangência e só é acionada por acumulação — nada aqui está agendado.

Resolução opcional de supersedência de um salto

O campo opcional supersedes de um registro aponta para um registro anterior pelo hash da transação. Resolver esse ponteiro é opcional para um verificador. Um verificador que confirma que supersedes é estruturalmente um hash de 32 bytes, mas não busca a transação anterior, é conforme, embora perca a chance de revelar a cadeia de supersedência. Orientação: um verificador MAY resolver um salto — consultar de novo o resolvedor de transações pelo hash referenciado e relatar sua existência e o horário do bloco — sem recursão adicional. Um salto é suficiente; o percurso mais profundo é responsabilidade de quem chama, e a supersedência nunca revoga o registro anterior, que a cadeia mantém verificável de forma independente para sempre.

Migrar uma constante criptográfica

Toda construção consolidada acima depende de constantes nomeadas: identificadores de algoritmo, strings de info do HKDF, salts de KDF, comprimentos de nonce de AEAD e rótulos de separação de domínio. Mudar o significado de qualquer uma delas é uma ruptura no formato de transmissão, e o padrão prescreve exatamente um caminho disciplinado para isso. A regra que rege tudo: use a mudança de menor abrangência que resolva o problema, e nunca altere silenciosamente o significado de uma constante existente sob o mesmo namespace.

O procedimento é aditivo e compatível com versões anteriores — os registros antigos continuam sendo verificados sob as constantes com que foram publicados — e avança por abrangência:

1. Versione o namespace, não o valor. Uma derivação alterada incrementa o sufixo -vN em cada string de separação de domínio que ela toca: strings de info do HKDF (…-v1 → …-v2), prefixos de mensagem de HMAC, salts e rótulos. Uma nova constante vive sob o novo sufixo; a constante antiga permanece válida sob o sufixo antigo. Verificadores mais antigos rejeitam registros mais novos de forma limpa no discriminador, em vez de interpretá-los de forma errada.

2. Incremente o discriminador que corresponde ao alcance da mudança. Uma mudança restrita a uma família de slots é selecionada por enc.kem; uma mudança que abrange vários KEMs na camada de conteúdo ou no compromisso do conjunto de slots é um incremento de enc.scheme; uma mudança no próprio esquema do registro é um incremento de v de nível superior. Cada discriminador restringe a ruptura à menor camada que de fato mudou.

3. Mantenha os antecessores verificáveis. Versões mais antigas de registro continuam legíveis como esquemas congelados. Um verificador seleciona a construção pelos próprios discriminadores de versão do registro, de modo que uma única implementação possa verificar o v1 e um sucessor futuro lado a lado. Nenhum registro deixa de ser verificável só porque um sucessor foi lançado.

Páginas relacionadas

• Catálogos de algoritmos — os identificadores nomeados cujos namespaces são versionados em uma migração.
• Prova de existência selada — o KEM híbrido X-Wing, o vínculo da transcrição de compromisso da chave e os discriminadores enc.scheme / enc.kem.
• Assinaturas — a verificação estrita de Ed25519 e o catálogo de assinaturas ao qual os algoritmos pós-quânticos reservados se juntariam.