9. Security Considerations

All security considerations related to key management apply to this specification. In particular, the provenance and trust of keys are critical for secure applications.

9.1. Key Provenance and Trust

JWKs themselves provide no mechanism for provenance information about keys. Applications need to ensure that they trust the provenance of keys by application-specific means. Applications using JWKs can choose to use X.509 certificates [RFC5280] to convey provenance and trust information about keys. Applications using the "x5u" (X.509 URL), "x5c" (X.509 Certificate Chain), "x5t" (X.509 Certificate SHA-1 Thumbprint), and "x5t#S256" (X.509 Certificate SHA-256 Thumbprint) parameters SHOULD process the certificates and use the claims in the certificates when deciding whether to trust keys.

The security considerations in Section 12.3 of XML DSIG 2.0 [W3C.NOTE-xmldsig-core2-20130411] about the strength of a digital signature being dependent upon the strength of all links in the security chain also apply to this specification.

The TLS requirements in Section 8 of [JWS] also apply to this specification, both when JWKs are used in JWS and JWE contexts and when the "x5u" JWK member is used.

9.2. Preventing Disclosure of Non-public Key Information

Private keys and symmetric keys MUST be prevented from disclosure to unintended parties. One recommended means of doing so is to encrypt JWKs or JWK Sets containing them by using a JWK or JWK Set value as the plaintext of a JWE. Of course, this presupposes that there is a secure way to obtain the key for encrypting the non-public key information to the intended party and that party has a secure way to obtain the corresponding decryption key.

The security considerations in RFC 3447 [RFC3447] and RFC 6030 [RFC6030] about protecting private and symmetric keys, key usage, and information leakage also apply to this specification.

9.3. RSA Private Key Representations and Blinding

The RSA Key Blinding operation [Kocher] is a defense against some timing attacks [Kocher] and requires all RSA key values "n", "e", and "d". However, some RSA private key representations do not include the public exponent "e", but only include the modulus "n" and the private exponent "d". This is the case, for instance, with the Java RSAPrivateKeySpec API, which does not include the public exponent "e" as a parameter. To enable RSA key blinding, such representations SHOULD be avoided. For Java, the RSAPrivateCrtKeySpec API can be used instead. Section 8.2.2(i) of the "Handbook of Applied Cryptography" [HAC] discusses how to compute the remaining RSA private key parameters, if needed, using only "n", "e", and "d".

9.4. Key Entropy and Random Values

See Section 10.1 of [JWS] for security considerations on key entropy and random values.