Summary

  • RFC 3183 described Experimental S/MIME services that an organizational boundary could perform for users, but a valid domain signature did not necessarily reveal an individually named originator to the outside recipient.
  • Its originator, domain, review and additional-attributes signatures represented different acts; domain encryption and decryption changed custody again. Treating all of them as “the message is signed and secure” destroys the evidence the design tried to preserve.

Imagine a recipient opening a signed message in October 2001. The cryptography verifies. The certificate names a domain signer. The message has passed the originating organization’s checks. Yet the interface has no justified basis for displaying Alice, Carlos or Fatima as the certificate-bound sender. It may display only the domain.

That was not an accidental gap in RFC 3183. Domain Security Services using S/MIME, published as an Experimental RFC, defined machinery for message-transfer agents, guards, firewalls and protocol-translation gateways. Such systems could serve organizations whose users lacked desktop public-key infrastructure, whose internal formats or PKIs did not interoperate, whose message stores reformatted mail, or whose policies required screening and audit at the boundary. The document did not settle the political and architectural contest between end-to-end desktop security and domain-based intervention. It specified parts from which different policies could be assembled.

The most revealing part is its refusal to make every signature mean the same thing.

An originator signature identifies the originator and the signed content. A domain signature is a proxy signature generated on a user’s behalf. Before issuing it, the domain signer must authenticate the originator—either by verifying an inner originator signature or through evidence outside S/MIME, such as an authenticated link—and must validate the other signatures it relies on. If those checks fail, it must not generate the domain signature.

But internal authentication and external naming are not identical. RFC 3183 says successful verification of the domain signature can authenticate the originator, then draws a display boundary. When an originator signature is present, the recipient can use the individual identity carried by that certificate. When it is absent, the recipient’s justified assumption is only the domain from which the message originated. The domain may genuinely have known the employee. The external recipient nonetheless holds the domain’s attestation, not that employee’s independently verifiable certificate identity.

This separates at least four things that ordinary product language often collapses. A human or system produced some content. The originating organization authenticated someone by a local method. A domain authority decided to release a representation of the message. The recipient observed a verifiable domain signature. One event may support the next, but none is a synonym for all the others.

A review signature marks another boundary. It says that the named reviewer or review authority approved the message for onward transmission. A guard could require that approval before releasing mail. The signature does not make the reviewer the author, and RFC 3183 expressly denies that it authenticates the originator. Nor does it prove that the content was true, safe, legally sufficient, delivered or accepted. It proves a narrower action: an identified authority approved onward transmission under some policy.

An additional-attributes signature is narrower in a different direction. It binds attributes in a SignerInfo to the message. Correct verification can show which signer bound which attribute bytes to which content. It cannot by itself establish that an asserted external fact was accurate, current or authorized for a later decision. A cryptographic binding is evidence about the binding. It is not an automatic promotion of every encoded attribute into reality.

The distinction depended on typed evidence. RFC 3183 defined a signed SignatureType attribute with values for originator, domain, additional-attributes and review signatures. A later verified erratum, Erratum 3757, supplied the attribute object identifier omitted from the published text: id-aa-signatureType, under the PKCS 9 arc at 1.2.840.113549.1.9.2.28. The correction mattered to implementations because software needs an unambiguous identifier to parse the claim. It did not enlarge any claim’s semantics. Repairing the label did not turn review into authorship or domain release into a publicly named individual.

Encryption introduced a second authority plane. RFC 3183’s domain confidentiality authority, or DCA, could encrypt for a domain or decrypt on behalf of recipients. This could solve operational problems, but it moved key custody and plaintext across the organizational boundary. A domain key could affect many users at once. When the recipient’s DCA decrypted a message, plaintext existed after that point. If the DCA were compromised, the final recipient could not simply infer integrity from the authority’s report—especially where no signature remained that the recipient could independently verify.

The RFC’s treatment of mailing lists and nested CMS objects shows why the order of operations matters. A gateway might verify a layer, decrypt an envelope, preserve selected signed attributes, strip one wrapper, add a domain signature, re-encrypt the result and retain mail-list expansion history in another signed layer. “Signed” is therefore not a stable property of an abstract message. The evidentiary question is: which bytes, inside which encapsulation, were signed by which named authority, with which signature type, before or after which transformation?

Contemporary S/MIME and Cryptographic Message Syntax specifications supplied the containers and processing vocabulary. Later CMS, S/MIME and PKIX documents changed baselines and clarified the surrounding standards. They do not prove that RFC 3183 was widely deployed, or retroactively turn its Experimental design into an Internet Standard. The IANA registry can corroborate an assigned identifier; allocation is not evidence of use.

The durable historical lesson is not that gateways were good or bad. It is that infrastructure becomes more legible when it records authority as a sequence of specific acts. The person originated. The domain authenticated. The reviewer approved release. The attribute authority bound a claim. The DCA decrypted. The recipient observed. If a system stores only a green padlock or a boolean trusted, it discards exactly the distinctions needed to reconstruct responsibility after the message crosses the boundary.