Zusammenfassung

  • RFC 5259 lässt das gespeicherte Original unverändert und gibt ein angefordertes oder serverseitig gewähltes Derivat zurück; Lesbarkeit beweist weder Bytegleichheit noch Signaturgültigkeit oder dauerhafte Ersetzung.
  • Ein abschließendes OK kann Einzelfehler enthalten, während Standardkonvertierung Details entfernt oder Zeichen ersetzt. Der Nachweis muss deshalb je Ausgabeelement geführt werden.

Die Darstellung trug noch das Siegel, aber nicht mehr dessen Beweis

Ein mobiles Gerät konnte den Vertrag nicht öffnen. Der Server wählte ein anderes Format, reduzierte Bilder und zeigte eine saubere Seite. Das Signaturbild blieb sichtbar. Im Protokoll stand anschließend, der signierte Vertrag sei geprüft worden.

RFC 5259 sagt: Wird ein signierter Bodypart serverseitig konvertiert, kann der Client die Authentizität des konvertierten Inhalts nicht mit der ursprünglichen Signatur prüfen. Wer dem Server nicht vertraut, muss das signierte Objekt laden, verifizieren und selbst konvertieren.

Die Darstellung kann korrekt und nützlich sein. Sie erbt dennoch nicht durch Aussehen die kryptografische Autorität ihrer Quelle.

Quelle und Ausgabe sind getrennte Gegenstände

Konvertierung betrifft nur die Übertragung zum Client. Originaldaten im Message Store dürfen nicht verändert werden. Andere Clients behalten die Quelle, Antworten und Weiterleitungen nutzen sie, BODYSTRUCTURE bleibt erhalten und Signaturen können am richtigen Objekt geprüft werden.

Das Derivat darf MIME-Typ, Struktur, Kodierung, Abmessungen, Zeichensatz und Größe ändern. Es gehört zu einer Ausführung. Nur die Ausgabe zu archivieren belegt keine Änderung der Quelle.

Bewahren Sie Quellenidentität mit Postfach, UID, Teil und Hash sowie Ausgabeidentität mit Anfrage, Richtlinie, Parametern, Version und Hash.

Capability ist kein Ausführungsbeleg

Der Server bewirbt CONVERT und BINARY. CONVERSIONS nennt Quell-/Zielpaare und Parameter, AVAILABLECONVERSIONS Ziele für einen Teil. Das ist ein Möglichkeitsraum.

Später können Ressourcen fehlen, Dienste ausfallen, Parameter ungültig oder Formate ohne Konverter sein. Revision und Richtlinie können wechseln. Ein angekündigter Pfad ist kein Hash der erzeugten Bytes.

Erfassung von Fähigkeiten und konkrete Ausführung brauchen eigene Zeitpunkte und Belege.

NIL delegiert die sichtbare Version

Der Client nennt ein Ziel oder übergibt NIL. Der Server entscheidet dann aus Gerätewissen, Nutzer-/Administratorpräferenzen, Konfiguration und angenommenen Standardformaten. Der Algorithmus ist nicht vollständig normiert.

Details oberhalb der Gerätefähigkeit dürfen entfernt werden, etwa Bildauflösung. Qualitätsverlust soll minimiert werden, doch das verspricht keine verlustfreie Gleichheit. Ohne Capability-Signal kann der Server falsch raten.

Standardkonvertierung delegiert somit eine Darstellungsentscheidung. Der Beleg muss das gewählte Ziel und seine Auswahlgrundlage nennen.

Gültige Ausgabe kann Information ersetzen

Textkonvertierung braucht einen Zielzeichensatz. Nicht darstellbare Zeichen können durch unknown-character-replacement ersetzt werden. Das Ergebnis erfüllt die Anfrage und verliert zugleich einen Unterschied.

Header und MIME-Parameter können dekodiert und neu kodiert werden. Ähnliche Lesart ist keine Oktettgleichheit. Treue umfasst Bytes, Text, Layout, Maße und Auslassungen getrennt.

Teilbereiche von CONVERT BINARY beziehen sich auf transkodierte und dekodierte Daten, nicht auf Quelloffsets. Eine Derivatkoordinate darf nicht als Originalfundstelle zitiert werden.

OK ist keine Vollständigkeitszahl

CONVERTED kann TEMPFAIL, BADPARAMETERS oder MISSINGPARAMETERS tragen. Sobald eine Konvertierung gelingt, muss der Tag OK lauten. Selbst bei vollständigem Fehlschlag ist OK oder NO möglich.

Der grüne Gesamtstatus sagt daher nicht, welche Teile ankamen. Jeder angeforderte Wert muss seinem Ergebnis oder Fehler zugeordnet werden. Struktur kann vorliegen, obwohl Bytes fehlen.

BODYPARTSTRUCTURE zeigt gewöhnlich, ob die Anfrage genau erfüllt wurde, erklärt aber nicht immer den Grund. Speichern Sie sie mit Parametern und Hash.

Weder gelesen noch kanonisch

CONVERT setzt niemals \Seen; dazu braucht es STORE. Erzeugte Bytes belegen keinen Leser und keine Statusänderung.

Der Server darf Ausgaben cachen und soll die Anzahl gegen DoS begrenzen. Cache ist flüchtiger Ausführungszustand, kein alternatives Original. Codec, Policy, Schrift und externer Dienst können eine spätere Wiederholung ändern.

Entscheidungsrelevante Ausgaben müssen deshalb im Moment der Nutzung erhalten werden.

Der Transcoder ist eine Sicherheitsgrenze

Ein präpariertes APPEND mit anschließendem CONVERT kann Parser oder Codec angreifen. Extreme Skalierung verbraucht Ressourcen; gefährliche Umwandlung kann ausführbaren Inhalt erzeugen. Empfohlen sind Ablehnung teurer Vorgänge, Ausgabeprüfung, Protokollierung der Identität und Isolation vom privilegierten Store.

Ein externer Dienst ergänzt einen Verwahrungsschritt. Gleiche Vertrauensdomäne reduziert, beseitigt aber nicht den Übergang. SASL/TLS schützt Peer und Kanal, authentifiziert nicht neue Bytes unter alter Signatur.

Ein Beleg von der Quelle zum Derivat

Erhalten Sie Postfach, UIDVALIDITY/UID, Quellteil, MIME, Größe und Hash; Typen und Parameter; explizite oder Standardwahl; Gerätefähigkeit, Präferenzen, Richtlinie, Revision, Transcoder, Zeitpunkt und Sicherheitsdomäne.

Fügen Sie jedes CONVERTED-Element, Fehler und Endstatus, Ausgabe-MIME/Größe/Hash, Reduktion, Ersatz, Cache, Quellsignaturprüfung, fehlende Vererbungsprüfung, Anzeige, \Seen und Folgeentscheidung hinzu.

„Dieser Server erzeugte diese Bytes“ ist prüfbar. „Das ist der signierte Anhang“ braucht Authentifizierung über die neuen Bytes. „Erfolgreich“ verlangt Ergebnisse für alle Elemente.

RFC 5259 gab eingeschränkten Clients nützliche Anpassung. Führung muss verhindern, dass eine bequeme Darstellung das authentifizierte Original verkörpert.

Quellen