Aller au contenu

Horodatages (RFC 3161)

POST https://api.kennmarq.com/v1/tsa/{key}

Notre propre serveur d’horodatage RFC 3161, pour le mode local : quand votre machine signe un manifeste C2PA, elle demande à cette URL d’horodater la signature. La clé figure dans l’URL parce que la bibliothèque C2PA ne peut pas ajouter d’en-têtes.

Une clé limitée à tsa

Créez une clé dont la seule portée est tsa et placez-la dans l’URL. Toute clé ayant d’autres portées est refusée ici avec 403 key_not_allowed_in_url : les URL finissent dans des journaux, et une clé puissante ne doit jamais s’y trouver. Si cela arrive, remplacez la clé que vous avez envoyée.

URL d’horodatage
https://api.kennmarq.com/v1/tsa/sk_live_…

Requête

  • Content-Type: application/timestamp-query
  • Le corps : un TimeStampReq encodé en DER, de 4 Ko au plus.
  • Empreintes de message en SHA-256, SHA-384 ou SHA-512. Une empreinte SHA-1 reçoit un statut de rejet dans la réponse.
  • certReq est pris en compte (notre chaîne TSA est incluse dans le jeton) et votre nonce est renvoyé à l’identique.

Réponse

200 avec exactement Content-Type: application/timestamp-reply, et le TimeStampResp DER comme corps, octet pour octet tel que notre serveur l’a produit. Chaque jeton indique une précision de 1 seconde, porte un numéro de série aléatoire de 128 bits et notre propre OID de politique, et est signé en ECDSA P-256 / SHA-256 avec signingCertificateV2 (RFC 5816).

Chaque jeton est inscrit dans notre journal de transparence public avant d’être renvoyé ; l’en-tête X-Log-Index indique à quelle position, et GET /v1/log/proof/{index} le prouve. Un rejet ne porte ni jeton ni index.

Exemple avec OpenSSL

Shell
# A query for a file's SHA-256, asking for our certificate in the reply
openssl ts -query -data artwork.png -sha256 -cert -out request.tsq

curl https://api.kennmarq.com/v1/tsa/$TSA_KEY \
  -H "Content-Type: application/timestamp-query" \
  --data-binary @request.tsq \
  -o response.tsr

openssl ts -reply -in response.tsr -text

Pour vérifier un jeton, récupérez notre chaîne TSA avec GET /v1/certificate?chain=tsa.

Décompte

Chaque horodatage compte une fois dans le quota mensuel d’horodatages, de même taille que les marquages de votre offre (et que vos marquages de test pour les clés de test), tenu séparément pour les clés de production et de test. Une requête qui échoue de notre côté n’est pas décomptée. Les appels par minute de l’offre s’appliquent à l’organisation, toutes ses clés confondues ; la liste d’IP autorisées d’une clé s’applique à cette clé.

Les validateurs C2PA signalent nos horodatages comme timeStamp.untrusted tant que notre certificat reconnu publiquement n’est pas en place ; le fichier reste néanmoins valide.

Erreurs

Erreurs de POST /v1/tsa
StatutCodeQuand
400invalid_requestUn corps vide, ou une requête que notre serveur n’a pas pu analyser.
401missing_api_key, invalid_api_key, api_key_revokedAucune clé, une clé inconnue ou une clé révoquée.
402quota_exceededLes horodatages du mois sont épuisés.
403key_not_allowed_in_urlLa clé a d’autres portées que tsa.
403ip_not_allowedL’adresse ne figure pas sur la liste d’IP autorisées de la clé.
413payload_too_largeLa requête dépasse 4 Ko.
415unsupported_media_typeLe Content-Type n’est pas application/timestamp-query.
429rate_limitedTrop d’appels cette minute.
503tsa_unavailableLe serveur d’horodatage est momentanément indisponible. Rien n’est décompté ; réessayez.