Transforms da NF-e: as duas etapas anteriores ao digest

Transforms contém a sequência de tratamentos aplicada ao objeto identificado por Reference antes do cálculo de DigestValue. No schema da NF-e, o grupo é obrigatório e contém exatamente dois elementos Transform.

Caminho desta página: /nfeProc/NFe/ds:Signature/ds:SignedInfo/ds:Reference/ds:Transforms. O alias ds neste XPath representa o namespace http://www.w3.org/2000/09/xmldsig#; ele permite localizar o elemento, mas não exige esse prefixo na serialização fiscal.

Quais transformações compõem o grupo?

O tipo aceita apenas os algoritmos enveloped-signature e Canonical XML 1.0. Uma restrição de unicidade impede repetir o mesmo Algorithm no grupo. Como há dois elementos e dois valores possíveis distintos, ambos precisam estar representados.

Este fragmento parcial sintético segue a ordem apresentada no exemplo do MOC, sem constituir assinatura completa:

<Transforms xmlns="http://www.w3.org/2000/09/xmldsig#">
  <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
  <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
</Transforms>

O XSD verifica quantidade, literais e unicidade, mas não codifica por posição a ordem dos dois algoritmos. Isso não autoriza reordenar uma sequência já assinada.

Declaração XSD do contexto.

O que cada etapa faz com os dados?

A transformação enveloped-signature trata a exclusão do elemento de assinatura de seu conjunto de entrada quando aplicável, evitando que a própria assinatura integre os dados que a geram. C14N produz a representação canônica para o hash. A sequência é processada na ordem em que aparece, e o resultado alimenta DigestMethod.

Na NF-e, a URI aponta para infNFe, e Signature fica como irmã desse grupo. Ainda assim, o perfil fiscal exige as duas transformações; não remova enveloped por supor que ela é dispensável naquele recorte. A C14N desta sequência opera sobre a referência, enquanto CanonicalizationMethod opera sobre SignedInfo.

XMLDSig: processamento e elementos.

Como investigar ausência ou duplicidade?

Exemplo: dois Transform declaram C14N. A quantidade está correta, mas a restrição de unicidade e o conjunto exigido falham. Outro cenário: há apenas enveloped. Falta a segunda etapa estrutural. A regra F01/298 do MOC trata divergência do padrão, incluindo os algoritmos esperados.

Preserve o XML e confira a configuração da biblioteca, a URI e os bytes resultantes. Inserir uma transformação em SignedInfo após a assinatura modifica o que foi assinado. Faça ajustes no gerador com validação controlada, sem editar documento autorizado. Mesmo o grupo correto não prova digest, assinatura ou autorização.

MOC: validações de assinatura.

Fontes e contexto

Schema específico XMLDSig da NF-e — PL_010f_v1.04 / xmldsig-core-schema_v1.01.xsd; MOC — Visão Geral — 7.0; MOC — Anexo I, Leiaute e Regras de Validação — 7.0; XML Signature Syntax and Processing — 1.1, Recommendation 11/04/2013.