Resumo

  • A RFC 9925, Proposed Standard do IETF publicada em fevereiro de 2026, define id-alg-unsigned, sem parâmetros e com valor de assinatura de zero bits.
  • O objeto transporta nome, chave e extensões do sujeito, mas nenhuma prova de um emissor. Um nome repetido no campo emissor é só um marcador de compatibilidade.
  • Consumidores que não verificam a assinatura X.509 podem aceitar o formato; validadores de caminho precisam rejeitá-lo sempre que uma assinatura for exigida.
  • Retirar uma autoassinatura decorativa pode economizar bytes pós-quânticos, evitar uso cruzado de chaves e acomodar chaves KEM incapazes de assinar.
  • Um recibo de origem e escopo deve documentar os bytes, a evidência externa, quem aprovou, qual repositório recebeu a chave, os usos permitidos e a remoção.

Um vazio que o protocolo consegue reconhecer

O identificador 1.3.6.1.5.5.7.6.36 descreve uma não assinatura. Os parâmetros ficam ausentes e signatureValue é uma BIT STRING vazia. Assim, um parser não precisa adivinhar se está diante de corrupção, algoritmo desconhecido ou prova incompleta. O estado é explícito.

Esse objeto pode ser sintaticamente útil e, ao mesmo tempo, incapaz de formar uma aresta de certificação. Se o aplicativo apenas extrai dados do sujeito dentro de um contexto protegido por outro mecanismo, ele pode aceitá-lo. Se está verificando a assinatura ou construindo um caminho, deve rejeitar.

O perigo não é a norma ter esquecido uma checagem. É a camada de produto apagar a distinção. Uma tela pode chamar o marcador de “emitido por”, um inventário pode somar o objeto aos certificados emitidos por CAs e uma equipe pode lembrar apenas que “o certificado era confiável”. A RFC oferece uma linguagem melhor: contêiner sem emissor, com confiança externa.

O nó ficou; a ligação saiu

A RFC representa PKI como grafo. Um certificado comum liga informações do sujeito à prova produzida por um emissor. Em alguns casos, porém, o sistema precisa apenas do nó: uma âncora que inicia o caminho, uma chave conhecida por impressão digital ou uma chave de encapsulamento que precisa de estrutura X.509, mas não sabe assinar.

A autoassinatura não escolhe a chave para o operador. Ela mostra, no máximo, que a chave assinou sua própria representação. Não confirma o nome, o direito de instalação ou o alcance. A RFC 5280 já trata a âncora como entrada externa: o certificado autoassinado que a representa não integra o caminho prospectivo, e a informação é confiada porque chegou por procedimento fora de banda. A seleção permanece local.

A RFC 9925 remove a ligação ornamental. Isso melhora o espelho entre o arquivo e a autoridade real, na linha do Policy Mirror de Lu Heng. Mas torna impossível evitar a pergunta: qual decisão local transformou esse nó em ponto de partida?

O emissor obrigatório pode ser apenas texto de enchimento

X.509 exige um campo emissor não vazio. Para compatibilidade, o remetente pode copiar o sujeito ou usar o marcador definido pela RFC. Nenhuma alternativa significa que houve emissão. O documento declara que o objeto não é autoassinado nem autoemitido.

Uma interface fiel precisa mostrar esse limite. Repetir sujeito e emissor numa tela sem aviso cria uma relação que não ocorreu. Desenhar uma seta circular faz o mesmo. Identificador de chave da autoridade e nome alternativo do emissor devem normalmente ser omitidos, pois não existe tal autoridade.

Já as restrições básicas e o uso de chave descrevem o papel do sujeito. Uma chave pode ser tecnicamente adequada para CA sem que esteja autorizada a ocupar qualquer repositório. Capacidade e permissão continuam separadas.

Registro não é aprovação

IANA registrou id-alg-unsigned e os demais identificadores PKIX. O registro permite reconhecer o estado e chegar à referência normativa. Não autentica o sujeito, não avalia um produto e não concede mandato a um administrador.

