Algorithmes JOSE : valeurs alg et enc pour JWS et JWE

EdDSA

L’identifiant polymorphe EdDSA de la RFC 8037, déconseillé par la RFC 9864 au profit d’Ed25519 et d’Ed448.

Avec « EdDSA », la courbe vient de la clé (crv: Ed25519 ou Ed448), si bien qu’une partie ne peut pas annoncer quelle courbe elle prend en charge. La RFC 9864 enregistre les noms entièrement spécifiés Ed25519 et Ed448 et classe « EdDSA » comme déconseillé.

ES256

ECDSA sur P-256 avec SHA-256, l’algorithme JWS le plus utilisé pour les JWT signés avec des clés asymétriques.

Une signature JWS en ES256 est la concaténation de r et s sur 64 octets, chacun complété à 32 octets (RFC 7518 §3.4), et non la structure DER que produisent OpenSSL et Java ; la conversion entre les deux est une source fréquente d’erreurs « invalid signature » (voir le convertisseur DER ⇄ brut).

La RFC 9864 déconseille l’identifiant COSE polymorphe ES256 (−7) au profit de l’identifiant entièrement spécifié ESP256 (−9) ; en JOSE, le nom ES256 fixe déjà la courbe, il n’est donc pas concerné.

HS256

HMAC avec SHA-256, un algorithme JWS symétrique : quiconque peut vérifier un jeton peut aussi en forger un.

HS256 est le seul algorithme que la RFC 7518 rend obligatoire. Comme le même secret signe et vérifie, il convient à un service unique qui émet et contrôle ses propres jetons. Un secret court ou devinable peut être retrouvé par force brute hors ligne à partir de n’importe quel jeton ; la RFC 7518 §3.2 exige une clé au moins aussi longue que la sortie de la fonction de hachage (256 bits pour HS256), et cette clé doit être aléatoire.

ML-DSA-65

ML-DSA-65 (FIPS 204) pour JWS, enregistré par la RFC 9964 avec le nouveau type de clé AKP.

Les clés JWS post-quantiques utilisent le type de clé Algorithm Key Pair, ou paire de clés liée à un algorithme (kty « AKP »), dont le membre « pub » contient la clé publique ML-DSA brute et dont le membre « alg » la lie à un seul jeu de paramètres. Les signatures font 3309 octets, si bien que les jetons atteignent plusieurs kilo-octets.

none

alg « none » désigne un JWS non sécurisé, c’est-à-dire un jeton sans aucune signature.

La RFC 7518 §3.6 définit « none » pour les contextes où l’intégrité est assurée par d’autres moyens. Des bibliothèques qui laissent l’en-tête du jeton lui-même choisir l’algorithme ont accepté des jetons forgés avec alg « none », la vulnérabilité JWT la plus connue (RFC 8725 §2.1) ; les vérificateurs doivent le rejeter, sauf si l’application attend explicitement des jetons non sécurisés.

RS256

RSASSA-PKCS1-v1_5 avec SHA-256, l’algorithme JWS de la plupart des jetons d’ID OpenID Connect.

OpenID Connect Core §15.1 impose aux fournisseurs de prendre en charge la signature des jetons d’ID en RS256, ce qui explique que la plupart des jetons d’ID et des points de terminaison JWKS utilisent des clés RSA. Son piège classique est la confusion d’algorithme : un vérificateur qui accepte HS256 pour une clé destinée à RS256 peut être amené à utiliser la clé publique comme secret HMAC (RFC 8725 §2.1). Fixez l’algorithme attendu pour chaque clé, comme l’exige la RFC 8725 §3.1.

RSA1_5

Chiffrement de clé RSAES-PKCS1-v1_5 pour JWE, exposé aux attaques par oracle de remplissage de type Bleichenbacher.

Un serveur qui révèle de quelque manière que ce soit (message d’erreur, temps de réponse) si le remplissage d’une clé RSA1_5 déchiffrée était valide permet à un attaquant de déchiffrer les clés de contenu une requête après l’autre. La RFC 7518 classe RSA1_5 « Recommended- », c’est-à-dire susceptible d’être rétrogradé ; préférez RSA-OAEP-256 ou ECDH-ES.