Ubuntu Manpage: ts - Outil d’autorité d’horodatage (client et serveur)

Provided by: manpages-fr-extra_20151231_all

NOM

       ts - Outil d’autorité d’horodatage (client et serveur)

SYNOPSIS

       openssl ts -query [-rand fichier:fichier...] [-config fichier_conf] [-data
       fichier_à_hacher] [-digest octets_sign] [-md2|-md4|-md5|-sha|-sha1|-mdc2|-ripemd160|...]
       [-policy id_objet] [-no_nonce] [-cert] [-in demande.tsq] [-out demande.tsq] [-text]

       openssl ts -reply [-config fichier_conf] [section section_tsa] [-queryfile demande.tsq]
       [-passin src_mot_de_passe] [-signer tsa_cert.pem] [-inkey privée.pem] [-chain
       fichier_certs.pem] [-policy id_objet] [-in réponse.tsr] [-token_in] [-out response.tsr]
       [-token_out] [-text] [-engine id]

       openssl ts -verify [-data fichier_à_hacher] [-digest octets_sign] [-queryfile demande.tsq]
       [-in réponse.tsr] [-token_in] [-CApath chemin_cert_confiance] [-CAfile
       certs_confiance.pem] [-untrusted fichier_cert.pem]

DESCRIPTION

La commande ts est une application client et serveur d’autorité d’horodatage (« Time
Stamping Authority », TSA) conforme à la RFC 3161 (protocole d'horodatage, « Time-Stamp
Protocol » TSP). Une TSA peut faire partie d'un déploiement de PKI et son rôle est de
fournir des preuves à long terme de l'existence d'une certaine donnée avant un moment
donné. Voici une brève description du protocole.

1. Le client TSA calcule une valeur de hachage à sens unique pour un fichier de données
et envoie le hachage à la TSA.

2. La TSA attache la date et l'heure à la valeur de hachage reçue, les signe et envoie le
jeton d’horodatage au client. En créant ce jeton, la TSA certifie l'existence du
fichier original de données au moment où la réponse est créée.

3. Le client TSA reçoit le jeton d'horodatage et en vérifie la signature. Il vérifie
également si le jeton contient la même valeur de hachage qu'il avait envoyé à la TSA.

Une unité de données de protocole encodée DER est définie pour le transport d'une demande
d'horodatage à la TSA et une autre pour l'envoi de la réponse d'horodatage au client. La
commande ts a trois fonctions principales : créer une demande d'horodatage à partir d'un
fichier de données, créer une réponse d'horodatage à partir d'une demande et vérifier si
une réponse correspond à une demande particulière ou à un fichier de données.

Aucune prise en charge n’existe encore pour l’envoi de demandes et réponses
automatiquement par HTTP ou TCP comme suggéré dans la RFC 3161. Les utilisateurs doivent
envoyer les demandes par FTP ou courrier électronique.

OPTIONS

Création de demande d’horodatage
L’option -query peut être utilisée pour créer et afficher une demande d'horodatage avec
les options suivantes :

-rand fichier:fichier...
Les fichiers contenant des données aléatoires utilisées pour initialiser le générateur
de nombres pseudoaléatoires. Plusieurs fichiers peuvent être indiqués en utilisant le
séparateur du système d'exploitation : « ; » pour Windows, « , » pour OpenVMS et « : »
pour tous les autres. (Facultatif)

-config fichier_conf
Le fichier de configuration à utiliser, cette option remplace la variable
d'environnement OPENSSL_CONF. Seule la section OID du fichier de configuration est
utilisée avec la commande -query. (Facultatif)

-data fichier_à_hacher
Le fichier de données pour lequel la demande d'horodatage doit être créée. L’entrée
standard est la valeur par défaut si aucune des options -data ou -digest n’est
indiquée. (Facultatif)

-digest octets_sign
Indiquer explicitement l’empreinte du message est possible sans le fichier de données.
L’empreinte doit être indiquée au format hexadécimal, deux caractères par octet, les
octets éventuellement séparés par des deux-points (par exemple 1A:F6:01:... ou
1AF601...). Le nombre d’octets doit correspondre à l’algorithme de signature de
message utilisé. (Facultatif)

-md2|-md4|-md5|-sha|-sha1|-mdc2|-ripemd160|...
La signature de message à appliquer au fichier de données, tous les algorithmes de
signature de message pris en charge par la commande openssl dgst sont utilisables. La
valeur par défaut est SHA-1. (Facultatif)

