9. Security Considerations (Considerazioni sulla sicurezza)
Tutte le considerazioni sulla sicurezza relative alla gestione delle chiavi si applicano a questa specifica. In particolare, la provenienza (Provenance) e la fiducia (Trust) delle chiavi sono fondamentali per applicazioni sicure.
9.1. Key Provenance and Trust (Provenienza e fiducia delle chiavi)
I JWK stessi non forniscono alcun meccanismo per informazioni sulla provenienza delle chiavi. Le applicazioni devono garantire di fidarsi della provenienza delle chiavi con mezzi specifici dell'applicazione. Le applicazioni che utilizzano JWK possono scegliere di utilizzare certificati X.509 [RFC5280] per trasmettere informazioni sulla provenienza e sulla fiducia delle chiavi. Le applicazioni che utilizzano i parametri « x5u » (X.509 URL), « x5c » (X.509 Certificate Chain), « x5t » (X.509 Certificate SHA-1 Thumbprint) e « x5t#S256 » (X.509 Certificate SHA-256 Thumbprint) dovrebbero (SHOULD) elaborare i certificati e utilizzare le rivendicazioni (Claims) nei certificati quando decidono se fidarsi delle chiavi.
Le considerazioni sulla sicurezza nella sezione 12.3 di XML DSIG 2.0 [W3C.NOTE-xmldsig-core2-20130411] sulla forza di una firma digitale che dipende dalla forza di tutti gli anelli della catena di sicurezza si applicano anche a questa specifica.
I requisiti TLS nella sezione 8 di [JWS] si applicano anche a questa specifica, sia quando i JWK sono utilizzati in contesti JWS e JWE sia quando viene utilizzato il membro JWK « x5u ».
9.2. Preventing Disclosure of Non-public Key Information (Prevenzione della divulgazione di informazioni su chiavi non pubbliche)
Le chiavi private (Private Keys) e le chiavi simmetriche (Symmetric Keys) devono (MUST) essere protette dalla divulgazione a parti non intenzionali. Un mezzo raccomandato per farlo è crittografare i JWK o i JWK Set che li contengono utilizzando un valore JWK o JWK Set come testo in chiaro di un JWE. Naturalmente, ciò presuppone che esista un modo sicuro per ottenere la chiave per crittografare le informazioni sulla chiave non pubblica alla parte prevista e che tale parte abbia un modo sicuro per ottenere la chiave di decrittografia corrispondente.
Le considerazioni sulla sicurezza in RFC 3447 [RFC3447] e RFC 6030 [RFC6030] sulla protezione delle chiavi private e simmetriche, sull'uso delle chiavi e sulla perdita di informazioni si applicano anche a questa specifica.
9.3. RSA Private Key Representations and Blinding (Rappresentazioni di chiavi private RSA e blinding)
L'operazione di blinding della chiave RSA (RSA Key Blinding Operation) [Kocher] è una difesa contro alcuni attacchi temporali (Timing Attacks) [Kocher] e richiede tutti i valori di chiave RSA « n », « e » e « d ». Tuttavia, alcune rappresentazioni di chiavi private RSA non includono l'esponente pubblico « e », ma includono solo il modulo « n » e l'esponente privato « d ». Questo è il caso, ad esempio, dell'API Java RSAPrivateKeySpec, che non include l'esponente pubblico « e » come parametro. Per abilitare il blinding della chiave RSA, tali rappresentazioni dovrebbero (SHOULD) essere evitate. Per Java, può essere utilizzata invece l'API RSAPrivateCrtKeySpec. La sezione 8.2.2(i) del « Handbook of Applied Cryptography » [HAC] discute come calcolare i parametri di chiave privata RSA rimanenti, se necessario, utilizzando solo « n », « e » e « d ».
9.4. Key Entropy and Random Values (Entropia delle chiavi e valori casuali)
Vedere la sezione 10.1 di [JWS] per considerazioni sulla sicurezza sull'entropia delle chiavi e sui valori casuali.