6.2. Registre des algorithmes de signature HTTP

6.2. Registre des algorithmes de signature HTTP

Le présent document définit des algorithmes de signature HTTP, pour lesquels IANA a créé et maintient désormais un nouveau registre intitulé « HTTP Signature Algorithms ». Les valeurs initiales de ce registre sont données à la Section 6.2.2. Les attributions futures et les modifications des attributions existantes se font selon la politique d'enregistrement Specification Required [RFC8126].

Les algorithmes listés dans ce registre identifient certaines possibilités d'algorithmes cryptographiques pour les applications utilisant la présente spécification, mais les entrées ne constituent ni une liste exhaustive d'algorithmes possibles ni une indication d'adéquation à un usage particulier de la spécification. Une application est libre d'implémenter tout algorithme qui convient à ses besoins, pour autant que le signataire et le vérificateur puissent convenir des paramètres de cet algorithme de façon sécurisée et déterministe. Lorsqu'une application doit signaler l'utilisation d'un algorithme particulier à l'exécution au moyen du paramètre de signature alg, ce registre fournit une correspondance entre la valeur de ce paramètre et un algorithme particulier. Toutefois, l'utilisation du paramètre alg doit être traitée avec prudence pour éviter diverses formes de confusion et de substitution d'algorithmes, comme discuté à la Section 7.

La valeur Status devrait refléter le statut de normalisation et l'opinion générale des groupes d'intérêt pertinents tels que l'IETF ou les organisations de normalisation liées à la sécurité (SDO). Lorsqu'un algorithme est d'abord enregistré, l'expert désigné (DE) devrait régler le champ Status sur « Active » s'il existe un consensus pour recommander généralement l'algorithme comme sûr, ou sur « Provisional » si l'algorithme n'a pas atteint ce consensus, par exemple pour un algorithme expérimental. Un statut « Provisional » ne signifie pas que l'algorithme est connu comme non sûr, mais indique plutôt que l'algorithme n'a pas atteint de consensus quant à ses propriétés. Si, ultérieurement, l'algorithme tel qu'enregistré s'avère présenter des défauts, l'entrée du registre peut être mise à jour et l'algorithme peut être marqué « Deprecated » pour indiquer que l'algorithme a été jugé problématique. Ce statut n'empêche pas une application d'utiliser un algorithme particulier ; il sert plutôt d'avertissement sur d'éventuels problèmes connus avec un algorithme que l'application doit prendre en compte. Le DE peut en outre veiller à ce que l'enregistrement inclue une explication et une référence pour la valeur Status ; cela est particulièrement important pour les algorithmes dépréciés.

On attend du DE qu'il fasse ce qui suit :

• S'assurer que les algorithmes référencés par un identifiant d'algorithme enregistré sont entièrement définis avec tous les paramètres (par ex. sel, hachage, longueur de clé requise) fixés par le texte normatif.

• S'assurer que la définition de l'algorithme spécifie entièrement les fonctions primitives HTTP_SIGN et HTTP_VERIFY, y compris comment toutes les entrées et sorties définies se mappent à l'algorithme cryptographique sous-jacent.

• Rejeter tout enregistrement qui est un alias d'enregistrements existants.

• S'assurer que tous les enregistrements suivent le modèle présenté à la Section 6.2.1 ; cela inclut de vérifier que la longueur du nom n'est pas excessive tout en restant unique et reconnaissable.

La présente spécification crée des identifiants d'algorithme en incluant les paramètres majeurs dans la chaîne d'identifiant afin de rendre le nom d'algorithme unique et reconnaissable par les développeurs. Toutefois, les identifiants d'algorithme dans ce registre doivent être interprétés comme des valeurs de chaîne entières et non comme une combinaison de parties. Autrement dit, on attend des implémentateurs qu'ils comprennent rsa-pss-sha512 comme se référant à un algorithme précis avec ses valeurs de hachage, masque et sel fixées comme défini dans le texte normatif qui établit l'identifiant en question. Les implémentateurs n'analysent pas les portions rsa, pss et sha512 de l'identifiant pour en déduire les paramètres de l'algorithme de signature à partir de la chaîne, et l'enregistrement d'une combinaison de paramètres n'implique pas l'enregistrement d'autres combinaisons.