policy id_objet
La politique attendue par le client de la TSA à utiliser pour créer le jeton
d'horodatage. Soit la notation OID avec points, soit les noms d’OID définis dans le
fichier de configuration peuvent être utilisés. Si aucune politique n’est demandée, la
TSA utilisera sa propre politique par défaut. (Facultatif)

-no_nonce
Aucun nonce n’est indiqué dans la demande si cette option est donnée. Sinon, un nonce
pseudoaléatoire de 64 bits est inclus dans la demande. Utiliser nonce est recommandé
pour se protéger contre les attaques par rejeu. (Facultatif)

-cert
La TSA devrait inclure son certificat de signature dans la réponse. (Facultatif)

-in demande.tsq
Cette option indique une demande d'horodatage précédemment créée au format DER qui
sera envoyée dans le fichier de sortie. Utile pour examiner le contenu d'une demande
au format lisible. (Facultatif)

-out demande.tsq
Nom du fichier de sortie où la demande doit être écrite. La sortie standard par
défaut. (Facultatif)

-text
Si cette option est indiquée, la sortie est au format texte lisible au lieu de DER.
(Facultatif)

Création de réponse d’horodatage
Une réponse d’horodatage (TimeStampResp) se compose d'un état de réponse et du jeton
d'horodatage lui-même (ContentInfo), si la création du jeton a réussi. La commande -reply
permet de créer une réponse d'horodatage ou un jeton d'horodatage suivant la demande et
l’affichage de la réponse ou du jeton dans un format lisible. Si -token_out n'est pas
indiqué, la sortie est toujours une réponse d'horodatage (TimeStampResp), sinon c'est un
jeton d'horodatage (ContentInfo).

-config fichier_conf
Le fichier de configuration à utiliser, cette option remplace la variable
d'environnement OPENSSL_CONF. Consultez OPTIONS DU FICHIER DE CONFIGURATION pour les
variables configurables. (Facultatif)

-spksect section
Le nom de la section du fichier de configuration contenant les paramètres pour la
création de la réponse. S'il n'est pas indiqué, la section TSA par défaut est
utilisée, consultez OPTIONS DU FICHIER DE CONFIGURATION pour plus de précisions.
(Facultatif)

-queryfile demande.tsq
Le nom du fichier contenant une demande d’horodatage encodée en DER. (Facultatif)

-passin src_mot_de_passe
Indiquer la source pour la clef privée de la TSA. Consultez la section PARAMÈTRES DE
PHRASE SECRÈTE d'openssl(1).

-signer tsa_cert.pem
Le certificat de signataire de la TSA au format PEM. Le certificat de signature TSA
doit avoir exactement une utilisation de clef étendue attribuée : timeStamping.
L'utilisation de la clef étendue doit aussi être critique, sinon le certificat sera
refusé. Cela remplace la variable signer_cert du fichier de configuration.
(Facultatif)

-inkey privée.pem
La clef privée du signataire de la TSA au format PEM. Cela remplace l'option
signer_key du fichier de configuration. (Facultatif)

-chain fichier_certs.pem
L’ensemble des certificats au format PEM qui seront tous inclus dans la réponse en
plus du certificat de signataire si l'option -cert a été utilisée pour la demande. Ce
fichier est censé contenir la chaîne de certificats pour le certificat de signataire à
partir de ses émetteurs. La commande -reply ne construit pas de chaîne de certificats
automatiquement. (Facultatif)

policy id_objet
La politique par défaut à utiliser pour la réponse à moins que le client ne demande
explicitement une politique TSA particulière. L'OID peut être indiqué en utilisant une
notation avec points ou par son nom. Cela remplace l'option default_policy du fichier
de configuration. (Facultatif)

-in réponse.tsr
Indiquer une réponse d'horodatage créée précédemment ou un jeton d'horodatage (si
-token_in est également indiquée) au format DER qui sera écrit dans le fichier de
sortie. Cette option ne nécessite pas de demande, elle est par exemple utile pour
examiner le contenu d'une réponse ou d'un jeton ou pour extraire le jeton d'horodatage
d'une réponse. Si l'entrée est un jeton et la sortie une réponse d'horodatage, une
information d’état accordée (« granted ») par défaut est ajoutée au jeton.
(Facultatif)

