Zusammenfassung

  • Der Experimental RFC 3183 ermöglichte S/MIME-Dienste an Organisationsgrenzen. Eine gültige Domain-Signatur belegte eine Freigabe nach interner Prüfung, nannte dem externen Empfänger aber ohne Urhebersignatur nicht zwingend die Person.
  • SignatureType unterschied Urheber-, Domain-, Zusatzattribut- und Prüfsignatur. Das verifizierte Erratum 3757 ergänzte die fehlende OID; es änderte nicht die begrenzte Bedeutung der einzelnen Beweise.

Domain Security Services using S/MIME erschien im Oktober 2001. Mail Transfer Agents, Guards, Firewalls und Übersetzungsgateways sollten für eine Organisation S/MIME verarbeiten können, wenn Endgeräte keine PKI besaßen, interne Formate nicht zusammenpassten oder Grenzkontrollen verlangt wurden. Der Text entschied den Streit zwischen Ende-zu-Ende- und Domain-Sicherheit nicht. Er stellte Bausteine bereit.

Eine Urhebersignatur verband den Urheber mit dem Inhalt. Eine Domain-Signatur war eine Stellvertretersignatur. Vor ihrer Erzeugung musste der Domain-Signierer den Urheber durch eine innere Signatur oder einen außerhalb von S/MIME liegenden Mechanismus authentisieren und weitere relevante Signaturen prüfen. Bei Fehlschlag durfte er nicht signieren.

Dennoch blieb die interne Kenntnis der Person von ihrer extern nachweisbaren Identität getrennt. War eine Urhebersignatur vorhanden, konnte ihr Zertifikat den Namen liefern. Ohne sie durfte der Empfänger nach RFC 3183 nur die Herkunfts-Domain annehmen. Die Organisation konnte den Mitarbeiter kennen; nach außen sprach kryptografisch die Domain.

Eine Prüfsignatur bedeutete, dass ein Prüfer die Weiterleitung genehmigt hatte. Sie machte ihn weder zum Autor noch authentisierte sie den Urheber. Wahrheit, Rechtmäßigkeit, Zustellung und Annahme folgten daraus ebenfalls nicht. Eine Zusatzattributsignatur band Attribute in SignerInfo an den Inhalt. Sie bewies die Bindung, nicht automatisch die Wahrheit oder Aktualität der dargestellten Außenwelt.

Genau deshalb war die Typisierung wichtig. RFC 3183 definierte SignatureType; Erratum 3757 ergänzte die ausgelassene OID 1.2.840.113549.1.9.2.28. Maschinen konnten damit die behauptete Rolle eindeutig adressieren. Die Korrektur machte aus einer Prüffreigabe keine Autorschaft und aus einer Domain-Freigabe keinen persönlichen Zertifikatsnamen.

Auch Verschlüsselung verlagerte Autorität. Eine Domain Confidentiality Authority konnte für Nutzer ver- und entschlüsseln. Das löste Betriebsprobleme, konzentrierte aber Schlüsselrisiko. Nach der Entschlüsselung an der Empfängergrenze lag Klartext vor. War die DCA kompromittiert und blieb keine unabhängig prüfbare Signatur erhalten, konnte ihr eigener Erfolgsbericht die Integrität nicht garantieren.

Bei Mailinglisten und verschachtelten CMS-Objekten konnte ein Gateway Schichten prüfen, entschlüsseln, entfernen, Attribute bewahren, neu signieren und erneut verschlüsseln. „Die Nachricht ist signiert“ bezeichnete daher keinen zeitlosen Zustand. Relevant waren Bytes, Inhaltstyp, Signaturrolle, Zertifikat und die Position vor oder nach jeder Transformation.

Zeitgenössische S/MIME-, CMS- und ESS-RFCs lieferten die Container. Spätere CMS-, S/MIME- und PKIX-Texte aktualisierten den Kontext, beweisen aber weder breite Nutzung noch einen Standardstatus für RFC 3183. Auch eine IANA-Zuweisung beweist nur die Registrierung.

Historisch bleibt eine Grammatik der Zuständigkeit: Der Mensch erzeugt, die Domain authentisiert und gibt frei, der Prüfer genehmigt, die Attributinstanz bindet, die DCA öffnet und der Empfänger beobachtet. Wer daraus ein einziges „vertrauenswürdig“ macht, entfernt die Subjekte aus der Geschichte.