JOSE-Algorithmen: alg- und enc-Werte für JWS und JWE

EdDSA

Die polymorphe EdDSA-Kennung aus RFC 8037, von RFC 9864 zugunsten von Ed25519 und Ed448 als veraltet markiert.

Bei „EdDSA“ ergibt sich die Kurve aus dem Schlüssel (crv: Ed25519 oder Ed448), sodass eine Partei nicht ankündigen kann, welche Kurve sie unterstützt. RFC 9864 registriert die vollständig spezifizierten Namen Ed25519 und Ed448 und kennzeichnet „EdDSA“ als „Deprecated“.

ES256

ECDSA auf P-256 mit SHA-256, der JWS-Algorithmus, der für signierte JWTs mit asymmetrischen Schlüsseln am häufigsten verwendet wird.

Eine JWS-Signatur mit ES256 ist die 64 Byte lange Verkettung von r und s, jeweils auf 32 Byte aufgefüllt (RFC 7518 §3.4), nicht die DER-Struktur, die OpenSSL und Java erzeugen; die Umwandlung zwischen beiden ist eine häufige Ursache von Fehlern wie „invalid signature“ – siehe den Konverter DER ⇄ Raw.

RFC 9864 markiert die polymorphe COSE-Kennung ES256 (−7) zugunsten des vollständig spezifizierten ESP256 (−9) als veraltet; in JOSE legt der Name ES256 die Kurve bereits fest, daher ist er nicht betroffen.

HS256

HMAC mit SHA-256, ein symmetrischer JWS-Algorithmus: Wer ein Token prüfen kann, kann auch eines fälschen.

HS256 ist der einzige Algorithmus, den RFC 7518 als verpflichtend festlegt. Weil dasselbe Secret signiert und prüft, eignet er sich für einen einzelnen Dienst, der seine eigenen Tokens ausstellt und prüft. Ein kurzes oder erratbares Secret lässt sich aus jedem beliebigen Token offline per Brute Force ermitteln; RFC 7518 §3.2 verlangt einen Schlüssel, der mindestens so lang ist wie die Ausgabe der Hashfunktion – 256 Bit für HS256 –, und er muss zufällig sein.

ML-DSA-65

ML-DSA-65 (FIPS 204) für JWS, registriert durch RFC 9964 zusammen mit dem neuen Schlüsseltyp AKP.

Post-Quanten-Schlüssel für JWS verwenden den Schlüsseltyp Algorithm Key Pair (kty „AKP“), dessen Parameter „pub“ den rohen öffentlichen Schlüssel von ML-DSA enthält und dessen „alg“ ihn an einen Parametersatz bindet. Signaturen sind 3.309 Byte groß, Tokens werden dadurch mehrere Kilobyte lang.

none

alg „none“ kennzeichnet ein ungesichertes JWS – ein Token ganz ohne Signatur.

RFC 7518 §3.6 definiert „none“ für Kontexte, in denen die Integrität auf anderem Weg gewährleistet ist. Bibliotheken, die den Header des Tokens selbst den Algorithmus wählen lassen, haben gefälschte Tokens mit alg „none“ akzeptiert – die bekannteste Schwachstelle von JWT (RFC 8725 §2.1); Verifizierer müssen den Wert ablehnen, sofern die Anwendung nicht ausdrücklich ungesicherte Tokens erwartet.

RS256

RSASSA-PKCS1-v1_5 mit SHA-256, der JWS-Algorithmus der meisten ID-Tokens von OpenID Connect.

OpenID Connect Core §15.1 verlangt, dass Provider das Signieren von ID-Tokens mit RS256 unterstützen; deshalb verwenden die meisten ID-Tokens und JWKS-Endpunkte RSA-Schlüssel. Die klassische Falle bei RS256 ist Algorithm Confusion: Ein Verifizierer, der HS256 für einen Schlüssel akzeptiert, der für RS256 gedacht ist, lässt sich dazu bringen, den öffentlichen Schlüssel als HMAC-Secret zu verwenden (RFC 8725 §2.1). Lege den erwarteten Algorithmus pro Schlüssel fest, wie es RFC 8725 §3.1 verlangt.

RSA1_5

Schlüsselverschlüsselung mit RSAES-PKCS1-v1_5 für JWE, anfällig für Padding-Oracle-Angriffe nach Bleichenbacher.

Ein Server, der auf irgendeine Weise – durch eine Fehlermeldung oder durch Antwortzeiten – verrät, ob das Padding eines entschlüsselten RSA1_5-Schlüssels gültig war, ermöglicht es einem Angreifer, Inhaltsschlüssel Anfrage für Anfrage zu entschlüsseln. RFC 7518 kennzeichnet RSA1_5 als „Recommended-“, also als Kandidaten für eine Herabstufung; verwende besser RSA-OAEP-256 oder ECDH-ES.