4.1. Ajouter une chaîne au journal

4.1. Ajouter une chaîne au journal

POST https://<log server>/ct/v1/add-chain

Entrées :

• chain : Un tableau de certificats encodés en base64. Le premier élément est le certificat d'entité finale ; le second se chaîne au premier et ainsi de suite jusqu'au dernier, qui est soit le certificat racine, soit un certificat qui se chaîne à un certificat racine connu.

Sorties :

• sct_version : La version de la structure SignedCertificateTimestamp, en décimal. Une implémentation v1 conforme NE DOIT PAS s'attendre à ce que cela soit 0 (c'est-à-dire, v1).

• id : L'ID du journal, encodé en base64. Puisque les clients de journal qui demandent un SCT pour inclusion dans les négociations TLS ne sont pas tenus de le vérifier, nous ne supposons pas qu'ils connaissent l'ID du journal.

• timestamp : L'horodatage SCT, en décimal.

• extensions : Un type opaque pour l'expansion future. Il est probable que tous les participants n'auront pas besoin de comprendre les données dans ce champ. Les journaux devraient définir cela comme une chaîne vide. Les clients devraient décoder les données encodées en base64 et les inclure dans le SCT.

• signature : La signature SCT, encodée en base64.

Si le "sct_version" n'est pas v1, alors un client v1 peut être incapable de vérifier la signature. Il NE DOIT PAS interpréter cela comme une erreur. (Note : Les clients de journal n'ont pas besoin de pouvoir vérifier cette structure ; seuls les clients TLS le font. Si nous devions servir la structure comme un blob binaire, alors nous pourrions complètement la changer sans nécessiter une mise à niveau vers les clients v1.)