Resumo

  • A RFC 3741 tornou assinaturas de fragmentos XML extraídos menos dependentes das declarações de namespace de seus ancestrais, serializando principalmente prefixos visíveis em nomes de elementos e atributos.
  • Ela não elimina toda dependência de contexto: atributos xml: herdados e prefixos presentes apenas em valores ainda podem mudar a interpretação depois que o fragmento recebe outro envelope.

O envelope não deveria reescrever a assinatura do conteúdo

Imagine um protocolo que assina um pequeno elemento XML dentro de uma mensagem maior. Um gateway remove a camada externa; outro serviço coloca o mesmo elemento em um novo envelope. No Canonical XML inclusivo, declarações ancestrais de namespace e certos atributos xml: podem entrar nos bytes canônicos mesmo que o fragmento não os utilize. Assim, mudar apenas o envelope pode alterar a entrada do resumo e invalidar a assinatura de um trecho que permaneceu intacto.

Publicada em março de 2004, a RFC 3741 tratou dessa fricção específica. Ela define uma serialização exclusiva de um conjunto de nós XPath. Em vez de importar a maior parte do contexto de namespace dos ancestrais, emite uma vinculação quando o prefixo aparece visivelmente no nome de um elemento ou atributo. O parâmetro opcional InclusiveNamespaces PrefixList permite indicar prefixos que devem ser tratados de modo inclusivo apesar dessa regra. A ideia é permitir que um subdocumento assinado seja extraído e inserido em outro envelope sem que cada camada de transporte passe a integrar sua forma canônica.

Essa é uma escolha de fronteira, não uma promessa de significado independente de contexto. A própria RFC descreve suas limitações. A RFC 3075 pergunta o que a XML Signature efetivamente cobre; a RFC 3076 descreve a canonicalização de um conjunto de nós depois do processamento do XML. A RFC 3741 trata de qual contexto deve permanecer quando o subconjunto escolhido é movido.

“Visível” é um critério útil, mas estreito

A regra usa nomes XML. Se um elemento ou atributo emprega o prefixo n1, sua vinculação precisa aparecer na serialização daquele nome. Já um prefixo declarado por um ancestral, mas ausente desses nomes, pode ser omitido. Isso costuma remover ruído: uma envoltória SOAP ou do protocolo pode conter declarações úteis para a mensagem externa, mas irrelevantes para o trecho extraído. A canonicalização exclusiva pode então produzir os mesmos bytes canônicos para o conteúdo em envelopes diferentes.

O significado que a aplicação atribui ao XML, porém, pode depender de informação invisível nos nomes do conjunto de nós. Um valor de atributo pode conter uma expressão XPath cujos prefixos importam. A aplicação também pode tratar uma cadeia como xsi:type="xsd:decimal" como um QName, embora o XPath a veja apenas como texto. Se nenhum nome usar xsd de forma visível e a lista inclusiva não o mencionar, sua vinculação poderá ser omitida. No novo envelope, o destinatário talvez interprete o valor de outra maneira.

A RFC indica três formas de controlar essa dependência: tornar visível o uso do prefixo na estrutura XML, garantir a mesma vinculação em cada contexto de interpretação ou acrescentar o prefixo a InclusiveNamespaces PrefixList. Cada opção depende de uma decisão de projeto. A lista não detecta automaticamente semânticas escondidas; o projetista precisa saber quais valores carregam significado sensível a namespaces.

O contexto fora dos bytes ainda pode orientar a leitura

A canonicalização exclusiva também não copia valores ancestrais xml:lang, xml:space ou xml:base para nós órfãos do subconjunto. Esses atributos podem afetar idioma, tratamento de espaços ou resolução de referências relativas. A RFC exige que a aplicação coloque o valor necessário em um nó do próprio subconjunto ou assegure um valor equivalente em cada contexto de interpretação.

O alerta sobre o contexto de destino é ainda mais direto. Os octetos canônicos de um fragmento podem continuar iguais ao movê-lo para baixo de um novo namespace padrão. Mesmo assim, a aplicação receptora pode associar o elemento sem prefixo a outro namespace e tratá-lo como outro tipo de objeto. A assinatura continua válida porque os octetos selecionados não mudaram; a interpretação pode mudar porque o destino oferece outro contexto.

A RFC 3741 não define como extrair, inserir ou corrigir declarações de namespace, nem decide se a aplicação receptora tem autorização para fazê-lo. O protocolo precisa estabelecer qual contexto acompanha o fragmento e o que o consumidor deve fazer com o nó recebido. A integridade criptográfica é só uma parte dessa cadeia.

Uma fronteira de assinatura menor amplia o trabalho de integração

A canonicalização exclusiva troca a dependência acidental do envelope pela obrigação explícita de inventariar dependências semânticas. Ao revisar um fragmento assinado que será encaminhado, não basta perguntar se a assinatura verifica. Também é preciso saber se prefixos, atributos xml:, valores QName e referências relativas preservam o mesmo significado no destino. Sem uma regra explícita, estabilidade da assinatura pode parecer estabilidade semântica.

Esse é o modelo de risco descrito pela especificação, não a evidência de uma exploração ou falha de implementação específica. A RFC 3741 é Informational: comprova o objetivo e as limitações do algoritmo, mas não a frequência de implantação nem um erro de serviço identificado. A lição é precisa: retirar contexto dos bytes assinados pode melhorar a portabilidade, mas só a aplicação sabe qual contexto omitido ainda governa a interpretação.

Fontes