Zusammenfassung

  • RFC 3058 vergab getrennte Kennungen und Parameterregeln für IDEA-Inhaltsverschlüsselung und IDEA-Schlüsselverpackung. Die Drahtdarstellung wurde exakt, doch Unterstützung blieb optional; je nach Kontext waren Parameter abwesend, NULL oder enthielten einen Acht-Oktett-IV.
  • Eine signierte S/MIME-Fähigkeit war eine geordnete Behauptung des Clients, kein Ausführungsbeleg. Tatsächliche Nutzung hing weiter von beiden Endpunkten, lokalen Präferenzen, privaten Absprachen, rechtlichen Grenzen, Schlüsselzugriff und erfolgreicher Verarbeitung ab.

Ein Name reicht nicht für zwei Aufgaben

Kryptografische Software kann nicht allein über „IDEA verwenden“ interoperieren. CMS braucht Algorithmuskennung, Parameter und den Ort jedes Werts. Außerdem muss die Verschlüsselung des Inhalts von der Verschlüsselung seines Inhaltsschlüssels getrennt werden. Der im Februar 2001 als Informational veröffentlichte RFC 3058 lieferte diese Präzision.

Eine OID benannte IDEA-CBC für Inhalte, eine zweite die IDEA-Schlüsselverpackung. Die erste arbeitete mit einem 128-Bit-Schlüssel und 64-Bit-Blöcken. Die zweite nahm einen 16-Oktett-Inhaltsschlüssel, verband ihn mit einem Acht-Oktett-Prüfwert und erzeugte 32 verpackte Oktette. „Unterstützt IDEA“ verwischte zwei Funktionen.

Die OIDs lagen unter einem Ascom zugeordneten privaten Unternehmenszweig. Ihr Nutzen war Koordination: unabhängige Implementierungen konnten dieselbe Funktion gleich benennen. Die Registrierung sagte nicht, dass jeder S/MIME-Client den Code enthielt, jeder Nutzer ihn aktivieren durfte oder eine Nachricht einen Menschen erreichte. Sie machte eine Wahl lesbar, nicht verfügbar.

Abwesend, NULL und IV sind nicht dasselbe Nichts

Die Inhaltskennung erlaubte IDEA-CBCPar mit einem optionalen IV von genau acht Oktetten. War er im Parameter vorhanden, wurde er dort genutzt und nicht dem Geheimtext vorangestellt. Fehlte der Parameter, galten die ersten 64 Geheimtextbits als IV; RFC 3058 riet von dieser Form in CMS und S/MIME ab.

Für die Verpackungskennung galt eine andere Regel: Parameter mussten NULL sein. In den beiden S/MIME-Fähigkeiten mussten sie dagegen fehlen. Umgangssprachlich wirkt alles wie „kein Wert“. In ASN.1 sind es verschiedene Bytes und Anweisungen.

Das ist der leise Kern des Dokuments. Eine Kennung wird erst durch Kontext und Parameterkonvention zur vollständigen Anweisung. Wer Abwesenheit und NULL vertauscht, kann Gültiges ablehnen oder nie vereinbarte Semantik akzeptieren. Ein Dashboard mit nur „IDEA“ verliert die Belege zur Reproduktion.

Erratum 5913, für eine Dokumentaktualisierung zurückgehalten, verstärkt den Punkt: Das ASN.1-Symbol IDEA-CBC sollte wegen der Kleinbuchstabenregel id-IDEA-CBC heißen; die numerische OID bleibt gleich. Menschenname, Quellbezeichner und Registrierungszahl sind verwandt, aber nicht identisch.

Innen zufällig, außen fest

Die Verpackung war schrittweise definiert. Zum 16-Oktett-Inhaltsschlüssel kam ein Acht-Oktett-Prüfwert. Ein zufälliger Acht-Oktett-IV verschlüsselte diese 24 Oktette mit IDEA-CBC. Danach wurde der zufällige IV vorangestellt, alle 32 Oktette umgekehrt und mit dem festen äußeren IV 4adda22c79e82105 erneut verschlüsselt. Beim Auspacken führte ein falscher Prüfwert zur Ablehnung.

