5. Producing and Consuming JWEs (Production et consommation des JWE)

5.1 Message Encryption (Chiffrement de message)

Le processus de chiffrement de message est le suivant. L'ordre des étapes n'est pas significatif dans les cas où il n'y a pas de dépendances entre les entrées et les sorties des étapes.

1. Déterminer le mode de gestion des clés employé par l'algorithme utilisé pour déterminer la valeur de la clé de chiffrement de contenu. (C'est l'algorithme enregistré dans le paramètre d'en-tête "alg" (algorithm, algorithme) du JWE résultant.)

2. Lorsque l'enveloppement de clé, le chiffrement de clé ou l'accord de clé avec enveloppement de clé sont employés, générer une valeur CEK aléatoire. Voir RFC 4086 [RFC4086] pour les considérations sur la génération de valeurs aléatoires. La CEK doit (MUST) avoir une longueur égale à celle requise pour l'algorithme de chiffrement de contenu.

3. Lorsque l'accord de clé direct ou l'accord de clé avec enveloppement de clé sont employés, utiliser l'algorithme d'accord de clé pour calculer la valeur de la clé convenue. Lorsque l'accord de clé direct est employé, laisser la CEK être la clé convenue. Lorsque l'accord de clé avec enveloppement de clé est employé, la clé convenue sera utilisée pour envelopper la CEK.

4. Lorsque l'enveloppement de clé, le chiffrement de clé ou l'accord de clé avec enveloppement de clé sont employés, chiffrer la CEK pour le destinataire et laisser le résultat être la clé chiffrée JWE.

5. Lorsque l'accord de clé direct ou le chiffrement direct sont employés, laisser la clé chiffrée JWE être la séquence d'octets vide.

6. Lorsque le chiffrement direct est employé, laisser la CEK être la clé symétrique partagée.

7. Calculer la valeur de clé encodée BASE64URL(JWE Encrypted Key).

8. Si la sérialisation JSON JWE est utilisée, répéter ce processus (étapes 1-7) pour chaque destinataire.

9. Générer un vecteur d'initialisation JWE aléatoire de la taille correcte pour l'algorithme de chiffrement de contenu (si requis par l'algorithme); sinon, laisser le vecteur d'initialisation JWE être la séquence d'octets vide.

10. Calculer la valeur de vecteur d'initialisation encodée BASE64URL(JWE Initialization Vector).

11. Si un paramètre "zip" est inclus, compresser le texte en clair en utilisant l'algorithme de compression spécifié et laisser M être la séquence d'octets représentant le texte en clair compressé; sinon, laisser M être la séquence d'octets représentant le texte en clair.

12. Créer le ou les objets JSON contenant l'ensemble souhaité de paramètres d'en-tête, qui constituent ensemble l'en-tête JOSE: l'en-tête protégé JWE, l'en-tête non protégé partagé JWE et l'en-tête non protégé par destinataire JWE.

13. Calculer la valeur d'en-tête protégé encodée BASE64URL(UTF8(JWE Protected Header)). Si l'en-tête protégé JWE n'est pas présent (ce qui ne peut se produire que lors de l'utilisation de la sérialisation JSON JWE et qu'aucun membre "protected" n'est présent), laisser cette valeur être la chaîne vide.

14. Laisser le paramètre de chiffrement de données authentifiées supplémentaires être ASCII(Encoded Protected Header). Cependant, si une valeur JWE AAD est présente (ce qui ne peut être le cas que lors de l'utilisation de la sérialisation JSON JWE), laisser plutôt le paramètre de chiffrement de données authentifiées supplémentaires être ASCII(Encoded Protected Header || '.' || BASE64URL(JWE AAD)).

15. Chiffrer M en utilisant la CEK, le vecteur d'initialisation JWE et la valeur de données authentifiées supplémentaires en utilisant l'algorithme de chiffrement de contenu spécifié pour créer la valeur de texte chiffré JWE et le tag d'authentification JWE (qui est la sortie du tag d'authentification de l'opération de chiffrement).

16. Calculer la valeur de texte chiffré encodée BASE64URL(JWE Ciphertext).

17. Calculer la valeur de tag d'authentification encodée BASE64URL(JWE Authentication Tag).

18. Si une valeur JWE AAD est présente, calculer la valeur AAD encodée BASE64URL(JWE AAD).

19. Créer la sortie sérialisée souhaitée. La sérialisation compacte de ce résultat est la chaîne BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag). La sérialisation JSON JWE est décrite dans la section 7.2.

