4. Einschränkungen für "aes128gcm“
4. Einschränkungen für die Nutzung der Inhaltskodierung „aes128gcm“
Ein Anwendungsserver MUST eine Push-Nachricht mit genau einem Datensatz verschlüsseln. So ist eine minimale Empfängerimplementierung möglich, die nur einen Datensatz verarbeitet. Ein Anwendungsserver MUST den Parameter „rs“ im Header der Inhaltskodierung „aes128gcm“ auf eine Größe setzen, die größer ist als die Summe der Längen von Klartext, Padding-Trennzeichen (1 Oktett), beliebigem Padding und Authentifizierungs-Tag (16 Oktette).
Eine Push-Nachricht MUST den öffentlichen ECDH-Schlüssel des Anwendungsservers im Parameter „keyid“ des Headers der verschlüsselten Inhaltskodierung enthalten. Das unkomprimierte Punktformat nach [X9.62] (65 Oktette, beginnend mit 0x04) bildet den gesamten „keyid“. Dadurch ist „keyid“ kein gültiges UTF-8 wie in [RFC8188] empfohlen.
Ein Push-Dienst muss keine Nutzlastkörper größer als 4096 Oktette unterstützen (siehe Abschnitt 7.2 von [RFC8030]). Abzüglich Header (86 Oktette), Padding (mindestens 1 Oktett) und Expansion für AEAD_AES_128_GCM (16 Oktette) ergeben sich höchstens 3993 Oktette Klartext.
Ein Anwendungsserver MUST NOT andere Inhaltskodierungen für Push-Nachrichten verwenden. Insbesondere könnten komprimierende Kodierungen zum Ausleaken des Inhalts führen. Das Header-Feld Content-Encoding hat daher genau einen Wert, nämlich „aes128gcm“. Mehrere „aes128gcm“-Werte sind nicht zulässig.
Ein User-Agent muss mehrere Datensätze nicht unterstützen. Ein User-Agent MAY den Parameter „rs“ ignorieren. Wird die Datensatzgröße nicht geprüft, schlägt die Entschlüsselung in allen gültigen Fällen mit hoher Wahrscheinlichkeit fehl. Das Padding-Trennoktett MUST geprüft werden; Werte außer 0x02 MUST zur Verwerfung der Nachricht führen.