Rejeição 298: assinatura XML fora do padrão da NF-e

A rejeição 298, regra F01, aponta divergência no padrão da assinatura XML. O MOC destaca a referência ao atributo Id e as transformações C14N e Enveloped. Uma assinatura que segue outro perfil XMLDSig pode ser válida em outro sistema e ainda contrariar o subconjunto adotado pela NF-e.

Nesta página:

• Como Id e Reference URI devem se relacionar?
• Quais algoritmos e transformações precisam ser conferidos?
• Exemplo: biblioteca usa outro perfil por padrão
• Como distinguir 298, 297 e assinaturas do PAA?

Como Id e Reference URI devem se relacionar?

Na NF-e, o elemento assinado é infNFe, identificado pelo atributo Id. A Reference deve apontar para esse identificador com o marcador de referência interna. Para outras mensagens, o MOC mantém o princípio de identificar o elemento correto a assinar, conforme o leiaute próprio.

Não basta a assinatura existir no arquivo. Confira se ela referencia o elemento previsto, se esse Id existe e se é único. A ausência de Reference URI também é objeto de validação estrutural. Não crie uma chave ou um Id fictício para satisfazer a referência.

Fontes: MOC Anexo I, regra F01.

Quais algoritmos e transformações precisam ser conferidos?

A Visão Geral descreve XMLDSig Enveloped, canonicalização C14N e as duas transformações previstas: http://www.w3.org/2000/09/xmldsig#enveloped-signature e http://www.w3.org/TR/2001/REC-xml-c14n-20010315. O perfil documentado usa SignatureMethod RSA-SHA1 e DigestMethod SHA-1, com suas URIs específicas.

Esses algoritmos da assinatura XML não são o algoritmo de assinatura do certificado pela AC nem a negociação TLS. Não altere o perfil por preferência de biblioteca ou por interpretação de uma atualização de certificado. Confira o contrato fiscal e seus schemas vigentes; a correção pertence ao assinador compatível, mantendo a segurança da conexão e da cadeia.

Fontes: MOC Anexo I, regra F01.

Exemplo: biblioteca usa outro perfil por padrão

Em um cenário hipotético, uma atualização de biblioteca passa a emitir uma transformação de canonicalização diferente da prevista ou deixa a Reference apontar para a raiz do lote, em vez do elemento fiscal exigido. A presença de SignatureValue não corrige essa incompatibilidade.

Compare SignedInfo, URI de referência, elemento alvo e lista de transformações com o contrato. Configure o perfil adequado e regenere a assinatura pelo fluxo legítimo. Não edite esses campos depois de assinar, pois eles participam da verificação criptográfica.

Fontes: MOC Anexo I, regra F01.

Como distinguir 298, 297 e assinaturas do PAA?

A 298 avalia o padrão; a 297 avalia o valor calculado da assinatura. Um perfil correto ainda pode ter integridade inválida. No PAA, a NT 2026.001 prevê uma assinatura avançada em infPAA e a Signature qualificada do documento; os campos homônimos não devem ser tratados como a mesma verificação.

Valide schema e criptografia no arquivo final. Não altere XML autorizado e esclareça envios anteriores de resultado incerto antes de repetir a ação. Nenhuma assinatura sintética demonstra autorização.

Fontes: MOC Anexo I, regra F01; NT 2026.001 - Provedor de Assinatura e Autorização.

Limite do exemplo e preservação dos dados

Uma prova criptográfica depende de Id, certificado, chave e assinatura originais protegidos. O exemplo textual descreve o perfil sem fabricar chave de acesso, SignatureValue ou certificado. A conferência deve preservar o original e ocorrer em ambiente protegido; não publique certificado, senha, chave privada ou dados fiscais de clientes.

Fontes oficiais

• MOC 7.0 — Anexo I, versão 7.00. p. 74, regra F01, código 298; p. 74, regras próximas de assinatura.
• MOC 7.0 — Visão Geral, versão 7.00. pp. 52–56, §§4.2.3–4.2.6: certificado e assinatura, EndCertOnly, perfil XMLDSig, validação e LCR.
• NT 2026.001 - Provedor de Assinatura e Autorização, versão 1.02b. pp. 3–5, versão/cronograma e duas assinaturas; pp. 10–11, infPAA e F03; p. 14, ZG04-10 separado da Signature qualificada.