5.2 Message Decryption (Déchiffrement de message)

Le processus de déchiffrement de message est l'inverse du processus de chiffrement. L'ordre des étapes n'est pas significatif dans les cas où il n'y a pas de dépendances entre les entrées et les sorties des étapes. Si l'une de ces étapes échoue, le contenu chiffré ne peut pas être validé.

Lorsqu'il y a plusieurs destinataires, c'est une décision d'application de savoir lequel des contenus chiffrés des destinataires doit être validé avec succès pour que le JWE soit accepté. Dans certains cas, le contenu chiffré pour tous les destinataires doit être validé avec succès ou le JWE sera considéré comme invalide. Dans d'autres cas, seul le contenu chiffré pour un seul destinataire doit être validé avec succès. Cependant, dans tous les cas, le contenu chiffré pour au moins un destinataire doit (MUST) être validé avec succès ou le JWE doit (MUST) être considéré comme invalide.

1. Analyser la représentation JWE pour extraire les valeurs sérialisées des composants JWE. Lors de l'utilisation de la sérialisation compacte JWE, ces composants sont les représentations encodées en base64url de l'en-tête protégé JWE, de la clé chiffrée JWE, du vecteur d'initialisation JWE, du texte chiffré JWE et du tag d'authentification JWE, et lors de l'utilisation de la sérialisation JSON JWE, ces composants incluent également la représentation encodée en base64url du JWE AAD et les valeurs non encodées de l'en-tête non protégé partagé JWE et de l'en-tête non protégé par destinataire JWE. Lors de l'utilisation de la sérialisation compacte JWE, l'en-tête protégé JWE, la clé chiffrée JWE, le vecteur d'initialisation JWE, le texte chiffré JWE et le tag d'authentification JWE sont représentés comme des valeurs encodées en base64url dans cet ordre, chaque valeur étant séparée de la suivante par un seul caractère point ('.'), ce qui donne exactement quatre caractères point de délimitation utilisés. La sérialisation JSON JWE est décrite dans la section 7.2.

2. Décoder en base64url les représentations encodées de l'en-tête protégé JWE, de la clé chiffrée JWE, du vecteur d'initialisation JWE, du texte chiffré JWE, du tag d'authentification JWE et du JWE AAD, en suivant la restriction selon laquelle aucun saut de ligne, espace blanc ou autre caractère supplémentaire n'a été utilisé.

3. Vérifier que la séquence d'octets résultant du décodage de l'en-tête protégé JWE encodé est une représentation encodée en UTF-8 d'un objet JSON complètement valide conforme à RFC 7159 [RFC7159]; laisser l'en-tête protégé JWE être cet objet JSON.

4. Si la sérialisation compacte JWE est utilisée, laisser l'en-tête JOSE être l'en-tête protégé JWE. Sinon, lors de l'utilisation de la sérialisation JSON JWE, laisser l'en-tête JOSE être l'union des membres de l'en-tête protégé JWE, de l'en-tête non protégé partagé JWE et de l'en-tête non protégé par destinataire JWE correspondant, qui doivent tous être des objets JSON complètement valides. Pendant cette étape, vérifier que l'en-tête JOSE résultant ne contient pas de noms de paramètres d'en-tête en double. Lors de l'utilisation de la sérialisation JSON JWE, cette restriction inclut que le même nom de paramètre d'en-tête ne doit pas (MUST NOT) non plus apparaître dans des valeurs d'objet JSON distinctes qui constituent ensemble l'en-tête JOSE.

5. Vérifier que l'implémentation comprend et peut traiter tous les champs qu'elle est tenue de prendre en charge, qu'ils soient requis par cette spécification, par l'algorithme utilisé ou par la valeur du paramètre d'en-tête "crit", et que les valeurs de ces paramètres sont également comprises et prises en charge.