-token_in
Cet indicateur peut être utilisé avec l'option -in et indique que l'entrée est un
jeton d'horodatage encodé DER (ContentInfo) au lieu d'une réponse d'horodatage
(TimeStampResp). (Facultatif)

-out réponse.tsr
La réponse est écrite dans ce fichier. Le format et le contenu du fichier dépendent
d'autres options (consultez -text, -token_out). La valeur par défaut est la sortie
standard. (Facultatif)

-token_out
La sortie est un jeton d'horodatage (ContentInfo) au lieu d’une réponse d’horodatage
(TimeStampResp). (Facultatif)

-text
Si cette option est indiquée, la sortie est au format texte lisible au lieu de DER.
(Facultatif)

-engine id
Indiquer un moteur (en utilisant son identifiant unique id) forcera ts à essayer
d'obtenir une référence fonctionnelle pour le moteur indiqué et l'initialiser si
nécessaire. Le moteur sera ensuite utilisé par défaut pour tous les algorithmes
disponibles. La valeur par défaut est « builtin ». (Faclutatif)

Vérification de réponse d’horodatage
La commande -verify sert à vérifier si une réponse d'horodatage ou un jeton d'horodatage
est valable et correspond à une demande d'horodatage ou un fichier de données
particuliers. La commande -verify n'utilise pas le fichier de configuration.

-data fichier_à_hacher
La réponse ou le jeton doivent être vérifiés par rapport à fichier_à_hacher. Le
fichier est haché avec l’algorithme de signature de message indiqué dans le jeton. Les
options -digest et -queryfile ne doivent pas être indiquées avec cette option.
(Facultatif)

-digest octets_sign
La réponse ou le jeton doivent être vérifiés par rapport à la signature de message
indiquée par cette option. Le nombre d'octets doit correspondre à l’algorithme de
signature de message indiqué dans le jeton. Les options -data et -queryfile ne doivent
pas être indiquées avec cette option. (Facultatif)

-queryfile demande.tsq
La demande originale d’horodatage au format DER. Les options -data et -queryfile ne
doivent pas être indiquées avec cette option. (Facultatif)

-in réponse.tsr
La réponse d'horodatage à vérifier au format DER. (Obligatoire)

-CApath chemin_cert_confiance
Le nom du répertoire contenant les certificats de l’autorité de confiance du client.
Consultez l'option similaire de verify(1) pour plus de précisions. Soit cette option,
soit -CAfile doit être indiquée. (Facultatif)

-CAfile certs_confiance.pem
Le nom du fichier contenant un ensemble de certificats autosignés de l’autorité de
confiance au format PEM. Consultez l'option similaire de verify(1) pour plus de
précisions. Soit cette option, soit -CApath doit être indiquée. (Facultatif)

-untrusted fichier_cert.pem
Ensemble de certificats supplémentaires qui ne sont pas de confiance au format PEM
pouvant être nécessaires lors de la construction de la chaîne de certificats d'un
certificat de signature de la TSA. Ce fichier doit contenir le certificat de signature
TSA et tous les certificats d’autorité intermédiaires sauf si la réponse les inclut.
(Facultatif)

OPTIONS DU FICHIER DE CONFIGURATION

Les commandes -query et -reply utilisent un fichier de configuration défini par la
variable d'environnement OPENSSL_CONF. Consultez config(5) pour une description générale
de la syntaxe du fichier de configuration. La commande -query n’utilise que la section des
noms symboliques d’OID et peut fonctionner sans elle. Cependant, la commande -reply a
besoin du fichier de configuration pour fonctionner.

Quand une option de ligne de commande est équivalente à une variable, l'option est
toujours prioritaire sur les paramètres du fichier de configuration.

Section tsa, default_tsa
C’est la section principale, qui indique le nom d’une autre section contenant toutes
les options pour la commande -reply. Cette section par défaut peut être remplacée par
l’option -section en ligne de commande. (Facultatif)

oid_file
Consultez ca(1) pour la description. (Facultatif)

oid_section
Consultez ca(1) pour la description. (Facultatif)

RANDFILE
Consultez ca(1) pour la description. (Facultatif)

serial
Le nom du fichier contenant le numéro de série hexadécimal de la dernière réponse
d’horodatage créée. Ce nombre est incrémenté de 1 pour chaque réponse. Si le fichier
n'existe pas au moment de la création de réponse d'un nouveau fichier, un nouveau est
créé avec le numéro de série 1. (Obligatoire)

