4. Restrictions d'usage du codage ' aes128gcm '

4. Restrictions d'usage du codage de contenu « aes128gcm »

Un serveur d'application MUST chiffrer un message push avec un seul enregistrement (single record). Cela permet une implémentation réceptrice minimale qui ne gère qu'un enregistrement. Un serveur d'application MUST régler le paramètre « rs » de l'en-tête du codage de contenu « aes128gcm » à une taille supérieure à la somme des longueurs du texte clair, du délimiteur de remplissage (1 octet), de tout remplissage et de l'étiquette d'authentification (16 octets).

Un message push MUST inclure la clé publique ECDH du serveur d'application dans le paramètre « keyid » de l'en-tête du codage de contenu chiffré. Le format de point non compressé défini dans [X9.62] (séquence de 65 octets commençant par 0x04) constitue l'intégralité de « keyid ». Ainsi « keyid » ne sera pas de l'UTF-8 valide comme recommandé dans [RFC8188].

Un service push n'est pas tenu de prendre en charge plus de 4096 octets de corps de charge utile (voir section 7.2 de [RFC8030]). En retranchant l'en-tête (86 octets), le remplissage (au minimum 1 octet) et l'expansion AEAD_AES_128_GCM (16 octets), cela correspond au plus à 3993 octets de texte clair.

Un serveur d'application MUST NOT utiliser d'autres codages de contenu pour les messages push. En particulier, les codages qui compressent pourraient entraîner une fuite du contenu des messages. Le champ d'en-tête Content-Encoding a donc exactement une valeur, « aes128gcm ». Plusieurs valeurs « aes128gcm » ne sont pas permises.

Un agent utilisateur n'est pas tenu de prendre en charge plusieurs enregistrements. Un agent utilisateur MAY ignorer le paramètre « rs ». Si la taille d'enregistrement n'est pas vérifiée, le déchiffrement échouera avec forte probabilité dans tous les cas valides. L'octet délimiteur de remplissage MUST être vérifié ; toute valeur autre que 0x02 MUST entraîner l'abandon du message.