9. Security Considerations (Sicherheitsüberlegungen)
Alle Sicherheitsüberlegungen im Zusammenhang mit der Schlüsselverwaltung gelten für diese Spezifikation. Insbesondere sind die Herkunft (Provenance) und das Vertrauen (Trust) von Schlüsseln für sichere Anwendungen von entscheidender Bedeutung.
9.1. Key Provenance and Trust (Schlüsselherkunft und Vertrauen)
JWKs selbst bieten keinen Mechanismus für Herkunftsinformationen über Schlüssel. Anwendungen müssen sicherstellen, dass sie der Herkunft von Schlüsseln durch anwendungsspezifische Mittel vertrauen. Anwendungen, die JWKs verwenden, können wählen, X.509-Zertifikate [RFC5280] zu verwenden, um Herkunfts- und Vertrauensinformationen über Schlüssel zu übermitteln. Anwendungen, die die Parameter „x5u" (X.509 URL), „x5c" (X.509 Certificate Chain), „x5t" (X.509 Certificate SHA-1 Thumbprint) und „x5t#S256" (X.509 Certificate SHA-256 Thumbprint) verwenden, sollten (SHOULD) die Zertifikate verarbeiten und die Ansprüche (Claims) in den Zertifikaten verwenden, wenn sie entscheiden, ob sie Schlüsseln vertrauen.
Die Sicherheitsüberlegungen in Abschnitt 12.3 von XML DSIG 2.0 [W3C.NOTE-xmldsig-core2-20130411] über die Stärke einer digitalen Signatur, die von der Stärke aller Glieder in der Sicherheitskette abhängt, gelten auch für diese Spezifikation.
Die TLS-Anforderungen in Abschnitt 8 von [JWS] gelten auch für diese Spezifikation, sowohl wenn JWKs in JWS- und JWE-Kontexten verwendet werden als auch wenn das „x5u" JWK-Mitglied verwendet wird.
9.2. Preventing Disclosure of Non-public Key Information (Verhinderung der Offenlegung nicht-öffentlicher Schlüsselinformationen)
Private Schlüssel (Private Keys) und symmetrische Schlüssel (Symmetric Keys) müssen (MUST) vor Offenlegung gegenüber unbeabsichtigten Parteien geschützt werden. Ein empfohlenes Mittel dazu ist die Verschlüsselung von JWKs oder JWK Sets, die diese enthalten, indem ein JWK- oder JWK Set-Wert als Klartext eines JWE verwendet wird. Dies setzt natürlich voraus, dass es einen sicheren Weg gibt, den Schlüssel zum Verschlüsseln der nicht-öffentlichen Schlüsselinformationen an die beabsichtigte Partei zu erhalten, und dass diese Partei einen sicheren Weg hat, den entsprechenden Entschlüsselungsschlüssel zu erhalten.
Die Sicherheitsüberlegungen in RFC 3447 [RFC3447] und RFC 6030 [RFC6030] über den Schutz privater und symmetrischer Schlüssel, die Schlüsselverwendung und Informationslecks gelten auch für diese Spezifikation.
9.3. RSA Private Key Representations and Blinding (RSA-Privatschlüssel-Darstellungen und Blinding)
Die RSA Key Blinding Operation [Kocher] ist eine Verteidigung gegen einige Timing-Angriffe (Timing Attacks) [Kocher] und erfordert alle RSA-Schlüsselwerte „n", „e" und „d". Einige RSA-Privatschlüssel-Darstellungen enthalten jedoch nicht den öffentlichen Exponenten „e", sondern nur den Modulus „n" und den privaten Exponenten „d". Dies ist beispielsweise bei der Java RSAPrivateKeySpec API der Fall, die den öffentlichen Exponenten „e" nicht als Parameter enthält. Um RSA Key Blinding zu ermöglichen, sollten (SHOULD) solche Darstellungen vermieden werden. Für Java kann stattdessen die RSAPrivateCrtKeySpec API verwendet werden. Abschnitt 8.2.2(i) des „Handbook of Applied Cryptography" [HAC] diskutiert, wie die verbleibenden RSA-Privatschlüssel-Parameter bei Bedarf nur unter Verwendung von „n", „e" und „d" berechnet werden können.
9.4. Key Entropy and Random Values (Schlüsselentropie und Zufallswerte)
Siehe Abschnitt 10.1 von [JWS] für Sicherheitsüberlegungen zur Schlüsselentropie und Zufallswerten.