Resumo

  • O RFC 5402 permite compressão dentro ou fora da assinatura, fazendo o MIC acompanhar os bytes efetivamente assinados ou, em casos não assinados, o conteúdo descomprimido definido pela regra.
  • O RFC 6362 calcula um MIC sobre o corpo multipart inteiro e invalida todos os anexos quando ele diverge, mas deixa o processamento de cada documento para a implementação.
  • Um registro confiável precisa ligar a prova da embalagem a recibos separados de extração, sintaxe, autorização e aceitação de cada item.

Integridade de grupo não é aprovação em lote

O envelope chegou inteiro. O parceiro devolveu um recibo verificável, o identificador da mensagem correspondia e o MIC bateu. Isso prova algo importante sobre o conjunto protegido. Não prova que o PDF era o desenho contratado, que o XML respeitava a regra fiscal ou que a imagem estava autorizada para uso.

O erro nasce quando a estrutura de dados tem apenas um campo de sucesso. A aplicação copia o verde do envelope para todos os filhos e chama o resultado de validação. Uma propriedade de transporte passa a parecer uma decisão semântica.

O RFC 5402 foi publicado em fevereiro de 2010 como Informational no Independent Stream. Uma nota do IESG deixa claro que ele não é candidato a Internet Standard e pede cautela na avaliação de implementação. O documento acrescenta a compressão CMS aos intercâmbios EDIINT de AS1, AS2 e AS3. Ele descreve ordem e cálculo; não atesta que um produto ou parceiro siga a regra em produção.

A posição da compressão define o primeiro recibo

Em uma mensagem assinada, o emissor pode comprimir o corpo MIME interno e depois assinar a entidade comprimida. Também pode assinar primeiro e comprimir o multipart/signed externo. Não pode usar as duas posições no mesmo documento, e o receptor precisa suportar ambas.

Na primeira forma, a assinatura cobre CMS CompressedData. Na segunda, cobre o MIME não comprimido e fica, com o conteúdo, dentro da compressão. Para mensagens assinadas, o MIC retornado é calculado sobre os mesmos dados que foram assinados. Portanto, um MIC pode nomear bytes comprimidos ou não comprimidos conforme a ordem.

O banco deve registrar a etapa, o mapa de camadas, a faixa assinada, a canonicalização e o algoritmo. Um campo genérico documentHash não distingue duas provas corretas. Guardar apenas o XML final também impede reprocessar uma disputa depois que a tecnologia da passagem original foi substituída.

Nos casos não assinados, o RFC 5402 especifica o MIC sobre o conteúdo descomprimido com cabeçalhos MIME e Content-Transfer-Encoding aplicável. A apresentação legível pode ser igual, mas a entrada criptográfica continua sendo uma sequência normativa de bytes.

Multipart cria uma raiz e vários destinos

O RFC 6362 armazena anexos EDIINT em multipart/related. O parâmetro type identifica o tipo da parte raiz, e start é recomendado para indicar o Content-ID inicial. O conjunto pode conter XML, PDF, imagens e outros tipos acordados pelos parceiros.

Para uma mensagem comprimida e não assinada, o MIC cobre o corpo multipart descomprimido após a canonicalização do transporte. Se o MIC esperado e o calculado divergem, todos os anexos devem ser considerados inválidos e retransmitidos. A regra evita aceitar pedaços de um conjunto cuja integridade comum falhou.

Quando o MIC confere, porém, o trabalho se divide. O agente precisa extrair cada anexo. Depois, cada consumidor decide como armazenar e processar o documento. O próprio RFC 6362 diz que essa parte depende da implementação.

Uma modelagem robusta mantém um recibo pai para a estrutura multipart e um recibo filho para cada Content-ID. No pai ficam os bytes, a ordem, o MIC e o MDN. No filho ficam tipo declarado, hash extraído, parser, esquema, controle de duplicidade, autorização e decisão de negócio. Assim, a retransmissão do conjunto não produz automaticamente uma segunda ordem.

Base64 acompanha a camada binária exposta

O RFC 5402 observa que a parte comprimida precisa de base64 quando aparece externamente em um transporte de sete bits como SMTP. Se ela estiver dentro de uma parte criptografada, a codificação de transferência passa à parte criptografada externa.

Esse detalhe revela que há várias representações legítimas: MIME fonte, bytes comprimidos, envelope cifrado e forma de transporte. No destino vêm decodificação de transferência, decriptação, descompressão e parsing. Uma diferença em qualquer etapa pode alterar o hash correspondente sem mudar a forma final exibida.

Preservar apenas os anexos extraídos elimina a prova de onde ocorreu truncamento, alteração de quebra de linha ou falha de decodificação. Preservar somente o fio, sem a receita, também não basta. Cada digest precisa de nome de etapa e regra de transformação.

Uma auditoria que abre o PDF e calcula SHA-256 está respondendo se aquele arquivo atual é estável. Não está necessariamente reproduzindo o MIC do EDIINT, que pode incluir cabeçalhos, limites e codificação.

Um erro assinado continua sendo erro

Quando a descompressão falha e havia pedido de recibo, o RFC 5402 define Error: decompression-failed no MDN assinado. Esse retorno atribui uma constatação ao parceiro: a camada comprimida não pôde ser revertida.

Ele não diz quais anexos seriam semanticamente válidos, porque talvez nenhum tenha sido extraído. Também não prova sozinho se a causa nasceu no emissor, no transporte ou no limite local do receptor.

O RFC 4130 requer que um recibo assinado ainda seja retornado diante de erro de processamento, e registra que a transação pode não ser válida. Assinar o relatório protege a origem do relatório; não transforma sua disposição em êxito.

Por isso, o sistema deve encaminhar decompression-failed para uma fila técnica com bytes de replay. Traduzir o código em “ordem recusada” pode iniciar compensação comercial indevida, ao mesmo tempo em que apaga a causa que a engenharia precisava investigar.

Capacidade comum não garante a mesma execução

O perfil exige ZLIB, apoiado em DEFLATE. O RFC 3274 define o content type CMS e o identificador do algoritmo. Diferentes níveis de compressão permanecem compatíveis e não precisam ser codificados como parâmetro.

Ainda assim, há um detalhe histórico: os parâmetros do AlgorithmIdentifier podem aparecer omitidos ou como ASN.1 NULL. Implementações podem encontrar as duas formas. Duas caixas marcadas como ZLIB podem divergir nessa tolerância, na ordem MIME, na canonicalização, no tamanho máximo ou no modo de erro.

Ao usar a compressão do RFC 5402, AS2 ou AS3 deve anunciar versão 1.1 ou superior. A versão e a capacidade são pré-condições. Acordo bilateral, configuração habilitada e sucesso observado são fatos adicionais. Nenhum deve herdar o estado do outro.

O recibo comercial vem depois

Um MDN assinado do AS2 pode sustentar não repúdio de recebimento quando a assinatura do receptor e o MIC retornado são verificados. Ele também correlaciona a mensagem original e informa a disposição. É uma prova forte dentro de seu alcance.

Depois dela vêm extração, validação de cada anexo, vínculo com cadastro, autoridade do comprador, disponibilidade, preço, duplicidade e aceite. Um PDF pode ser íntegro e irrelevante. Um XML pode ser íntegro e inválido. Um pedido válido pode aguardar aprovação humana.

As fontes não demonstram adoção atual, comportamento de fornecedor ou incidente específico. Elas permitem uma conclusão limitada e operacional: o MIC do pacote não deve ser copiado para os anexos como se fosse aprovação de todos eles.