SignedInfo no protocolo da SEFAZ: o que a assinatura protege

SignedInfo, em /nfeProc/protNFe/ds:Signature/ds:SignedInfo, reúne os métodos e a referência usados na assinatura das informações do protocolo pela SEFAZ. A assinatura digital recai sobre sua representação canonicalizada; a referência liga esse conjunto ao conteúdo protegido. Ele não é um segundo protocolo de autorização.

Como os componentes se encadeiam

O XSD exige, nesta ordem, um CanonicalizationMethod, um SignatureMethod e um Reference. O primeiro define a normalização de SignedInfo; o segundo identifica como sua assinatura é verificada; o terceiro informa o objeto referenciado, as transformações aplicadas a ele e o resumo resultante. O atributo Id do próprio SignedInfo é opcional.

Dentro de Reference, Transforms descreve o processamento do objeto; DigestMethod identifica o algoritmo do resumo; DigestValue guarda esse resumo em base64. SignatureValue, irmão de SignedInfo, contém o resultado criptográfico da assinatura, e KeyInfo fornece o certificado. Digest e assinatura são resultados distintos.

Qual conteúdo é referenciado no protocolo?

No leiaute do retorno, PR03 identifica infProt como o grupo a assinar. PR04 relaciona seu Id ao número de protocolo, e PR90 informa que assinar a resposta é decisão da UF. Na assinatura da NF-e pelo emitente, o contexto é NFe/infNFe; transportar automaticamente sua URI para o protocolo faz a verificação olhar outro objeto.

Um verificador deve resolver a URI da referência de maneira inequívoca, aplicar as transformações e comparar o resumo. Separadamente, deve canonicalizar SignedInfo e conferir SignatureValue com a chave pública apropriada. Também deve verificar confiança e a identidade esperada do signatário. Passar em apenas uma dessas etapas não completa a verificação.

Exemplo de leitura e diagnóstico

Considere uma resposta original cuja referência aponta para infProt, mas cujo verificador usa o DigestValue da assinatura do emitente como se fosse o resumo do protocolo. O resultado pode divergir mesmo que cada estrutura esteja bem formada: os objetos comparados são diferentes. O passo correto é registrar a URI de cada assinatura, localizar o alvo exato e recalcular somente no contexto correspondente.

Não há XML completo neste exemplo: sem a resposta original, qualquer digest ou assinatura inserido seria apenas bytes sem validade operacional. A árvore estrutural a localizar é Signature → SignedInfo → CanonicalizationMethod, SignatureMethod, Reference.

Se o XSD falhar, confira ordem, filhos obrigatórios e namespace. Se a criptografia falhar, preserve o arquivo original e examine alvo, transformações e certificado. Se o retorno não tiver assinatura, não acrescente uma: a cardinalidade do protocolo admite essa ausência. Mesmo uma assinatura verificada não informa, sozinha, a situação atual da nota após eventos posteriores.

Leituras relacionadas

• Reference — /nfeProc/protNFe/ds:Signature/ds:SignedInfo/ds:Reference
• SignatureMethod — /nfeProc/protNFe/ds:Signature/ds:SignedInfo/ds:SignatureMethod

Fontes oficiais

• Schema XMLDSig NF-e/NFC-e — PL_010f_v1.04: SignatureValueType, SignedInfoType, ReferenceType, TransformsType e TTransformURI.
• Leiaute NF-e/NFC-e — PL_010f_v1.04: TProtNFe, linhas 6686–6770.
• 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.