1. Introduction
1. Introduction
Le protocole Web Push [RFC8030] est par nature un protocole avec intermédiaire. Les messages issus d'un serveur d'application sont livrés à un agent utilisateur (UA) via un service push (push service), comme le montre la figure 1.
+-------+ +--------------+ +-------------+
| UA | | Push Service | | Application |
+-------+ +--------------+ +-------------+
| | |
| Setup | |
|<====================>| |
| Provide Subscription |
|-------------------------------------------->|
| | |
: : :
| | Push Message |
| Push Message |<---------------------|
|<---------------------| |
| | |
Figure 1
Ce document décrit comment sécuriser les messages envoyés avec ce protocole contre l'observation, la modification et la falsification par le service push.
Les messages Web Push sont la charge utile d'un message HTTP [RFC7230]. Ils sont chiffrés à l'aide d'un codage de contenu chiffré (encrypted content encoding) [RFC8188]. Ce document précise comment appliquer ce codage et propose un schéma de gestion des clés recommandé.
Plusieurs utilisateurs de Web Push sur le même agent utilisateur partagent souvent un agent central qui agrège la fonctionnalité push. Cet agent peut imposer l'usage de ce schéma de chiffrement aux applications qui utilisent la messagerie push. Un agent qui ne livre que des messages correctement chiffrés favorise fortement la protection de bout en bout.
Un navigateur web qui implémente l'API Push [API] peut imposer le chiffrement en ne relayant que les messages correctement chiffrés.
1.1. Conventions de notation
Les mots-clés « MUST », « MUST NOT », « REQUIRED », « SHALL », « SHALL NOT », « SHOULD », « SHOULD NOT », « RECOMMENDED », « NOT RECOMMENDED », « MAY » et « OPTIONAL » dans ce document doivent être interprétés comme décrit dans le BCP 14 [RFC2119] [RFC8174] lorsqu'ils apparaissent en majuscules comme ici.
Ce document reprend la terminologie de [RFC8030], en particulier « user agent », « push service » et « application server ».