Resumo

  • abc, "abc", #616263#, 3:abc e |YWJj| podem representar os mesmos três octetos; apenas a forma canônica fornece a codificação única destinada à assinatura.
  • Uma dica de exibição pode entrar no objeto canônico assinado sem se tornar prova de tipo, confiança ou autorização.
  • Evidência defensável separa entrada, perfil do parser, saída canônica, assinatura, interpretação, política e resultado observado.

O visor mostra caracteres; a assinatura cobre bytes

Um terminal exibe abc, um arquivo guarda "abc", um rastreamento contém #616263#, uma mensagem transporta 3:abc e uma ferramenta imprime |YWJj|. A RFC 9804 mostra que as cinco grafias podem virar os mesmos três octetos. A imagem de uma delas, porém, não identifica os bytes que atravessaram a fronteira da assinatura.

Uma S-expression é uma cadeia de octetos ou uma lista finita. A especificação separa quatro ambientes. A representação avançada atende pessoas e depuração. O transporte básico leva a forma canônica por canais sensíveis a binário ou tamanho de linha. A representação canônica é única e serve à assinatura. A estrutura em memória é assunto da implementação.

Na forma canônica, cada cadeia recebe comprimento decimal, dois-pontos e seus bytes literais; listas não têm espaços de formatação. A expressão inteira pode viajar em Base64 entre chaves. Essa embalagem protege o transporte, não cria outro significado: a decodificação deve recuperar os bytes canônicos exatos.

A forma avançada aceita tokens, aspas, hexadecimal, Base64, comprimento e espaços. Seu suporte é opcional. A aplicação deve habilitá-la por perfil ou descoberta de capacidade. Um log que registra apenas “parse concluído” não revela versão, formas ativas, limites ou restrições aplicadas.

Dica assinada continua sendo dica

A RFC 9804 permite uma dica de exibição ligada à cadeia. Ela orienta como mostrar os dados e não tem outra função. Quando existe, entra na forma canônica e pode ser coberta pela assinatura. Isso prova a inclusão da dica, não a veracidade de um tipo, a segurança do manipulador nem o direito de executar uma ação.

Sem dica, a aplicação escolhe um padrão local; application/octet-stream é o padrão geral. Dois sistemas podem exibir os mesmos octetos de maneiras diferentes. A igualdade também depende do perfil: a recomendação compara dica e dados, mas uma aplicação pode ignorar a dica. Auditoria precisa registrar essa regra e sua versão.

A gramática é somente a primeira porta. A RFC 9804 deixa o perfil proibir formas avançadas, dicas, listas ou cadeias vazias e impor limites. No SPKI, a RFC 2693 estreita o universo: certificados não usam listas vazias e a primeira posição deve conter uma cadeia de tipo.

A trilha começa com bytes e enquadramento recebidos. Guarda versão e configuração do parser, perfil, limites e o objeto abstrato. Depois reemite bytes canônicos e calcula seu hash. A verificação vincula esse hash à chave usada; a tela jamais substitui o objeto.

Só então vem a interpretação. A RFC 2692 atribui ao autor da aplicação a definição do significado de uma autorização SPKI. A RFC 2693 descreve tuplas confiáveis e redução, mas a aplicação ainda decide. O recibo identifica manipulador, política, principal, ação, recurso e decisão. Outra observação confirma o efeito executado.

Isso forma oito etapas: receber, admitir, analisar, canonicalizar, verificar, interpretar, autorizar e observar. Se parsers divergem, compare entrada e hash canônico. Se a assinatura coincide e o resultado muda, examine o manipulador e a política. Se a política permite e nada acontece, investigue a execução. A RFC 9804 oferece acordo de bytes, não autoridade automática sobre o restante.

Fontes