Nesse caso, reconhecer serve para rejeitar corretamente. Um validador não modificado deve falhar ao encontrar uma assinatura que não pode verificar. Só o consumidor que já possui contexto externo específico precisa de suporte positivo.

Se o valor entrar num caminho como se fosse assinatura, a verificação foi contornada. A RFC 8725 oferece a disciplina geral: o chamador deve definir algoritmos aceitos e a biblioteca deve garantir que o algoritmo declarado corresponda à operação executada. Reconhecer o número e concluir a verificação são resultados diferentes.

Menos assinatura pode ser mais honestidade

Autoassinaturas ignoradas consomem espaço sem fornecer a razão da confiança. Assinaturas pós-quânticas podem ser grandes. Uma chave de entidade final usada também para assinar a estrutura X.509 cruza finalidades. Uma chave KEM não consegue produzir a assinatura. A não assinatura nomeada elimina essas exigências.

O formato não é um passe livre. Em qualquer contexto que demande prova do emissor, ele é inválido. Sua vantagem está em impedir uma cerimônia sem efeito e preservar a chave para a função correta.

O melhor argumento contrário diz que o sistema local já sabe em quem confiar e que um registro adicional gera burocracia. O ponto é válido quando o escopo é pequeno e a configuração reproduzível. Mas “fora de banda” pode ser firmware assinado, impressão digital comparada, repositório protegido, provisionamento industrial ou clique manual. Cada rota tem autoridade e recuperação próprias.

Instalar é decidir

A RFC 6024 separa âncora, gestor e repositório. Ela prevê repositórios por aplicação ou população, operações de adicionar, remover e substituir, autenticação da origem, autorização do fornecedor, proteção contra repetição e recuperação.

Essa decomposição revela a camada de poder. A pessoa que importa o objeto não apenas copia bytes: torna uma chave capaz de sustentar decisões futuras. Uma impressão digital comprova identidade dos bytes, não seu escopo. Um canal seguro autentica a origem imediata, não o mandato. Privilégio administrativo executa a mudança, mas não prova sua aprovação.

Recibo de origem e escopo

O recibo começaria pelo digest exato, a chave do sujeito, o papel declarado, o estado sem assinatura e a proibição de usá-lo num passo de validação de assinatura. Em seguida registraria fonte, canal, prova externa de integridade, identidade de quem forneceu e regra que autorizou esse fornecimento.

O bloco decisório nomearia o aprovador, momento, repositório, aplicações, dispositivos, espaços de nomes, políticas, finalidades e janela temporal. O ciclo de vida incluiria substituição, remoção, revisão, responsável e recuperação.

A camada pública pode ser fina: digest, autoridade, escopo, estado, linhagem e contato de correção. Credenciais e topologia interna permanecem protegidas. O recibo não cria uma assinatura; evita que a decisão externa desapareça.

Limite da evidência

As fontes não medem adoção e não apontam produto que processe a RFC incorretamente. A carta LAMPS é escopo institucional, não telemetria. O registro IANA é identidade, não certificação.

Nem toda autoassinatura é inútil: algumas aplicações a usam contra corrupção acidental, caso em que o perfil sem assinatura precisa de hash externo. Nem todo objeto não assinado será âncora.

O fato seguro é delimitado: os dados do sujeito continuam, a prova do emissor sai, o caminho deve rejeitar e a confiança chega por outra via. Essa via merece ser tão verificável quanto o formato.

Fontes

  1. Lu Heng, “The Policy Mirror”
  2. RFC 9925, certificados X.509 sem assinatura
  3. RFC 5280, perfil de certificados e CRLs X.509
  4. RFC 4158, construção de caminhos de certificação
  5. RFC 5914, formato de âncoras de confiança
  6. RFC 6024, requisitos de gestão de âncoras
  7. RFC 8446, TLS 1.3
  8. RFC 8725, boas práticas para JSON Web Token
  9. IANA, números SMI
  10. IETF, carta do grupo LAMPS