Transform na assinatura do protocolo: cada etapa antes do digest

Transform representa uma etapa da cadeia aplicada ao objeto de Reference antes de calcular seu resumo na assinatura da SEFAZ. O caminho é /nfeProc/protNFe/ds:Signature/ds:SignedInfo/ds:Reference/ds:Transforms/ds:Transform. No grupo pai Transforms, o XSD fiscal exige exatamente duas ocorrências.

Algorithm identifica a etapa

Cada Transform tem Algorithm obrigatório, do tipo TTransformURI. Em PL_010f_v1.04, esse tipo admite a transformação enveloped-signature e a canonicalização C14N 1.0, identificadas pelas URIs oficiais. O pai impõe algoritmos únicos; duas ocorrências da mesma transformação não formam uma cadeia válida nesse perfil.

O conteúdo XPath é estruturalmente opcional e repetível no tipo TransformType. Isso não torna o algoritmo de filtro XPath permitido: sua URI não está na enumeração TTransformURI. Aceitação lexical de um filho não cria um algoritmo operacional novo.

Como interpretar uma ocorrência

Este fragmento sintético representa só uma etapa, parcial em relação à cadeia de duas e sem validade operacional de assinatura:

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

A URI informa canonicalização do objeto de Reference. Ela não deve ser confundida com o CanonicalizationMethod de SignedInfo, embora o identificador possa coincidir. As entradas são diferentes. Uma etapa isolada não substitui o grupo completo Transforms.

A ordem precisa ser preservada

XMLDSig processa a lista na sequência declarada. O XSD limita quantidade e valores, mas não declara cada posição como um algoritmo diferente. Assim, um teste estrutural isolado não é prova de ordem semântica correta ou de digest coincidente. Leia e execute a cadeia do original; não a ordene alfabeticamente nem por preferência da biblioteca.

Como cenário de diagnóstico, um mapper converte os filhos em um mapa indexado por nome Transform e mantém apenas um deles. O original tinha dois e o armazenado passou a ter um. A falha é perda de ocorrência no armazenamento, não motivo para editar o protocolo da SEFAZ. Preserve a lista e sua ordem na integração.

O que conferir diante de uma falha

Separe quantidade incorreta, método não reconhecido, algoritmo repetido e digest diferente. Valide o contexto de namespace e confira os atributos exatos no arquivo original. Para divergência criptográfica, confirme também a URI do alvo e o DigestMethod. Se o protocolo já veio assinado, recupere o original ou corrija o processamento do leitor; não reescreva a etapa. O resultado da verificação ainda depende de SignatureValue e confiança no signatário.

Leituras relacionadas

• Transforms — /nfeProc/protNFe/ds:Signature/ds:SignedInfo/ds:Reference/ds:Transforms
• XPath — /nfeProc/protNFe/ds:Signature/ds:SignedInfo/ds:Reference/ds:Transforms/ds:Transform/ds:XPath

Fontes oficiais

• Schema XMLDSig NF-e/NFC-e — PL_010f_v1.04: SignatureValueType, SignedInfoType, ReferenceType, TransformsType e TTransformURI.
• XML Signature Syntax and Processing — 1.1: seções 3.2, 4.3, 4.4 e 6: processamento, referências, IDs e algoritmos.
• NT 2025.002 RTC — 1.52: seção 5.1, p. 11; PR03–PR90, p. 13.