Resumo

  • RFC 3183 descreveu, em caráter Experimental, serviços S/MIME prestados por agentes e gateways de uma organização. Eles podiam assinar, revisar, cifrar ou decifrar em nome de usuários, mas cada operação representava uma autoridade diferente.
  • Uma assinatura de domínio válida podia registrar que a organização autenticou internamente o originador e liberou a mensagem; sem a assinatura pessoal do originador, o destinatário externo ainda só podia atribuí-la ao domínio.

Publicado em outubro de 2001 como Domain Security Services using S/MIME, RFC 3183 tratava de ambientes em que a segurança não cabia apenas no cliente de correio. Usuários podiam não ter PKI no desktop; organizações podiam manter formatos e certificados incompatíveis; armazenamentos podiam remodelar mensagens; guardas e firewalls podiam exigir inspeção. O documento ofereceu mecanismos para que MTAs e gateways atuassem no limite do domínio, sem declarar vencedor o debate entre segurança de ponta a ponta e segurança intermediada.

A assinatura do originador identificava o originador e o conteúdo. A assinatura de domínio era uma assinatura por procuração. Antes de emiti-la, o signatário do domínio precisava autenticar o originador por uma assinatura interior ou por mecanismo externo ao S/MIME, além de validar as demais assinaturas pertinentes. Se a verificação falhasse, a assinatura de domínio não deveria existir.

Mesmo assim, conhecimento interno e identidade externamente demonstrável não eram equivalentes. Com uma assinatura pessoal do originador, seu certificado podia fornecer o nome. Sem ela, RFC 3183 limitava a inferência do destinatário ao domínio de origem. A organização podia saber qual funcionário usou uma ligação autenticada; o destinatário recebia a declaração criptográfica da organização, não necessariamente a identidade certificada daquele funcionário.

Esse limite separava cinco camadas: a pessoa produziu conteúdo; um mecanismo interno reconheceu um sujeito; a autoridade do domínio autorizou a saída; um objeto S/MIME representou essa decisão; o destinatário verificou o objeto. A frase “o remetente foi autenticado” perde informação quando não diz por quem e com que evidência disponível fora do domínio.

A assinatura de revisão registrava aprovação para encaminhamento. Um guarda podia exigi-la, mas o revisor não virava autor. Ela não autenticava o originador, nem provava verdade, conformidade jurídica, entrega ou aceitação. A assinatura de atributos adicionais ligava atributos em SignerInfo à mensagem. Provava a vinculação feita por uma autoridade; não tornava verdadeiro ou atual todo fato externo descrito pelo atributo.

RFC 3183 definiu o atributo assinado SignatureType para manter esses papéis distintos. O Erratum verificado 3757 forneceu o identificador omitido: id-aa-signatureType, 1.2.840.113549.1.9.2.28. A correção permite reconhecer o tipo de alegação, sem ampliar seu alcance. Aprovação continua não sendo autoria.

A autoridade de confidencialidade do domínio, ou DCA, mudava a custódia. Ela podia cifrar para um domínio e decifrar para seus usuários. Uma chave assim concentrava risco sobre muitas pessoas. Depois da decifragem na fronteira receptora, havia texto claro a jusante. Se a DCA estivesse comprometida, o usuário final não poderia confiar apenas no relato da mesma autoridade sobre integridade; uma assinatura sobrevivente e verificável de forma independente faria diferença.

O tratamento de listas e objetos CMS aninhados tornava a sequência visível. Um gateway podia verificar, decifrar, remover uma camada, preservar atributos, acrescentar assinatura de domínio, cifrar novamente e envolver o resultado para conservar o histórico de expansão da lista. A mensagem não possuía uma qualidade atemporal chamada “assinada”. Cada assinatura cobria bytes específicos, em uma camada específica, antes ou depois de uma transformação.

As RFCs contemporâneas de S/MIME, CMS e serviços de segurança aprimorados forneceram os recipientes. Documentos posteriores atualizaram CMS, S/MIME e PKIX, mas não provam implantação ampla de RFC 3183 nem mudam seu status Experimental. O registro da IANA comprova alocação de identificador, não uso.

A contribuição histórica é uma linguagem de verbos com sujeitos. O indivíduo origina. O domínio autentica e libera. O revisor aprova o trânsito. A autoridade de atributos vincula. A DCA abre. O destinatário observa. Quando o sistema guarda apenas “seguro”, elimina a trilha que permitiria entender responsabilidade e custódia.