SignatureValue de protNFe: verificação da assinatura da resposta

SignatureValue no ramo de protNFe contém em Base64 o resultado da assinatura de SignedInfo do protocolo. Ele pertence à resposta assinada pela autoridade e não é o valor da assinatura da nota feita pelo emitente.

Caminho desta página: /nfeProc/protNFe/ds:Signature/ds:SignatureValue. 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.

Quando esse valor é exigido e o que ele protege?

A Signature de protNFe é opcional. Quando a autoridade a inclui, o tipo exige um SignatureValue entre SignedInfo e KeyInfo; seu conteúdo deriva de base64Binary e admite Id opcional.

O objeto fiscal da referência é infProt, identificado conforme a resposta assinada. Seu digest integra SignedInfo; a assinatura RSA-SHA1 atua sobre o SignedInfo canonicalizado e produz este valor. O certificado da mesma assinatura fornece a chave pública para a verificação. Não se usa automaticamente a chave do emitente.

Declaração XSD do contexto.

Por que ele não é digVal, nProt ou autorização?

infProt/digVal registra o digest da NF-e processada para conferência de integridade do original. SignedInfo/Reference/DigestValue dessa assinatura resume o objeto do protocolo referenciado. SignatureValue é o resultado criptográfico sobre SignedInfo. infProt/nProt é o número do protocolo. Os quatro têm caminhos e funções diferentes.

Uma assinatura de resposta pode autenticar um resultado de processamento sem que esse resultado seja autorização. A interpretação depende de cStat, xMotivo, chave, ambiente e condições da resposta real; a situação atual pode depender de eventos posteriores.

XMLDSig: processamento e elementos.

Como investigar um valor que não confere?

Cenário: o sistema copiou SignatureValue da NFe para preencher o ramo do protocolo. Isso não cria uma assinatura da SEFAZ: o objeto, a chave e o SignedInfo são outros. Preserve a resposta original e confira se a autoridade de fato incluiu assinatura; a ausência opcional não deve ser preenchida pelo destinatário.

Se a assinatura original existe, valide a referência ao infProt correto, os métodos e o digest, depois SignatureValue com o certificado da autoridade. Separe falha matemática de falha de confiança. Não há XML completo com assinatura da SEFAZ inventada; esse valor só pode vir da operação criptográfica correspondente. Não troque bytes ou certificado no documento recebido para forçar sucesso.

MOC: resposta e protocolo, pp. 76–77.

Fontes e contexto

Schema específico XMLDSig da NF-e — PL_010f_v1.04 / xmldsig-core-schema_v1.01.xsd; Leiaute da NF-e e protocolo — PL_010f_v1.04 / leiauteNFe_v4.00.xsd; MOC — Visão Geral — 7.0; XML Signature Syntax and Processing — 1.1, Recommendation 11/04/2013.