Pular para o conteúdo
Fiscal ProBiblioteca
NF-e e NFC-e · Suplemento, assinatura e protocolo

CanonicalizationMethod da NF-e: como SignedInfo é canonicalizado

<CanonicalizationMethod>nfeProc › NFe › ds:Signature › ds:SignedInfo › ds:CanonicalizationMethod

Revisã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.

Declaração XSD do contexto.

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.