4. Restrizioni su ' aes128gcm '
4. Restrizioni sull'uso della codifica di contenuto « aes128gcm »
Un application server MUST crittografare un messaggio push con un singolo record. Ciò consente un'implementazione ricevente minimale che gestisce un solo record. Un application server MUST impostare il parametro « rs » nell'intestazione della codifica di contenuto « aes128gcm » a una dimensione maggiore della somma delle lunghezze del testo in chiaro, del delimitatore di padding (1 ottetto), di eventuale padding e del tag di autenticazione (16 ottetti).
Un messaggio push MUST includere la chiave pubblica ECDH dell'application server nel parametro « keyid » dell'intestazione della codifica di contenuto crittografata. Il formato di punto non compresso definito in [X9.62] (sequenza di 65 ottetti che inizia con 0x04) costituisce per intero il « keyid ». Ciò implica che « keyid » non sarà UTF-8 valido come raccomandato in [RFC8188].
Un push service non è tenuto a supportare più di 4096 ottetti di corpo del payload (vedere Sezione 7.2 di [RFC8030]). Al netto dell'intestazione (86 ottetti), del padding (minimo 1 ottetto) e dell'espansione per AEAD_AES_128_GCM (16 ottetti), ciò equivale al massimo a 3993 ottetti di testo in chiaro.
Un application server MUST NOT usare altre codifiche di contenuto per i messaggi push. In particolare, codifiche che comprimono potrebbero far trapelare il contenuto. Il campo di intestazione Content-Encoding ha quindi esattamente un valore, « aes128gcm ». Non sono consentiti valori multipli « aes128gcm ».
Un user agent non è tenuto a supportare più record. Un user agent MAY ignorare il parametro « rs ». Se la dimensione del record non è controllata, la decifratura fallirà con alta probabilità in tutti i casi validi. L'ottetto delimitatore di padding MUST essere verificato; valori diversi da 0x02 MUST causare lo scarto del messaggio.