Certificat DAT ​

1. Présentation ​

Le certificat DAT est la spécification qui contrôle les droits d'émission des DAT et qui gère les algorithmes de signature et de chiffrement du token ainsi que les informations de clé (Key).

Chaque certificat possède un identifiant unique (CID) et assure une gestion sécurisée du cycle de vie des tokens en imposant la période d'émission autorisée des DAT ainsi que la durée de validité (TTL) des tokens générés.

Dans DAT, la rotation des clés n'est pas optionnelle. La période d'émission autorisée étant inscrite dans le certificat au niveau de la spécification, une fois cette période écoulée il devient impossible de créer de nouveaux tokens avec ce certificat.

2. Structure du certificat ​

cid . start . duration . ttl . sig-alg . crypto-alg . sig-key . crypto-key

2.1. Spécification détaillée par champ ​

CID : Hex (uint64)

• Identifiant unique permettant d'identifier le certificat. Il est mis en correspondance avec le champ CID du DAT afin de déterminer quel certificat utiliser lors de la vérification.
• Le CID est un identifiant immuable. Lors d'un renouvellement de clé, on ne réutilise pas le même CID : un certificat est émis avec un nouveau CID.

Heure de début d'émission du DAT : uint64 (Unix Time)

• Représente l'heure de début à partir de laquelle ce certificat peut être utilisé pour émettre des DAT, exprimée en secondes (Seconds).

Durée d'émission du DAT : uint64 (Seconds)

• La durée de validité d'émission du certificat. Une fois cette durée (en secondes) écoulée depuis Heure de début d'émission du DAT, il n'est plus possible d'émettre de nouveaux DAT avec ce certificat.
• Il s'agit d'une durée (duration), et non d'une date absolue. La date de fin se calcule par start + duration.

DAT TTL (Durée de vie) : uint64 (Seconds)

• La durée de validité (Time To Live) des DAT émis avec ce certificat. Lors de la création d'un DAT, la valeur expire est définie en ajoutant cette valeur à l'heure d'émission.

Algorithme de signature : String / Enum

• L'algorithme de signature à utiliser pour générer et vérifier le champ signature du DAT.

Algorithme de chiffrement : String / Enum

• L'algorithme de chiffrement à utiliser pour chiffrer et déchiffrer le champ secure du DAT.

Clé de signature : Base64Url (Binary)

• Les données de clé utilisées pour la signature et la vérification. (Selon l'algorithme, il peut s'agir de la clé publique/privée d'une paire asymétrique ou d'une clé symétrique.)

Clé de chiffrement : Base64Url (Binary)

• Les données de clé de chiffrement utilisées pour le chiffrement et le déchiffrement du champ secure.

2.2. Calcul des temps ​

end    = start + duration        fin de la fenêtre d'émission
expire = end + ttl               expiration finale du certificat

• Tous les calculs sont effectués en uint64 et seul le dépassement de capacité (overflow) est rejeté comme erreur.
• duration = 0 et ttl = 0 sont des valeurs légitimes. Elles permettent d'exprimer un certificat dont la fenêtre d'émission se referme immédiatement, ou un certificat produisant des tokens invalides dès leur émission.
• Tous les champs étant des entiers non signés, les valeurs négatives n'existent pas au niveau du type.

2.3. Signature du constructeur ​

Toutes les implémentations, quel que soit le langage, utilisent l'ordre d'arguments suivant.

(cid, dat_issuance_start_seconds, dat_issuance_duration_seconds, dat_ttl_seconds,
 signature_key, crypto_key)

3. Cycle de vie du certificat ​

• La possibilité d'émettre est déterminée par signable() && start <= now <= end, bornes incluses.
• Même après la fermeture de la fenêtre d'émission, le certificat reste en vie pendant la durée ttl supplémentaire. Il faut en effet qu'un token émis juste avant la fermeture puisse aller au bout de sa durée de vie.
• La phase de délai d'émission (delay) sert à laisser à tous les nœuds du cluster le temps de récupérer le nouveau certificat. Pour plus de détails, consultez le document Synchronisation CMS.

4. Algorithmes ​

4.1. Algorithmes de signature ​

Liste des algorithmes de signature protégeant les DAT contre la falsification et la modification. Les méthodes à clé symétrique et à clé asymétrique sont prises en charge.

MFS (Maximum Fixed Secret) : méthode utilisant une clé secrète de taille fixe dont le nombre de bits est identique à la taille de sortie (Output) de l'algorithme de hachage.

4.2. Algorithmes de chiffrement ​

Liste des algorithmes de chiffrement authentifié (Authenticated Encryption) protégeant les données confidentielles internes au DAT (champ secure).

Intégration de l'IV (Initialization Vector) : un NONCE (IV) unique de 96 bits, généré à chaque chiffrement, est concaténé en préfixe (Prefix) devant le résultat du chiffrement. Lors du déchiffrement, les 96 premiers bits sont extraits en tant qu'IV pour effectuer le déchiffrement.

4.3. Validation de la longueur de clé ​

Lors de l'importation d'un certificat, la correspondance entre le nombre de bits de l'algorithme déclaré et la longueur réelle de la clé est vérifiée.

Par exemple, si un certificat déclarant IV-AES256-GCM contient une clé de 16 octets, l'importation elle-même est refusée. Sans ce contrôle, on croirait utiliser AES-256 alors que le système fonctionnerait en réalité en AES-128.

5. Export verify-only ​

Il n'est pas nécessaire de confier la clé privée de signature aux serveurs qui se contentent de vérifier. Le certificat DAT propose pour cela un export verify-only.

HMAC étant à clé symétrique, la notion de « clé permettant uniquement de vérifier » n'existe pas. C'est pourquoi une tentative d'export verify-only n'est pas silencieusement ignorée : elle est signalée immédiatement par une erreur. Comme un export verify-only échoue dès qu'un certificat HMAC est présent dans le lot, il faut utiliser la famille ECDSA si vous exploitez des nœuds dédiés à la vérification.