3.1. Création d'une signature (Creating a Signature)

3.1. Création d'une signature

La création d'une signature de message HTTP est un processus dont l'entrée est le contexte de signature (y compris le message cible) et les exigences de l'application. La sortie est une valeur de signature et un ensemble de paramètres de signature communicables au vérificateur en les ajoutant au message.

Pour créer une signature, un signataire DOIT appliquer l'algorithme suivant:

1. Le signataire choisit un algorithme de signature HTTP et le matériel de clé pour signer parmi l'ensemble des algorithmes de signature possibles. Cet ensemble est déterminé par l'application et sort du périmètre de ce document. Le signataire DOIT choisir un matériel de clé adapté à l'algorithme de la signature et conforme aux exigences définies par l'algorithme, telles que la taille ou le format de clé. Le mécanisme par lequel le signataire choisit l'algorithme et le matériel de clé sort du périmètre de ce document.

2. Le signataire fixe l'heure de création de la signature à l'heure courante.

3. Le cas échéant, le signataire fixe la propriété d'heure d'expiration de la signature à l'instant où la signature doit expirer. L'expiration est une indication pour le vérificateur, exprimant l'instant à partir duquel le signataire ne cautionne plus la signature. Une durée d'expiration appropriée et les exigences de traitement de ce paramètre sont propres à l'application.

4. Le signataire crée un ensemble ordonné d'identifiants de composants représentant les composants de message à couvrir par la signature et attache des paramètres de métadonnées de signature à cet ensemble. La valeur sérialisée de cet ensemble sert ensuite de valeur du champ Signature-Input comme à la Section 4.1.

   • Une fois l'ordre des composants couverts choisi, il NE DOIT PAS changer pendant toute la durée de vie de la signature.

   • Chaque identifiant de composant couvert DOIT être soit (1) un champ HTTP (Section 2.1) dans le contexte de signature, soit (2) un composant dérivé énuméré à la Section 2.2 ou dans le registre « HTTP Signature Derived Component Names ».

   • Les signataires d'une requête DEVRAIENT inclure une partie ou la totalité des données de contrôle du message parmi les composants couverts, telles que @method, @authority, @target-uri, ou une combinaison de ceux-ci.

   • Les signataires DEVRAIENT inclure le paramètre de métadonnées created pour indiquer quand la signature a été créée.

   • L'identifiant de composant dérivé @signature-params NE DOIT PAS figurer dans la liste des identifiants de composants couverts. Ce composant dérivé est requis comme dernière ligne de la base de signature, garantissant qu'une signature couvre toujours ses propres métadonnées et que celles-ci ne peuvent être substituées.

   • Les conseils supplémentaires sur ce qu'inclure dans cet ensemble et dans quel ordre sortent du périmètre de ce document.

5. Le signataire crée la base de signature à partir de ces paramètres et de l'algorithme de création de la base de signature (Section 2.5).

6. Le signataire utilise la primitive HTTP_SIGN pour signer la base de signature avec l'algorithme de signature choisi et le matériel de clé choisi. La primitive HTTP_SIGN et plusieurs applications concrètes d'algorithmes de signature sont définies à la Section 3.3.

7. Le tableau d'octets en sortie de la fonction de signature est la valeur de sortie de la signature de message HTTP à inclure dans le champ Signature tel que défini à la Section 4.2.

Par exemple, étant donné le message HTTP et les paramètres de signature de l'exemple de la Section 2.5, la base d'exemple est signée avec la clé test-key-rsa-pss (voir Annexe B.1.2) et l'algorithme RSASSA-PSS décrit à la Section 3.3.1, ce qui donne la valeur de sortie de signature de message suivante, encodée en Base64:

NOTE: retour à la ligne '' selon la RFC 8792

HIbjHC5rS0BYaa9v4QfD4193TORw7u9edguPh0AW3dMq9WImrlFrCGUDih47vAxi4L2
YRZ3XMJc1uOKk/J0ZmZ+wcta4nKIgBkKq0rM9hs3CQyxXGxHLMCy8uqK488o+9jrptQ
+xFPHK7a9sRL1IXNaagCNN3ZxJsYapFj+JXbmaI5rtAdSfSvzPuBCh+ARHBmWuNo1Uz
VVdHXrl8ePL4cccqlazIJdC4QEjrF+Sn4IxBQzTZsL9y9TP5FsZYzHvDqbInkTNigBc
E9cKOYNFCn4D/WM7F6TNuZO9EgtzepLWcjTymlHzK7aXq6Am6sfOrpIC49yXjj3ae6H
RalVc/g==

       Figure 2: Exemple non normatif de valeur de signature

Notez que l'algorithme RSA-PSS utilisé ici est non déterministe: une valeur de signature différente est produite à chaque exécution. La valeur fournie ici peut être validée avec les clés données, mais les valeurs nouvellement générées ne sont pas censées correspondre à l'exemple. Voir Section 7.3.5.