CanonicalizationMethod da NF-e: como SignedInfo é canonicalizado
<CanonicalizationMethod>nfeProc › NFe › ds:Signature › ds:SignedInfo › ds:CanonicalizationMethodRevisão editorial em 15 de out. de 2026. As versões e condições das regras estão indicadas ao longo do artigo.
CanonicalizationMethod declara como transformar SignedInfo em uma representação canônica para calcular ou verificar a assinatura. Na NF-e, o schema fixa Canonical XML 1.0, sem comentários, pelo identificador oficial desse algoritmo.
Caminho desta página: /nfeProc/NFe/ds:Signature/ds:SignedInfo/ds:CanonicalizationMethod. 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.
Qual método o elemento declara?
O elemento ocorre uma vez como primeiro filho de SignedInfo. Seu atributo Algorithm é obrigatório e fixo em http://www.w3.org/TR/2001/REC-xml-c14n-20010315. O tipo fiscal não declara conteúdo filho.
O fragmento abaixo é sintético e parcial: mostra somente a declaração do método, sem gerar assinatura nem documento completo.
<CanonicalizationMethod xmlns="http://www.w3.org/2000/09/xmldsig#" Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
Esse valor identifica um procedimento; não é um endereço que precisa ser consultado para assinar cada nota.
O que a canonicalização muda e preserva?
Canonicalizar não é remover todos os espaços. O algoritmo trata aspectos de representação, como ordem de atributos e serialização, segundo o modelo de dados XML. Espaços e quebras que são nós de texto podem continuar relevantes. Prefixos e contexto de namespace também exigem atenção; trocar nomes ou indentar o documento depois da assinatura não é uma garantia de equivalência criptográfica.
O ds usado em um XPath é apenas uma associação de consulta com o namespace XMLDSig. No XML fiscal, o MOC 4.2.1.2 prescreve a declaração do namespace na própria Signature e restringe prefixos. Não renomeie elementos do original para fazer a consulta funcionar: configure o leitor corretamente.
XMLDSig: processamento e elementos.
Por que também existe C14N dentro de Transforms?
CanonicalizationMethod opera sobre SignedInfo. Já o Transform de C14N prepara os dados identificados por Reference para calcular DigestValue. Um XML pode ter método de SignedInfo correto e transformação de referência incorreta, ou o contrário.
Exemplo de diagnóstico: se o resumo da referência confere, mas SignatureValue falha após uma serialização, compare primeiro o SignedInfo preservado e seu contexto, além do certificado e método de assinatura. Não substitua o algoritmo por Exclusive C14N ou C14N 1.1 por preferência da biblioteca: são identificadores diferentes e não o valor fixado neste schema. Validação XSD confere a declaração; validação criptográfica precisa executar os métodos.
MOC: perfil de assinatura, pp. 53–56.
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; XML Signature Syntax and Processing — 1.1, Recommendation 11/04/2013; Canonical XML — 1.0, Recommendation 15/03/2001.
Referência técnica para integração
- XPath completo
/nfeProc/NFe/ds:Signature/ds:SignedInfo/ds:CanonicalizationMethod- Namespace
http://www.w3.org/2000/09/xmldsig#- Leiaute
- 4.00 · PL_010e_v1.02
- Ocorrências no XSD
- 1–1 no contexto do elemento pai
- Tipo
- inline:complexType
- Preenchimento no catálogo
- Obrigatório
A ocorrência vale dentro da estrutura XML: um campo obrigatório em um grupo opcional não torna esse grupo obrigatório. A aplicação fiscal depende da operação e da versão da regra.