Allein betrachtet kann der feste äußere IV täuschen: Der frische innere IV bleibt bestehen. Umgekehrt beweisen Zufall und passender Prüfwert weder Autorisierung noch Empfängerpräferenz oder sinnvollen Inhalt. Der Prüfwert beantwortet nur eine enge Frage zum ausgepackten Schlüssel.

CMS trennte die Schichten wegen ihrer unterschiedlichen Aufgaben. Der Inhaltsschlüssel schützte den Text, ein Schlüsselverschlüsselungsschlüssel schützte ihn, das Format transportierte ihn, der Umschlag benannte Algorithmen und Empfänger. Erfolg in einer Schicht quittierte nicht alle anderen.

Signiert, geordnet und unvollständig

Clients konnten SMIMECapabilities als signiertes Attribut veröffentlichen. RFC 3058 gab exakte DER-Bytes für IDEA-CBC und Verpackung in getrennten Kategorien; die Reihenfolge konnte Präferenz ausdrücken. Spätere S/MIME-Texte beschrieben die Liste weiterhin als partiell, nicht als vollständiges Inventar.

Eine geprüfte Signatur ordnete die Behauptung dem signierten Kontext zu, mit Zertifikats- und Zeitprüfung. Sie befragte nicht den gegenwärtigen Prozess. Upgrade, Konfiguration, fehlender Provider, unzugänglicher Schlüssel oder lokale Richtlinie konnten Behauptung und Ausführung trennen. Vorhandene Unterstützung konnte auch unerwähnt bleiben.

RFC 3058 ließ die Auswahl außerhalb des Registers. Genannt wurden empfangene Fähigkeiten, private Vereinbarungen, Nutzerpräferenzen und rechtliche Beschränkungen. Wenn Nutzer IDEA verlangten, mussten beide Clients es unterstützen und die Präferenz gesetzt sein. Die OID beseitigte Byte-Mehrdeutigkeit, übte aber keine dieser Befugnisse aus.

Lizenz und Drahtformat blieben getrennt

Der damalige IPR-Hinweis erklärte, Ascom halte Patente, biete nicht ausschließliche Lizenzen zu angemessenen und diskriminierungsfreien Bedingungen an und erlaube nichtkommerzielle Nutzung kostenlos. Das ist historische Evidenz für die 2001 dargestellte Grenze, keine heutige Rechtsberatung. Technische Standardisierung löschte die erklärte Lizenzschicht nicht.

Eine Implementierung konnte die OID erkennen und den Algorithmus auslassen. Entwickler konnten Code besitzen, während eine Organisation Bedingungen ablehnte. Ein Empfänger konnte Fähigkeit anzeigen, während die Senderpolitik anderes auswählte. Die Registrierung übernahm diese Entscheidungen nicht.

RFC 3370 trennte allgemeine Algorithmuskonventionen vom CMS-Kern; RFC 5652 definierte späteres CMS; RFC 8551 gab AES und ChaCha20-Poly1305 Anforderungsstufen und behielt Fähigkeits- sowie Außerbandentscheidungen. Diese Entwicklung beweist keine IDEA-Installation, und das Fehlen in einer modernen Pflichtliste löscht die OIDs nicht.

Die bleibende Lehre ist nicht Sieg oder Niederlage von IDEA. Standardisierung kann eine Entscheidung reproduzierbar machen, ohne sie zu verallgemeinern. Die Zahl identifiziert, Parameter erklären, die signierte Fähigkeit ordnet eine Behauptung zu, Richtlinie und Recht begrenzen die Wahl. Nur ein realer Austausch zeigt, ob beide Enden ihre Arbeit erledigten.

Quellen

Lu Heng schrieb oder billigte RFC 3058 nicht. Seine Essays dienen nur als offengelegte analytische Linse zwischen symbolischer Registrierung und ausführbarem Verhalten.