Resumo

  • Na RFC 3075, SignatureValue autenticava SignedInfo canonizado; os Reference dentro dele comprometiam os resumos de objetos produzidos depois de transformações ordenadas.
  • Validação bem-sucedida não abrangia automaticamente a árvore XML inteira, a tela mostrada, a autoridade de KeyInfo, cada item de Manifest ou a decisão tomada pelo aplicativo.

Publicada em março de 2001 pelo grupo XMLDSIG, a RFC 3075 não limitou a assinatura a arquivos XML. Ela podia apontar para qualquer dado digital, manter o objeto dentro da assinatura, inserir a assinatura no objeto ou usar uma referência destacada. A flexibilidade respondia à Web distribuída, mas retirava do termo “documento assinado” qualquer sentido automático.

O núcleo emitia dois recibos

A validação de referência obtinha o objeto de cada Reference, produzia a entrada indicada, calculava o resumo e comparava com DigestValue. A validação criptográfica canonizava SignedInfo e conferia SignatureValue com o método e a chave selecionados.

Uma assinatura correta sobre SignedInfo não corrigia um resumo errado. Resumos coincidentes não autenticavam sozinhos a lista e seus métodos. Com ambos aprovados, havia evidência de que uma chave se ligava àqueles compromissos específicos. Não havia licença para incluir nós próximos, recursos carregados por outra camada ou consequências comerciais posteriores.

Uma investigação precisa, portanto, do SignedInfo canônico que entrou no algoritmo e dos bytes exatos que chegaram a cada função de resumo. O retorno booleano da biblioteca é a conclusão dessa cadeia, não sua reprodução.

A transformação criava o objeto assinado

XPath podia selecionar parte da árvore. XSLT podia construir outra representação. Base64 podia recuperar um binário. A canonização podia serializar um conjunto de nós. O resumo ficava na saída dessa ordem, e aquilo que a cadeia descartava podia mudar sem invalidar a assinatura.

Isso era útil. Formulários precisavam de campos editáveis; uma assinatura envolvida precisava retirar a si mesma do cálculo; um pacote podia proteger o conteúdo binário e não suas tags. O problema surgia quando a interface tratava a seleção como cobertura total. Valor, destinatário ou instrução excluídos poderiam ser alterados enquanto o objeto escolhido continuava intacto.

A RFC ainda separou declaração de execução. O núcleo não precisava provar que o verificador acabara de buscar o URI e executar cada passo. Uma política podia aceitar cópia já transformada em cache; outra podia exigir nova busca. O mesmo resumo não informava sozinho a origem nem a atualidade dos bytes.

Canonização preservava a comparação, não a semântica

Processadores XML normalizam quebras de linha e atributos, expandem entidades e distribuem namespaces. DOM e SAX deixam para trás detalhes da escrita original. A canonização permitia reconstruir uma sequência estável, para que assinatura e verificação calculassem sobre a mesma representação.

Ela não validava um schema, não assegurava a mesma tela, não concedia autoridade a um namespace e não declarava irrelevante um nó removido. O Canonical XML 1.1 posterior manteve a ressalva: equivalências próprias do aplicativo não cabem numa forma canônica geral.

A experiência apresentada precisava encontrar os bytes protegidos

Se a assinatura pretendia registrar julgamento ou consentimento, a seção de segurança recomendava proteger tão exatamente quanto possível o que havia sido apresentado. Assinar uma imagem da tela era possível, porém pouco manipulável. Outra opção era assinar dados junto com filtros, folhas de estilo, perfil do cliente e demais entradas que moldavam o resultado.

Quem confiava na assinatura deveria operar sobre a forma transformada e assinada. Usar o original ou um estado intermediário criava outra mensagem. Uma folha de estilo externa não referenciada poderia mudar a apresentação sem romper a assinatura dos dados.

Nada disso atribuía automaticamente a chave a uma pessoa nem produzia efeito jurídico. A especificação ligava chave e octetos referenciados; identidade institucional, significado, renderização e autorização pertenciam ao aplicativo.

KeyInfo ajudava a localizar a chave

O elemento opcional KeyInfo podia carregar chave pública, certificado, nome ou método de recuperação. Também podia ser omitido quando o contexto já fornecia a chave. Por padrão, ficava fora de SignedInfo; um Reference podia incluí-lo quando fosse necessário vincular seu conteúdo.

Mesmo vinculado, ele não encerrava a confiança. Um certificado autêntico podia não autorizar a operação. Um nome de chave podia ser apenas índice interno. A RFC 2807 havia deixado semânticas gerais de confiança e de afirmação fora do núcleo obrigatório.

A moldura do Manifest não verificava todos os cartões

Manifest agrupava referências para as quais o aplicativo podia escolher política de falha. Se SignedInfo apontasse ao Manifest, o núcleo conferia o resumo do elemento. A verificação dos membros internos e a reação a indisponibilidade ou divergência continuavam definidas pelo aplicativo.

Uma lista autêntica e uma coleção integralmente validada eram estados diferentes. O relatório precisava dizer quais membros foram buscados, transformados e comparados. Uma luz verde no contêiner não era recibo de cada recurso.

A prática posterior cercou a execução

Em março de 2002, a RFC 3275 substituiu a RFC 3075 depois de experiência de interoperabilidade e alterou algumas estruturas. XML Signature 1.1 e as práticas do W3C conservaram a arquitetura e explicitaram controles: autenticar SignedInfo antes de executar referências arriscadas, estabelecer a confiança da chave separadamente, limitar XPath, XSLT, RetrievalMethod, quantidade de transformações e URIs externos, e confirmar que os elementos usados pelo aplicativo estejam protegidos.

Essas recomendações não demonstram incidente ou defeito em implantação específica. Elas mostram que uma linguagem de assinatura capaz de selecionar e executar precisa de um perfil local mais estreito que sua sintaxe.

Os ensaios posteriores de Lu Heng sobre primazia do código em execução e camadas de realidade ajudam a distinguir declaração, bytes processados, resultado criptográfico, tela, confiança e efeito. Não fizeram parte da RFC. Sua utilidade aqui é reforçar a disciplina já presente no texto: uma assinatura ganha autoridade ao delimitar sua prova, não ao absorver afirmações vizinhas.

Fontes

Lu Heng não escreveu nem aprovou a RFC 3075, a RFC 3275 ou as recomendações do W3C. Seus ensaios são lentes analíticas posteriores e explicitamente declaradas.