SignatureMethod em protNFe: como a assinatura da SEFAZ é verificada

SignatureMethod, em /nfeProc/protNFe/ds:Signature/ds:SignedInfo/ds:SignatureMethod, identifica o método usado para assinar e verificar SignedInfo na resposta da SEFAZ. Ele não identifica o certificado e não contém SignatureValue.

O método declarado no schema

O elemento é obrigatório em SignedInfo. Seu atributo Algorithm é obrigatório e fixado pelo schema XMLDSig de PL_010f_v1.04 em http://www.w3.org/2000/09/xmldsig#rsa-sha1. A URI identifica RSA-SHA1 no perfil de assinatura, e não um endereço a consultar para validar o documento.

O método não deve ser escolhido pelo destinatário da resposta. Trocar a URI altera instruções que integram SignedInfo e não converte uma assinatura existente para outro algoritmo. O perfil geral XMLDSig conhecer outras opções não altera este valor fixo.

O que entra na verificação

Primeiro, Reference deve resolver o objeto protegido e seu DigestValue deve coincidir com o resumo calculado após as transformações. Depois, SignedInfo é canonicalizado por seu CanonicalizationMethod, e SignatureValue é verificado com a chave pública do certificado correspondente ao signatário esperado. As duas verificações precisam ser coerentes.

O certificado da conexão de transmissão e o certificado da assinatura são papéis diferentes. Estabelecer HTTPS não demonstra que o protocolo armazenado conserva uma assinatura válida. Tampouco uma chave pública qualquer que verifique o cálculo prova, sozinha, confiança na identidade da SEFAZ; a cadeia e a política de confiança também precisam ser avaliadas.

Fragmento e exemplos de falha

Fragmento sintético parcial do método, sem chave, certificado ou assinatura operacional:

<SignatureMethod xmlns="http://www.w3.org/2000/09/xmldsig#" Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

Se a referência passou e SignatureValue falhou, examine a canonicalização de SignedInfo, sua preservação e o certificado utilizado. Um digest correto não elimina falha nessa etapa. Se a assinatura matemática passou e a cadeia não é confiável, não classifique a resposta como autenticada apenas pelo cálculo.

Se uma biblioteca rejeita o método por política própria, registre essa distinção e investigue compatibilidade com o perfil fiscal; não afrouxe confiança nem edite o retorno para passar. Preserve o original.

Assinatura opcional não muda o status fiscal

A decisão de assinar a resposta é da UF, conforme PR90. A ausência de Signature sob protNFe é admitida pelo leiaute; não deve ser preenchida pelo emissor. Quando presente, sua verificação diz respeito ao retorno assinado, enquanto autorização e situação atual dependem de cStat, chave, ambiente e eventos oficiais posteriores.

Leituras relacionadas

• Algorithm — /nfeProc/protNFe/ds:Signature/ds:SignedInfo/ds:SignatureMethod/@Algorithm
• DigestValue — /nfeProc/protNFe/ds:Signature/ds:SignedInfo/ds:Reference/ds:DigestValue

Fontes oficiais

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