Summary

  • AS2-From e AS2-To são textos sensíveis a maiúsculas combinados pelos parceiros; não são identidades universais derivadas do certificado.
  • draft-ietf-ediint-rfc4130bis-04 manda separar o certificado TLS do certificado AS2 usado para assinar ou cifrar mensagens e exige proteção na obtenção e ativação das chaves.
  • Assinatura válida, nomes refletidos e MIC coincidente comprovam etapas importantes. A autorização da chave para um nome, direção e relacionamento continua sendo decisão local.

O incidente que começa sem falha criptográfica

Considere uma rotação concluída dentro da janela. O HTTPS funciona. O AS2-From tem a grafia esperada. O MDN devolve os nomes na ordem correta. A assinatura nova passa e o MIC coincide. A investigação só começa quando alguém pergunta quem autorizou a nova impressão digital para aquele fluxo.

A revisão 04 fornece a gramática para separar essas evidências. O Datatracker mostra um Internet-Draft ativo do EDIINT; a API registra I-D Exists, e o histórico data a versão em 24 de setembro de 2026. A intenção é Proposed Standard. Ainda não é RFC e só substituiria a RFC 4130 se aprovada.

Três superfícies de identidade

A primeira é o nome AS2. A seção 6.3 aceita DUNS ou uma string acordada. O valor tem 1 a 128 caracteres ASCII imprimíveis, diferencia maiúsculas e é obrigatório em mensagens e MDNs. Na resposta, AS2-To corresponde ao AS2-From da solicitação, e vice-versa.

Isso prova consistência textual, não identidade jurídica. Um nome desconhecido pode produzir unknown-trading-relationship ou unknown-trading-partner, justamente porque o receptor consulta uma relação local. O rascunho não cria cadastro mundial que associe cada nome a uma única chave.

A segunda superfície é o endpoint HTTPS. RFC 8446 define TLS 1.3 e RFC 9110 a semântica HTTP. RFC 9525 ajuda a contextualizar identidade de serviço moderna, mas não é uma regra de vínculo incorporada pelo texto AS2.

A terceira é a mensagem. S/MIME e CMS aparecem em RFC 8551 e RFC 5652; RFC 5280 cobre a linhagem PKIX. O rascunho exige que o certificado AS2 não seja o mesmo do TLS. Renovação e comprometimento de canal e conteúdo permanecem separados.

Uma cadeia válida responde se o certificado satisfaz a política de confiança. Não responde se a equipe B2B o aprovou para o parceiro X, no sentido Y e na data Z.

Distribuição segura ainda precisa de destino certo

A seção 9.2 recomenda Certificate Exchange Messaging, descrito no rascunho CEM. Sem CEM, a troca manual deve garantir integridade e autenticação antes da ativação. Uma URI Well-Known pode servir para obtenção inicial, desde que o solicitante seja autenticado e o acesso autorizado.

Certificados autoassinados exigem confirmação adicional fora de banda, como conferir a impressão digital por canal seguro. A assinatura do emissor torna adulteração detectável; não seleciona a linha correta da tabela de parceiros.

O comprovante de ativação deve reunir grafia exata, relacionamento, direção, uso, impressão digital, série, algoritmo, validade, método de confiança, origem, aprovadores, horário, sobreposição e retorno. O texto exige erro imediato e visível para certificado expirado, revogado ou não confiável. Mesmo assim, um certificado válido pode estar autorizado para outro parceiro.

Um MDN não autoriza sua própria chave

O remetente preserva mensagem, Message-ID e MIC. O receptor devolve MDN assinado; o remetente verifica assinatura, Original-Message-ID e MIC. RFC 8098 é a referência atual para MDN.

O rascunho chama o resultado verificado de “non-repudiation of receipt”. Não o tratamos como sentença jurídica universal. Também não repetimos a tese já publicada de que entrega não é aceitação comercial. A questão aqui é anterior: a chave pública usada na verificação já tinha autoridade local sobre aquele nome?

A escada correta é: HTTP/TLS; nomes; validade do certificado; autorização local; assinatura; Message-ID/MIC; disposition do MDN; aceitação EDI; resultado comercial. Uma etapa não herda automaticamente a competência da próxima.

A revisão 03 já continha controles centrais de certificado. A formulação segura é que a revisão atual os codifica. As versões HTML e XML confirmam a estrutura, não uma implantação.

Fontes e limites

O pacote inclui texto, HTML e XML da revisão 04; página, API e histórico do Datatracker; revisão 03; RFC 4130, RFC 8098, RFC 8551, RFC 8615, RFC 5652, RFC 5280, rascunho CEM, RFC 9110, RFC 9525 e RFC 8446. A leitura de liderança usa separadamente Lu Heng sobre primazia do código em execução, camadas de realidade e especificação inicial mínima. As fontes não provam produto, incidente, ataque ou decisão judicial.