6. Déterminer le mode de gestion des clés employé par l'algorithme spécifié par le paramètre d'en-tête "alg" (algorithm, algorithme).

7. Vérifier que le JWE utilise une clé connue du destinataire.

8. Lorsque l'accord de clé direct ou l'accord de clé avec enveloppement de clé sont employés, utiliser l'algorithme d'accord de clé pour calculer la valeur de la clé convenue. Lorsque l'accord de clé direct est employé, laisser la CEK être la clé convenue. Lorsque l'accord de clé avec enveloppement de clé est employé, la clé convenue sera utilisée pour déchiffrer la clé chiffrée JWE.

9. Lorsque l'enveloppement de clé, le chiffrement de clé ou l'accord de clé avec enveloppement de clé sont employés, déchiffrer la clé chiffrée JWE pour produire la CEK. La CEK doit (MUST) avoir une longueur égale à celle requise pour l'algorithme de chiffrement de contenu. Notez que lorsqu'il y a plusieurs destinataires, chaque destinataire ne pourra déchiffrer que les valeurs de clé chiffrée JWE qui ont été chiffrées pour les clés en possession de ce destinataire. Il est donc normal de ne pouvoir déchiffrer qu'une seule des valeurs de clé chiffrée JWE par destinataire pour obtenir la valeur CEK. Voir également la section 11.5 pour les considérations de sécurité sur l'atténuation des attaques temporelles.

10. Lorsque l'accord de clé direct ou le chiffrement direct sont employés, vérifier que la valeur de clé chiffrée JWE est une séquence d'octets vide.

11. Lorsque le chiffrement direct est employé, laisser la CEK être la clé symétrique partagée.

12. Enregistrer si la CEK a pu être déterminée avec succès pour ce destinataire.

13. Si la sérialisation JSON JWE est utilisée, répéter ce processus (étapes 4-12) pour chaque destinataire contenu dans la représentation.

14. Calculer la valeur d'en-tête protégé encodée BASE64URL(UTF8(JWE Protected Header)). Si l'en-tête protégé JWE n'est pas présent (ce qui ne peut se produire que lors de l'utilisation de la sérialisation JSON JWE et qu'aucun membre "protected" n'est présent), laisser cette valeur être la chaîne vide.

15. Laisser le paramètre de chiffrement de données authentifiées supplémentaires être ASCII(Encoded Protected Header). Cependant, si une valeur JWE AAD est présente (ce qui ne peut être le cas que lors de l'utilisation de la sérialisation JSON JWE), laisser plutôt le paramètre de chiffrement de données authentifiées supplémentaires être ASCII(Encoded Protected Header || '.' || BASE64URL(JWE AAD)).

16. Déchiffrer le texte chiffré JWE en utilisant la CEK, le vecteur d'initialisation JWE, la valeur de données authentifiées supplémentaires et le tag d'authentification JWE (qui est l'entrée du tag d'authentification pour le calcul) en utilisant l'algorithme de chiffrement de contenu spécifié, retournant le texte en clair déchiffré et validant le tag d'authentification JWE de la manière spécifiée pour l'algorithme, rejetant l'entrée sans émettre de sortie déchiffrée si le tag d'authentification JWE est incorrect.

17. Si un paramètre "zip" est inclus, décompresser le texte en clair déchiffré en utilisant l'algorithme de compression spécifié.

18. S'il n'y a pas de destinataires pour lesquels toutes les étapes de déchiffrement ont réussi, alors le JWE doit (MUST) être considéré comme invalide. Sinon, afficher le texte en clair. Dans le cas de la sérialisation JSON JWE, retourner également un résultat à l'application indiquant pour lequel des destinataires le déchiffrement a réussi et échoué.

Enfin, notez que c'est une décision d'application de savoir quels algorithmes peuvent être utilisés dans un contexte donné. Même si un JWE peut être déchiffré avec succès, à moins que les algorithmes utilisés dans le JWE soient acceptables pour l'application, elle devrait (SHOULD) considérer le JWE comme invalide.

5.3 String Comparison Rules (Règles de comparaison de chaînes)

Les règles de comparaison de chaînes pour cette spécification sont les mêmes que celles définies dans la section 5.3 de [JWS].