9. Security Considerations (Considérations de sécurité)
Toutes les considérations de sécurité liées à la gestion des clés s'appliquent à cette spécification. En particulier, la provenance (Provenance) et la confiance (Trust) des clés sont essentielles pour les applications sécurisées.
9.1. Key Provenance and Trust (Provenance et confiance des clés)
Les JWK eux-mêmes ne fournissent aucun mécanisme pour les informations de provenance sur les clés. Les applications doivent s'assurer qu'elles font confiance à la provenance des clés par des moyens spécifiques à l'application. Les applications utilisant des JWK peuvent choisir d'utiliser des certificats X.509 [RFC5280] pour transmettre des informations de provenance et de confiance sur les clés. Les applications utilisant les paramètres « x5u » (X.509 URL), « x5c » (X.509 Certificate Chain), « x5t » (X.509 Certificate SHA-1 Thumbprint) et « x5t#S256 » (X.509 Certificate SHA-256 Thumbprint) devraient (SHOULD) traiter les certificats et utiliser les revendications (Claims) dans les certificats lors de la décision de faire confiance aux clés.
Les considérations de sécurité de la section 12.3 de XML DSIG 2.0 [W3C.NOTE-xmldsig-core2-20130411] concernant la force d'une signature numérique dépendant de la force de tous les maillons de la chaîne de sécurité s'appliquent également à cette spécification.
Les exigences TLS de la section 8 de [JWS] s'appliquent également à cette spécification, à la fois lorsque les JWK sont utilisés dans des contextes JWS et JWE et lorsque le membre JWK « x5u » est utilisé.
9.2. Preventing Disclosure of Non-public Key Information (Prévention de la divulgation d'informations de clés non publiques)
Les clés privées (Private Keys) et les clés symétriques (Symmetric Keys) doivent (MUST) être protégées contre la divulgation à des parties non intentionnelles. Un moyen recommandé de le faire est de chiffrer les JWK ou les JWK Sets les contenant en utilisant une valeur JWK ou JWK Set comme texte en clair d'un JWE. Bien entendu, cela suppose qu'il existe un moyen sûr d'obtenir la clé pour chiffrer les informations de clé non publiques à la partie prévue et que cette partie dispose d'un moyen sûr d'obtenir la clé de déchiffrement correspondante.
Les considérations de sécurité de RFC 3447 [RFC3447] et RFC 6030 [RFC6030] concernant la protection des clés privées et symétriques, l'utilisation des clés et la fuite d'informations s'appliquent également à cette spécification.
9.3. RSA Private Key Representations and Blinding (Représentations de clés privées RSA et masquage)
L'opération de masquage de clé RSA (RSA Key Blinding Operation) [Kocher] est une défense contre certaines attaques temporelles (Timing Attacks) [Kocher] et nécessite toutes les valeurs de clé RSA « n », « e » et « d ». Cependant, certaines représentations de clés privées RSA n'incluent pas l'exposant public « e », mais incluent seulement le module « n » et l'exposant privé « d ». C'est le cas, par exemple, de l'API Java RSAPrivateKeySpec, qui n'inclut pas l'exposant public « e » comme paramètre. Pour activer le masquage de clé RSA, de telles représentations devraient (SHOULD) être évitées. Pour Java, l'API RSAPrivateCrtKeySpec peut être utilisée à la place. La section 8.2.2(i) du « Handbook of Applied Cryptography » [HAC] explique comment calculer les paramètres de clé privée RSA restants, si nécessaire, en utilisant uniquement « n », « e » et « d ».
9.4. Key Entropy and Random Values (Entropie des clés et valeurs aléatoires)
Voir la section 10.1 de [JWS] pour les considérations de sécurité sur l'entropie des clés et les valeurs aléatoires.