crypto_device
Indiquer le moteur OpenSSL qui sera défini par défaut pour tous les algorithmes
disponibles. La valeur par défaut est « builtin », vous pouvez indiquer d'autres
moteurs pris en charge par OpenSSL (par exemple, utiliser chil pour le HSM nCipher).
(Facultatif)

signer_cert
Certificat de signature TSA au format PEM. Identique à l'option -signer en ligne de
commande. (Facultatif)

certs
Un fichier contenant un ensemble de certificats encodés PEM qui doivent être inclus
dans la réponse. Identique à l'option -chain en ligne de commande. (Facultatif)

signer_key
La clef privée de la TSA au format PEM. Identique à l'option -inkey en ligne de
commande. (Facultatif)

default_policy
La politique par défaut à utiliser quand la demande n'exige pas de politique.
Identique à -policy en ligne de commande. (Facultatif)

other_policies
Liste des politiques, séparées par des virgules, qui sont aussi acceptables par la TSA
et utilisées seulement si la demande indique explicitement l'une d’entre elles.
(Facultatif)

digests
La liste des algorithmes de signature de message que la TSA accepte. Au moins un
algorithme doit être indiqué. (Obligatoire)

accuracy
La précision de la source de temps de la TSA en seconde, milliseconde et microseconde.
Par exemple secs:1, millisecs:500, microsecs:100. Si l'un des composants est manquant,
ce champ est supposé nul. (Facultatif)

clock_precision_digits
Indiquer le nombre maximal de chiffres pour représenter la fraction de seconde qui
doit être incluse dans champ temporel. Les zéros finaux doivent être supprimés, donc
moins de chiffres pourraient être présents ou aucune fraction de seconde du tout. Pris
en charge uniquement sur les plate-formes UNIX. La valeur maximale est 6, la valeur
par défaut est 0. (Facultatif)

ordering
Si cette option est « yes », les réponses créées par cette TSA peuvent toujours être
ordonnées, même si la différence de temps entre deux réponses est inférieure à la
somme de leurs précisions. « no » par défaut. (Facultatif)

tsa_name
Si cette option est « yes », le nom d'objet de la TSA doit être inclus dans le champ
de noms TSA de la réponse. « no » par défaut. (Facultatif)

ess_cert_id_chain
Les objets SignedData créés par la TSA contiennent toujours l'identifiant de
certificat du certificat de signature dans un attribut signé (consultez la RFC 2634,
« Enhanced Security Services »). Si cette option est « yes » et que soit la variable
certs, soit l'option -chain est indiquée, les identifiants de certificat de la chaîne
seront également inclus dans l’attribut SigningCertificate signé. Si cette variable
est « no », seul l'identifiant de certificat de signature est inclus. « no » par
défaut. (Facultatif)

VARIABLES D'ENVIRONNEMENT

       OPENSSL_CONF contient l'emplacement du fichier de configuration et peut être modifiée par
       l'option -config en ligne de commande.

