Signature de protNFe: assinatura opcional da resposta da SEFAZ

Signature em protNFe é a assinatura digital que a administração tributária pode aplicar à resposta de processamento. Ela é diferente de NFe/Signature, que assina os dados fiscais da nota. O MOC deixa a decisão de assinar a resposta a critério da UF.

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

A assinatura do protocolo é obrigatória?

Não no schema examinado: TProtNFe declara Signature com ocorrência 0..1, depois de infProt. Se a assinatura existir, seus componentes obrigatórios continuam exigidos: SignedInfo, SignatureValue e KeyInfo, nessa ordem. Ausência do ancestral opcional é diferente de assinatura presente e incompleta.

Na resposta assinada, o alvo é infProt. O MOC PR04 prevê seu Id com o literal ID seguido do número do protocolo, e PR90 descreve a assinatura do grupo identificado por esse atributo. Não se deve substituir isso pela fórmula #NFe mais chave usada na assinatura da nota; a referência precisa resolver o identificador verdadeiro do protocolo.

Declaração XSD do contexto.

O que muda na identificação do assinante?

O certificado em protNFe/Signature/KeyInfo/X509Data/X509Certificate é o certificado da autoridade que assinou a resposta. Ele não deve ser comparado automaticamente ao CNPJ-base/CPF do emitente como se fosse a assinatura da nota. A chave pública deve verificar o SignatureValue do protocolo, e a confiança da autoridade precisa ser analisada no contexto apropriado.

O schema específico compartilhado fixa C14N, RSA-SHA1, SHA-1 e as duas transformações. Compartilhar tipos não iguala autoria ou alvo. A conexão TLS com o serviço também é outra camada de autenticidade/transporte.

XMLDSig: processamento e elementos.

Como verificar ausência, falha ou sucesso?

Cenário 1: a resposta não contém assinatura. Isso pode ser compatível com a opcionalidade; não crie uma assinatura do emitente para preencher o campo. Confira procedência, chave, ambiente e resultado individual por meios oficiais. Cenário 2: a assinatura existe, mas falha. Preserve o retorno, confira a referência a infProt, os métodos, o resumo, SignatureValue e a cadeia do certificado, sem substituir partes pela assinatura da nota.

Não se apresenta XML completo de resposta assinada: ele exigiria protocolo, certificado e resultado criptográfico originais da autoridade. Mesmo uma assinatura válida comprova a integridade/autoria do objeto referenciado dentro das condições verificadas; o código retornado ainda precisa ser interpretado. Um protocolo assinado pode comunicar um resultado que não é autorização.

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.