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

Algorithm em CanonicalizationMethod da NF-e: URI exata de C14N

@AlgorithmnfeProc › NFe › ds:Signature › ds:SignedInfo › ds:CanonicalizationMethod › @Algorithm

Revisão editorial em 15 de out. de 2026. As versões e condições das regras estão indicadas ao longo do artigo.

Algorithm em SignedInfo/CanonicalizationMethod identifica o método que canonicaliza SignedInfo. Seu tipo é anyURI, mas o schema específico restringe o valor a uma URI fixa; não é um campo de escolha livre.

Caminho desta página: /nfeProc/NFe/ds:Signature/ds:SignedInfo/ds:CanonicalizationMethod/@Algorithm. 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.

Que valor precisa ser reconhecido?

O valor é http://www.w3.org/TR/2001/REC-xml-c14n-20010315, correspondente a Canonical XML 1.0 sem comentários. A ausência do atributo não é equivalente ao valor fixado: use="required" exige a declaração.

Este fragmento parcial sintético demonstra a localização do atributo, sem uma assinatura completa:

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

Não acrescente #WithComments, não troque http por https e não use o nome curto C14N no atributo. Esses textos não são o literal fixado pelo tipo fiscal.

Declaração XSD do contexto.

Esse endereço deve ser acessado na internet?

A URI funciona como identificador do algoritmo. Uma implementação reconhece o identificador e executa o procedimento correspondente; não deve buscar uma regra remota por conta própria para verificar a nota. O endereço de uma referência externa e a URI de um algoritmo desempenham papéis diferentes.

O mesmo literal pode aparecer em Transform/@Algorithm, mas ali descreve o tratamento do alvo da referência. Neste atributo ele determina a representação de SignedInfo que alimenta a assinatura RSA-SHA1.

XMLDSig: processamento e elementos.

Como corrigir uma incompatibilidade da biblioteca?

Cenário: a biblioteca foi configurada para Exclusive C14N e emite sua URI, embora os demais elementos pareçam corretos. Compare a configuração efetiva com o perfil NF-e e teste a geração em ambiente controlado; não substitua somente o texto da URI em uma assinatura pronta. O conteúdo foi calculado com um método, e declarar outro não recalcula o resultado.

Conserve o original, o método configurado e o resultado da validação. Confira tanto DigestValue quanto SignatureValue e a confiança do certificado. A declaração aceita no XSD não comprova que o algoritmo foi executado corretamente nem que a nota foi autorizada.

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/@Algorithm
Namespace
Não informado
Leiaute
4.00 · PL_010e_v1.02
Ocorrências no XSD
1–1 no contexto do elemento pai
Tipo
anyURI
Preenchimento no catálogo
Obrigatório
Valor fixo no XSD
http://www.w3.org/TR/2001/REC-xml-c14n-20010315

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.