EXEMPLES

       Tous les exemples ci-dessous supposent que OPENSSL_CONF est défini vers un fichier de
       configuration approprié, comme dans le fichier d'exemple de configuration
       openssl/apps/openssl.cnf.

   Demande d’horodatage
       Pour créer une demande d'horodatage pour design1.txt avec SHA-1 sans nonce, avec la
       politique et sans certificat nécessaire dans la réponse :

         openssl ts -query -data design1.txt -no_nonce \
               -out design1.tsq

       Pour créer une demande d'horodatage similaire en indiquant explicitement l’empreinte du
       message :

         openssl ts -query -digest b7e5d3f93198b38379852f2c04e78d73abdd0f4b \
                -no_nonce -out design1.tsq

       Pour afficher le contenu de la requête précédente en format lisible :

         openssl ts -query -in design1.tsq -text

       Pour créer une demande d'horodatage qui comprend la signature MD-5 de design2.txt, demande
       le certificat du signataire et nonce, indique un identifiant de politique (en supposant
       que le nom tsa_policy1 est défini dans la section OID du fichier de configuration) :

         openssl ts -query -data design2.txt -md5 \
               -policy tsa_policy1 -cert -out design2.tsq

   Réponse d’horodatage
       Avant de créer une réponse, un certificat de signature doit être créé pour la TSA qui
       contient l'extension d’utilisation de clef étendue critique timeStamping sans aucune autre
       extension d'utilisation de clef. Vous pouvez ajouter la ligne « extendedKeyUsage =
       critical,timeStamping » à la section de certificat utilisateur du fichier de configuration
       pour créer un certificat approprié. Consultez req(1), ca(1) et x509(1) pour les
       instructions. Les exemples ci-dessous supposent que cacert.pem contient le certificat de
       l’autorité de certification, tsacert.pem est le certificat de signature émis par
       cacert.pem et tsakey.pem est la clef privée de la TSA.

       Pour créer une réponse d'horodatage pour une requête :

         openssl ts -reply -queryfile design1.tsq -inkey tsakey.pem \
               -signer tsacert.pem -out design1.tsr

       Pour utiliser les paramètres du fichier de configuration :

         openssl ts -reply -queryfile design1.tsq -out design1.tsr

       Pour afficher une réponse d’horodatage sur la sortie standard sous forme lisible :

         openssl ts -reply -in design1.tsr -text

       Pour créer un jeton d'horodatage au lieu d’une réponse d'horodatage :

         openssl ts -reply -queryfile design1.tsq -out design1_token.der \
               -token_out

       Pour afficher un jeton d’horodatage sur la sortie standard sous forme lisible :

         openssl ts -reply -in design1_token.der -token_in -text -token_out

       Pour extraire le jeton d'horodatage d'une réponse :

         openssl ts -reply -in design1.tsr -out design1_token.der -token_out

       Pour ajouter l’information d’état « granted » (accordé) à un jeton d'horodatage créant
       ainsi une réponse valable :

         openssl ts -reply -in design1_token.der -token_in -out design1.tsr

   Vérification d’horodatage
       Pour vérifier une réponse d’horodatage par rapport à une demande :

         openssl ts -verify -queryfile design1.tsq -in design1.tsr \
               -CAfile cacert.pem -untrusted tsacert.pem

       Pour vérifier une réponse d’horodatage qui comprend la chaîne de certificats :

         openssl ts -verify -queryfile design2.tsq -in design2.tsr \
               -CAfile cacert.pem

       Pour vérifier un jeton d'horodatage par rapport au fichier de données d'origine :

         openssl ts -verify -data design2.txt -in design2.tsr \
               -CAfile cacert.pem

       Pour vérifier un jeton d'horodatage par rapport à une empreinte de message :

         openssl ts -verify -digest b7e5d3f93198b38379852f2c04e78d73abdd0f4b \
                -in design2.tsr -CAfile cacert.pem

       D’autres exemples sont aussi disponibles dans le répertoire test.

BOGUES

       Les bogues et suggestions peuvent être envoyés à Zoltan Glozik <zglozik@opentsa.org>. Une
       liste des problèmes connus suit.

       — Pas de prise en charge d’horodatages par SMTP, mais c’est assez facile de mettre en
       œuvre une TSA automatique à base de courriers électroniques avec procmail(1) et perl(1).
       La prise en charge du serveur HTTP est fournie sous forme d'un module Apache séparé. La
       prise en charge de client HTTP est assurée par tsget(1). Le protocole TCP/IP pur n'est pas
       pris en charge.
       — Le fichier contenant le dernier numéro de série de la TSA n'est pas verrouillé lorsqu'il
       est lu ou écrit. C’est un problème si plusieurs instances d’openssl(1) tentent de créer
       une réponse d'horodatage en même temps. Ce n'est pas un problème si le module de serveur
       Apache est utilisé : il fait un verrouillage correct.
       — Recherchez le mot « FIXME » dans les fichiers source.
       — Le code source devrait vraiment être examiné par quelqu'un d'autre.
       — Plus de tests sont nécessaires, seuls quelques tests de base ont été effectués
       (consultez test/testtsa).

AUTEUR

       Zoltan Glozik <zglozik@opentsa.org>, projet OpenTSA (<http://www.opentsa.org>)

VOIR AUSSI

       tsget(1), openssl(1), req(1), x509(1), ca(1), genrsa(1), config(5)

TRADUCTION

       La traduction de cette page de manuel est maintenue par les membres de la liste
       <debian-l10n-french AT lists DOT debian DOT org>. Veuillez signaler toute erreur de
       traduction par un rapport de bogue sur le paquet manpages-fr-extra.