PAASignature: assinatura RSA do emitente no fluxo do PAA

PAASignature é a estrutura de assinatura RSA do emitente em infPAA, para documentos gerados por Provedor de Assinatura e Autorização. Ela contém o valor de assinatura e a chave pública correspondente; não substitui a assinatura qualificada do documento pelo PAA.

Caminho desta ocorrência: /nfeProc/NFe/infNFe/infPAA/PAASignature.

Dois filhos com funções diferentes

SignatureValue contém o resultado criptográfico em Base64. RSAKeyValue contém a chave pública do emitente, em Modulus e Exponent. A sequência do XSD exige primeiro o valor de assinatura, depois a chave pública, ambos obrigatórios no grupo.

Base64 é uma codificação de bytes: uma string que decodifica corretamente não está, por isso, assinada corretamente. A chave pública permite a verificação; a chave privada usada na geração não pertence ao XML e não deve ser divulgada. NT 2026.001 v1.02b, ZG03–07, p. 11; chaves, p. 5–6; XSD PL 010f v1.04, PAASignature.

Qual conteúdo a assinatura cobre

O fluxo documentado assina o valor do atributo Id da NF-e, convertido em bytes, usando RSA/SHA1 e codificando o resultado em Base64. O grupo não é uma assinatura inventada sobre qualquer texto nem a cópia do SignatureValue da assinatura XML qualificada.

Além da estrutura simplificada, o documento deve receber a assinatura qualificada com certificado ICP-Brasil do PAA. O PAASignature está no namespace da NF-e; não crie nele um ds:SignedInfo de XMLDSig convencional para substituir os filhos documentados. Verifique a implementação segundo a NT e o manual do provedor, mantendo o vínculo e a chave corretos. NT, p. 4–6 e 11.

Por que não há assinatura fictícia no exemplo

Não se apresenta um XML completo de PAASignature com assinatura ou chave pública fabricada. Para conferir a árvore, localize infPAA/PAASignature, leia SignatureValue e depois RSAKeyValue/Modulus e Exponent. A NT fixa AQAB para o expoente; o módulo e o valor de assinatura dependem da chave e do conteúdo legítimos.

Um exemplo de Base64 arbitrário poderia passar no XSD e ainda falhar na verificação RSA. Para testes de integração, use material autorizado do ambiente de homologação correspondente, sem reutilizar vínculo ou chave de outro emitente. O XSD confirma a estrutura, não a identidade, a validade criptográfica ou a autorização. NT, p. 5–6 e 11.

Diagnóstico 895,856 e 776 sem misturar as assinaturas

A 895 verifica se a chave pública corresponde à cadastrada para emitente/PAA na vigência pertinente. A 856 verifica a assinatura RSA usando essa chave. A 776 trata do CNPJ-base do certificado qualificado do provedor. Assim, trocar o valor Base64 não resolve vínculo/chave divergente, e trocar o certificado não explica automaticamente uma assinatura RSA inválida.

Compare o Id exato usado na geração com o do XML enviado, o material público do vínculo e a origem da assinatura, preservando o original. Verifique codificação de bytes, pareamento de chaves e ausência de cópia da assinatura de outro documento. Corrija a causa comprovada no gerador, sem editar um XML autorizado ou expor a chave privada. Essas regras são marcadas para SVRS; a NT 1.02 prevê produção 05/10/2026, mas o cronograma sozinho não prova que a emissão concreta foi autorizada. NT, p. 3 e 14.

Para separar parâmetros públicos e privados na estrutura, consulte chave pública RSAKeyValue.