\documentclass{report}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{textcomp}
\usepackage{geometry}
\geometry{top=15mm, bottom=15mm, left=1cm, right=1cm}
\usepackage[french]{babel}
\usepackage{pslatex}
\usepackage[colorlinks=true,urlcolor=black]{hyperref}
\usepackage{graphicx}
\usepackage{fancyhdr}
\pagestyle{fancy}
\renewcommand{\footrulewidth}{0.4pt}
\fancyfoot[L]{Uubu.fr}
\fancyfoot[R]{jeu. juil. 7 10:41:32 CEST 2016}
\lfoot{\Large \textit{Uubu.fr}}
\hypersetup{pdfinfo={
Title={rfc3161},
Author={Sylvain Girod},
Creator={Bash script from uubu.fr's format version 1},
Producer={Bash script and PDFLaTeX},
Subject={PKIX Time-Stamp Protocol},
CreationDate={D:20160707104132},
ModDate={D:20160707104132},
Keywords={chiffrement;sécurité;certificats}
}}
\begin{document}
 
\begin{center}
{\Huge rfc3161, rfc5816 }
\end{center}
\vspace{1cm}
 
\begin{flushleft}
 
{\large PKIX Time-Stamp Protocol}
 
\vspace{10mm}
 
\hspace{1mm}  Un service d'horodatage supporte la preuve qu'une donnée existait à une date donnée. Un TSA peut être opéré par un Tiers de confiance (TTP - Trusted Third Party), bien que d'autres modèles opérationels peuvent être appropriés, par ex, une organisation peut exiger un TSA pour de l'horodatage interne.
\vspace{5mm} \\
 
 
\hspace{1mm}  Les services de non-répudiation exigent la capacité d'établir l'existence d'une donnée avant une date spécifiée. Ce protocole peut être utilisé comme bloque de construction de tels services.
\vspace{5mm} \\
 
 
\hspace{1mm}  Pour associer une donnée avec un point dans le temps, une autorité d'horodatage (TSA) peut être utilisé. Ce tiers de confiance fournis une preuve d'existence pour cette donnée particulière à une point dans le temps.
\vspace{5mm} \\
 
 
\hspace{1mm}  Le rôle du TSA est de dater une donnée pour établir l'évidence indiquant qu'une donnée existait avant une date particulière. Cela peut être utilisé, par exemple, pour vérifier qu'une signature numérique a été appliquée à un message avant que le certificat correspondant n'ait été révoqué, permettant à une clé publique révoquée d'être utilisé pour vérifier la signature créé avant la date de révocation. C'est une opération PKI importante. Le TSA peut également être utilisé pour indiquer la date d'émission quand une deadline est critique, ou pour indiquer la date de transaction pour les entrées dans un log.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Le TSA }
 
\
 
\hspace{1mm}  Le TSA est un TTP qui créé des jetons d'horodatage pour indiquer qu'une donnée a existé à un point dans le temps particulier. Pour le reste du document, une "requête valide" signifie une requête que peut être décodée correctement.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Pre-requis du TSA }
 
\
 
\hspace{1mm}  Le TSA doit:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{Utiliser une source de temps fiable pour chaque jeton d'horodatage}
\item[\hspace{1mm} -]{Inclure une date fiable pour chaque jeton d'horodatage}
\item[\hspace{1mm} -]{Inclure un entier unique pour chaque jeton d'horodatage généré}
\item[\hspace{1mm} -]{produire un jeton d'horodatage une fois reçu une requête valide, si possible}
\item[\hspace{1mm} -]{Inclure dans chaque jeton d'horodatage un identifiant pour indiquer de manière unique la stratégie de sécurité sous laquelle le jeton a été créé.}
\item[\hspace{1mm} -]{horodater seulement une représentation hashée des données}
\item[\hspace{1mm} -]{examiner l'OID d'une fonction de hash résistante aux collisions et vérifier que la longueur du hash est consistante avec l'algorithme}
\item[\hspace{1mm} -]{Ne pas example l'empreinte à horodater de toute autre manière}
\item[\hspace{1mm} -]{Ne pas inclure d'identification de l'identité demandeur dans les jetons d'horodatage}
\item[\hspace{1mm} -]{Signer chaque jeton d'horodatage en utilisant une clé générée exclusivement dans ce but et avoir cette propriété de clé indiquée dans le certificat correspondant.}
\item[\hspace{1mm} -]{Inclure les informations additionnelles dans le jeton d'horodatage, si demandé en utilisant le champs extensions, seulement pour les extensions qui sont supportés par le TSA. Si ce n'est pas possible, le TSA doit répondre avec un message d'erreur.}
\end{description}
 
\vspace{1cm}{\huge Transactions TSA }
 
\
 
\hspace{1mm}  Comme premier message de ce mécanisme, l'entité demande un jeton d'horodatage via une requête (qui est ou inclus un TimeStampReq) au TSA. Comme second message, le TSA répond en envoyant une réponse (qui est ou inclus un TimeStampResp) à l'entité.
\vspace{5mm} \\
 
 
\hspace{1mm}  Une fois reçu la réponse ( qui est ou inclus un TimeStampResp qui contient normalement un TimeStampToken (TST) ), l'entité doit vérifier le status retourné dans la réponse et en l'absence d'erreur il doit vérifier les divers champs contenus dans le TimeStampToken et la validité de la signature numérique du TimeStampToken. En particulier, il doit vérifier que l'horodatage correspond à ce qui était demandé. Le demandeur doit vérifier que le TimeStampToken contient l'identifiant de certificat correcte du TSA, l'empreinte des données correcte, et l'OID de l'algorithme de hashage correcte. Il doit ensuite vérifier le délai de la réponse en vérifiant soit la date incluse dans la réponse avec une source de temp locale fiable de référence, si disponible, ou la valeur du nonce (un grand nombre aléatoire avec une grande probabilité qu'il a été généré par le client seulement une seule fois) inclus dans la réponse avec la valeur inclus dans la demande. Si une de ces vérification échoue, le TimeStampToken doit être rejeté.
\vspace{5mm} \\
 
 
\hspace{1mm}  Ensuite, le certificat du TSA peut avoir été révoqué, le status du certificat doivrait être vérifié pour s'assurer que le certificat est valide.
\vspace{5mm} \\
 
 
\hspace{1mm}  Ensuite, l'application cliente devrait vérifie le champ policy pour déterminer si la stratégie sous laquelle le jeton a été émis est acceptable pour l'application.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Identification du TSA }
 
\
 
\hspace{1mm}  Le TSA doit signer chaque message avec une clé réservée spécifiquement dans ce but. Un TSA peut avoir des clé privées distincts, par ex, pour gérer différentes stratégie, différents algorithmes, différentes tailles de clé ou pour augmenter les performances. Le certificat correspondant doit contenir seulement une instance du champ d'utilisation de clé avec KeyPurposeIP ayant la valeur: \textbf{id-kp-timeStamping}. Cette extension doit être critique.
\vspace{5mm} \\
 
 
\hspace{1mm} L'identifiant d'objet suivant identifie le KeyPurposeIP ayant la valeur id-kp-timeStamping
 
{\ttfamily
id-kp-timeStamping OBJECT IDENTIFIER ::= \{iso(1)\\ \hspace{2mm}\hspace{2mm}identified-organization(3) dod(6)\\ \hspace{2mm}\hspace{2mm}internet(1) security(5) mechanisms(5) pkix(7)\\ \hspace{2mm}\hspace{2mm}kp (3) timestamping (8)\}\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge Format des requêtes }
 
\
 
\hspace{1mm} Une requête time-stamping est comme suit:
 
{\ttfamily
TimeStampReq ::= SEQUENCE \{\\ \hspace{2mm}version INTEGER \{ v1(1) \},\\ \hspace{2mm}messageImprint MessageImprint,\\ \hspace{2mm}\hspace{2mm}--Un OID d'algorithme de hash et la valeur du hash des donnée à horodater\\ \hspace{2mm}reqPolicy TSAPolicyId OPTIONAL,\\ \hspace{2mm}nonce INTEGER OPTIONAL,\\ \hspace{2mm}certReq BOOLEAN DEFAULT FALSE,\\ \hspace{2mm}extensions \texttt{[}0\texttt{]} IMPLICIT Extensions OPTIONAL \}\\
}
\vspace{8mm}
 
\hspace{1mm}  Le champ version (actuellement v1) décris la version de la demande d'horodatage.
\vspace{5mm} \\
 
 
\hspace{1mm} Le champ messageImprint devrait contenir le hash des données à horodater. Le hash est représenté comme chaîne d'octets. Sa longueur doit correspondre à la longueur de la valeur du hash pour cet algorithme. (20 octets pour SHA1, 16 pour MD5).
 
{\ttfamily
MessageImprint ::= SEQUENCE \{\\ \hspace{2mm}hashAlgorithm AlgorithmIdentifier,\\ \hspace{2mm}hashedMessage OCTET STRING \}\\
}
\vspace{8mm}
 
\hspace{1mm}  L'algorithme de hashage indiqué dans le champ hashAlgoritm devrait être un algorithme de hashage connu. Cela signifie qu'il doit être one-way et résistant aux collisions. Le TSA devrait vérifier si l'algorithme de hashage donné est connu pour être suffisant. Si le TSA ne reconnait pas l'algorithme de hashe ou sait qu'il est faible, le TSA devrait refuser de fournir le jeton d'horodatage en retournant un pkiStatusInfo de 'bad\_alg'.
\vspace{5mm} \\
 
 
\hspace{1mm}  Le champ reqPolicy, si inclus, indique la stratégie TSA sous laquelle le TimeStampTocke devrait être fournis. TSAPolicyId est définis comme suit: \textbf{TSAPolicyId ::= OBJECT IDENTIFIER}
\vspace{5mm} \\
 
 
\hspace{1mm}  Le nonce, si inclus, permet au client de vérifier la date de la réponse quand aucune horloge locale n'est disponible. Le nonce est un grand nombre aléatoire avec une forte probabilité que le client l'a généré seulement une seule fois. Dans ce cas la même valeur nonce doit être incluse dans la réponse, sinon la réponse doit être rejetée.
\vspace{5mm} \\
 
 
\hspace{1mm}  Si le champ certReq est présent et à true, le certificat du TSA qui est référencé par l'identifiant ESSCertID dans un attribut SigningCertificate ou ESSCertIDv2 dans la réponse doit être fournie par le TSA dans le champ certificates de la structure SignedData dans cette réponse. Ce champ peut également contenir d'autres certificats.
\vspace{5mm} \\
 
 
\hspace{1mm}  Si le champ certReq est manquant ou s'est est présent est à false, le champ certificates ne doit pas être présent dans la réponse.
\vspace{5mm} \\
 
 
\hspace{1mm}  Le champ extensions est un manière générique d'ajouter des informations additionnelles aux requêtes dans le future. Les extensions sont définies dans la rfc2459. Si une extension, qu'elle soit marquée critique ou non, est utilisée par un demandeur mais non reconnue par le TSA, le serveur ne doit pas émettre de jeton et doit retourner une erreur (unacceptedExtension)
\vspace{5mm} \\
 
 
\hspace{1mm}  La requête d'horodatage ne doit pas identifier le demandeur, vu que cette information n'est pas validée par le TSA. Dans les situations où le TSA exige l'identité du demandeur, une identification/authentification alternative doit être mise en place.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Format de réponse }
 
\
 
\hspace{1mm} Une réponse d'horodatage est comme suit:
 
{\ttfamily
TimeStampResp ::= SEQUENCE \{\\ \hspace{2mm}status PKIStatusInfo,\\ \hspace{2mm}timeStampToken TimeStampToken OPTIONAL \}\\
}
\vspace{8mm}
 
\hspace{1mm} Le status est basé sur la définition des status dans la rfc2510 comme suit:
 
{\ttfamily
PKIStatusInfo ::= SEQUENCE \{\\ \hspace{2mm}status PKIStatus,\\ \hspace{2mm}statusString PKIFreeText OPTIONAL,\\ \hspace{2mm}failInfo PKIFailureInfo OPTIONAL \}\\
}
\vspace{8mm}
 
\hspace{1mm} Quand le status contient la valeur 0 ou 1, un TimeStampToken doit être présent. Quand le status contient une autre valeur, un TimeStampToken ne doit pas être présent. Une des valeurs suivantes doit être contenus dans le status:
 
{\ttfamily
PKIStatus ::= INTEGER \{\\ \hspace{2mm}granted (0),\\ \hspace{2mm}grantedWithMods (1),\\ \hspace{2mm}rejection (2),\\ \hspace{2mm}waiting (3),\\ \hspace{2mm}revocationWarning (4), // indique une révocation imminente\\ \hspace{2mm}revocationNotification (5) // indique une révocation\\
}
\vspace{8mm}
 
\hspace{1mm}  Les serveurs conformes ne doivent pas produire d'autres valeur. Les clients conforme doivent générer une erreur si des valeurs qu'il ne comprend pas sont présents.
\vspace{5mm} \\
 
 
\hspace{1mm} Quand le TimeStampToken n'est pas présent, failInfo indique la raison du rejet de le requête et peut être une des valeurs suivantes:
 
{\ttfamily
PKIFailureInfo ::= BIT STRING \{\\ \hspace{2mm}badAlg (0), -- identifiant d'algorithme non supporté ou inconnu\\ \hspace{2mm}badRequest (2), -- transaction non permise ou non supportée\\ \hspace{2mm}badDataFormat (5), -- Mauvais format de données transmises\\ \hspace{2mm}timeNotAvailable (14), -- Source de temps du TSA non disponible\\ \hspace{2mm}unacceptedPolicy (15), -- La stratégie TSA demandée n'est pas supportée par le TSA\\ \hspace{2mm}unacceptedExtension (16), -- extension non supportée par le TSA\\ \hspace{2mm}addInfoNotAvailable (17), -- Les informations additionnelles demandées ne sont pas comprises ou non disponible\\ \hspace{2mm}systemFailure (25) -- La requête ne peut pas être gérée à cause d'une erreur système\\ \}\\
}
\vspace{8mm}
 
\hspace{1mm}  Ce sont les seules valeurs de PKIFailureInfo qui doivent être supportées.
\vspace{5mm} \\
 
 
\hspace{1mm}  Les serveurs conformes ne doivent pas produire d'autres valeurs. Les clients conformes doivent générer une erreur si des valeurs qu'il ne comprend pas sont présents.
\vspace{5mm} \\
 
 
\hspace{1mm}  Le champ statusString de PKIStatusInfo peut être utilisé pour inclure un texte de raison.
\vspace{5mm} \\
 
 
\hspace{1mm} Un TimeStampToken est comme suit. Il est définis comme ContentInfo et doit encapsuler un type de contenu de données signée.
 
{\ttfamily
TimeStampToken ::= ContentInfo\\ \hspace{2mm}-- contentType is id-signedData (\texttt{[}CMS\texttt{]})\\ \hspace{2mm}-- content is SignedData (\texttt{[}CMS\texttt{]})\\
}
\vspace{8mm}
 
\hspace{1mm}  Les champs de type EncapsulatedContentInfo de la construction SignedData ont la signification suivante:
\vspace{5mm} \\
 
 
\hspace{1mm} eContentType est un identifiant d'objet qui spécifie uniquement le type de contenu. Pour un jeton d'horodatage il est définis comme suit:
 
{\ttfamily
id-ct-TSTInfo OBJECT IDENTIFIER ::= \{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4\}\\
}
\vspace{8mm}
 
\hspace{1mm}  eContent est le contenu, un chaîne d'octet, un TSTInfo encodé DER.
\vspace{5mm} \\
 
 
\hspace{1mm} Le jeton d'horodatage ne doit pas contenir de signature autre que la signature du TSA. L'identifiant de certificat (ESSCertID ou ESSCertIDv2) du certificat TSA doit être inclus comme attribut signerInfo dans l'attribut SigningCertificate.
 
{\ttfamily
TSTInfo ::= SEQUENCE \{\\ \hspace{2mm}version INTEGER \{ v1(1) \},\\ \hspace{2mm}policy TSAPolicyId,\\ \hspace{2mm}messageImprint MessageImprint,\\ \hspace{2mm}\hspace{2mm}-- doit avoir la même valeur que le champ similaire dans TimeStampReq\\ \hspace{2mm}serialNumber INTEGER,\\ \hspace{2mm}genTime GeneralizedTime,\\ \hspace{2mm}accuracy Accuracy OPTIONAL,\\ \hspace{2mm}ordering BOOLEAN DEFAULT FALSE,\\ \hspace{2mm}nonce INTEGER OPTIONAL,\\ \hspace{2mm}\hspace{2mm}-- Doit être présent si le champ similaire est présent dans TimeStampReq, et doit avoir la même valeur\\ \hspace{2mm}tsa \texttt{[}0\texttt{]} GeneralName OPTIONAL,\\ \hspace{2mm}extensions \texttt{[}1\texttt{]} IMPLICIT Extensions OPTIONAL \}\\
}
\vspace{8mm}
 
\hspace{1mm}  Le champ version (v1) décris la version du jeton d'horodatage. Les serveurs conformes doivent être capable de fournir des jetons version 1.
\vspace{5mm} \\
 
 
\hspace{1mm}  Parmis les champs optionnels, seul nonce doit être supporté. Les demandeurs conforme doivent être capable de reconnaitre les jeton d'horodatage version 1 avec tous les champs optionnels présents, mais ne sont pas obligés de comprendre les sémantiques des extensions. si présent.
\vspace{5mm} \\
 
 
\hspace{1mm}  Le champ policy doit indiquer la stratégie TSA sous laquelle la réponse a été produite. Si un champ similaire est présent dans TimeStampReq, il doit avoir la même valeur, sinon une erreur unacceptedPolicy doit être retournée. Cett stratégie peut inclure les types d'information suivantes (bien que cette liste n'est certainement pas exhaustive):
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{Les condition sous lesquels le jeton peut être uilisé}
\item[\hspace{1mm} -]{La disponibilité de log de jeton d'horodatage, pour permettre une vérification ultérieur de l'authenticité du jeton.}
\end{description}
 
\hspace{1mm}  Le messageImprint doit avoir la même valeur que le champ similaire dans le TimeStampReq, indiquant que la taille de la valeur du hash matche la taille attendue de l'algorithme de hashage identifié dans hashAlgorithm.
\vspace{5mm} \\
 
 
\hspace{1mm}  Le champ serialNumber est un entier assigné par le TSA pour chaque TimeStampTocken. Il doit être unique pour chaque TimeStampToken émis par un TSA donné.
\vspace{5mm} \\
 
 
\hspace{1mm}  genTime est la date à laquelle le jeton a été créé par le TSA. Il est exprimé en temp UTC pour réduire la confusion avec le timezone local. UTC est une échelle de temp, basée sur le secon (SI), comme définis et recommandé par le CCIR, et maintenu par le Bureau International des Poids et Mesures (BIPM). Un synonime est le temp "Zulu" qui est utilisé par l'aviation civile et représentée par la lettre Z.
\vspace{5mm} \\
 
 
\hspace{1mm} accuracy représent la déviation de temp autour du temps UTC contenus dans GeneralizedTime.
 
{\ttfamily
Accuracy ::= SEQUENCE \{\\ \hspace{2mm}seconds INTEGER OPTIONAL,\\ \hspace{2mm}millis \texttt{[}0\texttt{]} INTEGER (1..999) OPTIONAL,\\ \hspace{2mm}micros \texttt{[}1\texttt{]} INTEGER (1..999) OPTIONAL \}\\
}
\vspace{8mm}
 
\hspace{1mm}  Si un des éléments est manquant, la valeur est considéré comme 0. En ajoutant la valeur accuracy dans le GeneralizedTime, une limite supérieur du temp auquel le jeton d'horodatage a été créé par la TSA peut être obteni. De la même manière, en soustrayant l'accuracy au GeneralizedTime, une limite inférieur du temp auquel le jeton a été créé par le TSA peut être obtenu.
\vspace{5mm} \\
 
 
\hspace{1mm}  Si le champ ordering est manquant, ou s'il est présent et mis à false, le champ genTime indique seulement le temp auquel le jeton a été créé par le TSA. Dans un tel cas, l'ordre des jetons d'horodatage émis par le même TSA ou différents TSA est seulement possible quand la différence entre le genTime du premier jeton et le genTime du second jeton est supérieur à la somme des accuracy du genTime pour chaque jeton.
\vspace{5mm} \\
 
 
\hspace{1mm}  Si le champ ordering est présent et à true, tout jeton du même TSA peut toujours être ordonné basé sur le champ genTime, sans regarder l'accuracy GenTime.
\vspace{5mm} \\
 
 
\hspace{1mm}  Le champ nonce doit être présent s'il est présent dans le TimeStampReq. Dans ce cas, il doit être recopié dans la structure TimeStampReq.
\vspace{5mm} \\
 
 
\hspace{1mm}  Le but du champ tsa est de donner une indication pour identifier le nom du TSA. Si présent, il doit correspondre à un des nom de sujet inclus dans le certificat qui est utilisé pour vérifier le jeton. Cependant, l'identification de l'entité qui a signé la réponse se produit toujours via l'utilisation de l'identifiant de certificat (ESSCertID) dans l'attribut SigningCertificate ou ESSCertIDv2 dans l'attribut SigningCertificateV2 qui fait partie du signerInfo.
\vspace{5mm} \\
 
 
\hspace{1mm}  Les extensions sont une manière générique d'ajouter des informations additionnelles dans le future.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Transports }
 
\
 
\hspace{1mm}  Il n'y a pas de mécanisme de transport obligatoire pour les messages TSA dans ce document. Les mécanismes décris ci-dessous sont optionnels, d'autres mécanisme pouvant être définis dans le future.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge E-mail }
 
\
 
\hspace{1mm} Cette section spécifie un moyen de transporter des messages encodés ASN.1 pour l'échange de protocole via les mails. 2 objets MIME sont spécifiés comme suit:
 
{\ttfamily
Content-Type: application/timestamp-query\\ Content-Transfer-Encoding: base64\\ <<the ASN.1 DER-encoded Time-Stamp message, base64-encoded>>\\ Content-Type: application/timestamp-reply\\ Content-Transfer-Encoding: base64\\ <<the ASN.1 DER-encoded Time-Stamp message, base64-encoded>>\\
}
\vspace{8mm}
 
\hspace{1mm}  Ces objets MIME peuvent être respectivement envoyés et reçus en utilisant les moteurs de traitement MIME qui fournissent un simple transport par mail des messages d'horodatage.
\vspace{5mm} \\
 
 
\hspace{1mm} Pour les types MIME application/timestamp-query et application/timestamp-reply, les implémentations devraient inclure les paramètres optionnels "name" et "filename". Inclure un nom de fichier aide à préserver le type d'information quand les requêtes et réponses d'horodatage sont sauvées en tant que fichier. Quand ces paramètres sont inclus, un nom de fihier avec l'extension approprié devrait être sélectionné:
 
{\ttfamily
\_\_\_\_\_\_MIME Type\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_File Extension\\ application/timestamp-query\_\_\_\_\_\_\_\_\_\_\_\_.TSQ\\ application/timestamp-reply\_\_\_\_\_\_\_\_\_\_\_\_.TSR\\
}
\vspace{8mm}
 
 
 
\vspace{1cm}{\huge Fichier }
 
\
 
\hspace{1mm}  Un fichier contenant un message timestamp doit contenir seulement l'encodé DER d'un message TSA. De tels fichiers peuvent être utilisé pour transporter les messages timestamp en utiisant ftp par exemple.
\vspace{5mm} \\
 
 
\hspace{1mm}  Une requête timestamp devrait être contenue dans un fichier avec l'extension .tsq, et une réponse devrait être contenue dans un fichier avec l'extension .tsr
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Socket }
 
\
 
\hspace{1mm}  Le protocole suivant basé sur TCP est utilisé pour transporter les messages TSA. Ce protocole est utilisable pour les cas où une entité initie une transaction et peut demander un résultat. Le protocole assume qu'un processus d'écoute dans un TSA peut accepter les messages TSA sur un port définis (318).
\vspace{5mm} \\
 
 
\hspace{1mm}  Généralement un initiateur lie ce port et envoie le message TSA initiale. Le répondeur répond avec un message TSA et/ou avec un numéro de référence à utiliser ultérieurement pour demander la réponse.
\vspace{5mm} \\
 
 
\hspace{1mm}  L'initiateur d'une transaction envoie un "direct TCP-based TSA message" au destinataire. Le destinataire répond avec un message similaire. Un "direct TCP-based TSA message" consiste de: \textbf{length (32-bits), flag (8-bits), value (defined below)}
\vspace{5mm} \\
 
 
\hspace{1mm} Le champ longueur contient le nombre d'octets du reste du message. Toutse les valeurs 32bits dans ce protocole sont spécifiés pour être dans l'ordre d'octet réseaux
 
{\ttfamily
Message name flag value\\ tsaMsg '00'H DER-encoded TSA message -- message TSA\\ pollRep '01'H polling reference (32 bits),\\ \hspace{2mm}\hspace{2mm}\hspace{2mm}\hspace{2mm}\hspace{2mm}time-to-check-back (32 bits)\\ \hspace{2mm}\hspace{2mm}\hspace{2mm}\hspace{2mm}\hspace{2mm}-- Réponse quand aucun message TSA n'est prête. Utilise la valeur polling reference (et la valeur de date estimée) pour la demande ultérieur.\\ pollReq '02'H polling reference (32 bits)\\ \hspace{2mm}\hspace{2mm}\hspace{2mm}\hspace{2mm}\hspace{2mm}-- demande d'une réponse TSA pour le message initial\\ negPollRep '03'H '00'H\\ \hspace{2mm}\hspace{2mm}\hspace{2mm}\hspace{2mm}\hspace{2mm} pas d'autre réponses ultérieur (ex: transaction complète)\\ partialMsgRep '04'H next polling reference (32 bits),\\ \hspace{2mm}\hspace{2mm}\hspace{2mm}\hspace{2mm}\hspace{2mm}time-to-check-back (32 bits),\\ \hspace{2mm}\hspace{2mm}\hspace{2mm}\hspace{2mm}\hspace{2mm}DER-encoded TSA message\\ \hspace{2mm}\hspace{2mm}\hspace{2mm}\hspace{2mm}\hspace{2mm}-- réponse partielle du message initial plus une nouvelle référence d'attente à utilise pour obtenir la prochaine partie de la réponse\\ finalMsgRep '05'H DER-encoded TSA message\\ \hspace{2mm}\hspace{2mm}\hspace{2mm}\hspace{2mm}\hspace{2mm}-- réponse finale du message initial\\ errorMsgRep '06'H human readable error message\\ \hspace{2mm}\hspace{2mm}\hspace{2mm}\hspace{2mm}\hspace{2mm}-- produit quand une erreur est détectée\\
}
\vspace{8mm}
 
\hspace{1mm}  La séquence des messages qui se produit est:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} a)]{L'entité envoie tsaMsg et reçoit un pollRep, negPollRep, partialMsgRep, ou finalMsgRep dans la réponse.}
\item[\hspace{1mm} b)]{L'entité envoie un message pollReq et reçois negPollRep, partialMsgRep, finalMsgRep, ou errorMsgRep dans la réponse}
\end{description}
 
\vspace{1cm}{\huge HTTP }
 
\
 
\hspace{1mm} 2 objets MIME sont spécifiés comme suit:
 
{\ttfamily
Content-Type: application/timestamp-query\\ \hspace{2mm}\\ \hspace{2mm}<<the ASN.1 DER-encoded Time-Stamp Request message>>\\ \hspace{2mm}\\ Content-Type: application/timestamp-reply\\ \hspace{2mm}\\ \hspace{2mm}<<the ASN.1 DER-encoded Time-Stamp Response message>>\\
}
\vspace{8mm}
 
\hspace{1mm}  Ces 2 objets MIME peuvent être envoyés et reçus en utilisant un moteur de traitement HTTP sur des liens WWW et fournis un transport simple via navigateur internet. Une fois un requête valide reçue, le serveur doit répondre avec soit une réponse valide avec le type application/timestamp-response, ou avec une erreur HTTP.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Considérations de sécurité }
 
\
 
\hspace{1mm}  Tout le document est concerné par les considérations de sécurité. En concevant un service TSA, les considérations suivantes ont été identifiées comme ayant un impacte sur la validité ou la confiance dans le jeton d'horodatage.
\vspace{5mm} \\
 
 
\hspace{1mm}  1. Quand un TSA ne doit plus être utilisé, mais la clé privée TSA n'a pas été compromise, le certificat de l'autorité doit être révoqué. Quand l'extension reasonCode relatif au certificat révoqué du TSA est présent dans les extensions d'entrée de CRL, il doit être mis soit à unspecified, affiliationChanged, superseded ou cessationOfOperation. Dans ce cas, les jetons signés avec la clé correspondante seront considérés comme invalides, mais les jetons générés avant la date de révocation resteront valides. Quand l'extension reasonCode n'est pas présent dans la CRL, tous les jetons qui ont été signés avec la clé correspondante doivent être considérés comme invalides. Pour cette raison, il est recommandé d'utiliser l'extension reasonCode.
\vspace{5mm} \\
 
 
\hspace{1mm}  2. Quand la clé privée TSA a été compromise, le certificat correspondant doit être révoqué. Dans ce cas, l'extension reasonCode peut être présent et dans ce cas doit être à keyCompromise. Tout jeton signé par le TSA utilisant cette clé privée ne peuvent plus être validés. Pour cette raison, il est impératif que la clé privée du TSA soit conservé en lieu sûr et contrôlé pour minimiser la possibilité d'être compromise. Dans le cas où la clé privée est compromise, un audit de tous les jetons générés par le TSA peut fournir un moyen de discriminer les jetons. 2 jetons d'horodatage de 2 TSA différents est une autre manière d'adresser ce problème.
\vspace{5mm} \\
 
 
\hspace{1mm}  3. La clé de signature TSA doit être suffisamment longue pour une durée de vie confortable. Même si c'est le cas, la clé a une durée de vie définie. Donc, tout jeton signé par le TSA devrait être horodatées de nouveau (si des copies authentique des anciennes CRL sont disponibles) ou notarisé (s'il elle ne le sont pas) à une date ultérieur pour renouveler la confiance qui existe dans la signature du TSA. Les jetons d'horodatage peuvent également être conservés avec un "Evidence Recording Authority" pour maintenir ce trust.
\vspace{5mm} \\
 
 
\hspace{1mm}  4. Une application client utilisant seulement un nonce et sans horloge locale devrait être concerné par la quantité de temp qu'il est prêt à attendre la réponse. Une attaque MITM peut introduire un délai. Donc, un TimeStampResp qui prend trop de temp devrait être considéré comme suspect. Vu que chaque méthode de transport spécifié dans ce document a différentes caractéristiques de délai, la durée considérée acceptable dépend du transport utilisé, ainsi que les facteurs environnementaux.
\vspace{5mm} \\
 
 
\hspace{1mm}  5. Si différentes entités obtiennent des jetons d'horodatage sur le même objet en utilisant le même algorithme de hashage, ou une simple entité obtient plusieurs jetons sur le même objet, les jetons générés incluent le même message; en résultat, un observateur avec accès à ces jetons peut en déduire que l'horodatage réfère aux même données.
\vspace{5mm} \\
 
 
\hspace{1mm}  6. Le replays délibérés ou par inadvertance pour les demandes incorporant le même algorithme de hashage et de valeur peut se produire. Les replays par inadvertance se produisent quand plus d'une copie de la même requête est envoyée au TSA à cause de problèmes réseau. Les replays délibérés se produisent via MITM. Pour détecter ces situations, de nombreuses techniques peuvent être utilisé. Utiliser un nonce permet toujours de détecter les replay, et est recommandé. Il est également possible d'utiliser une horloge local, et une fenêtre de temps durant laquelle le demandeur mémorise tous les hash envoyés . En reçevant une réponse, le demandeur s'assure que l'heure de la réponse est dans la fenêtre et qu'il y a une seule occurence de la valeur de hash dans cette fenêtre de temps.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge APPENDIX A - attributs Time-stamp utilisant CMS }
 
\
 
\hspace{1mm}  Une des utilisations majeur de l'horodatage est d'horodater une signature pour prouver qu'une signature numérique a été créée avant une date donnée. Le certificat correspondant est révoqué, cela permet à un vérificateur de savoir si la signature a été créé avant ou après la date de révocation.
\vspace{5mm} \\
 
 
\hspace{1mm}  Un endroit sensible où stocker un timestamp est dans une structure CMS comme un attribut non-signé. Cette appendice définis un attribut Signature Time-stamp qui peut être utilisé pour horodater une signature numérique.
\vspace{5mm} \\
 
 
\hspace{1mm} Les identifiant d'objets suivants identifient cet attribut:
 
{\ttfamily
id-aa-timeStampToken OBJECT IDENTIFIER ::= \{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 14 \}\\
}
\vspace{8mm}
 
\hspace{1mm} La valeur de cet attribut a le type ASN.1 SignatureTimeStampToken:
 
{\ttfamily
SignatureTimeStampToken ::= TimeStampToken\\
}
\vspace{8mm}
 
\hspace{1mm}  La valeur du champ messageImprint dans TimeStampToken doit être un hash de la aleur du champ signature dans SignerInfo pour le signedData à horodater.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge APPENDIX 1 - Placer une signature à un point dans le temps }
 
\
 
\hspace{1mm}  On présent un exemple d'une utilisation possible de ce service d'horodatage généraliste. Il place une signature à un point dans le temps, depuis lequel les informations de status du certificat appropri(ex, CRL) doit être vérifié. Cette application est prévue pour être utilisée en conjonction avec des preuves générées en utilisant un mécanisme de signature numérique.
\vspace{5mm} \\
 
 
\hspace{1mm}  Les signature peuvent seulement être vérifiées en accord avec une stratégie de non-répudiation. Cette stratégie peut être implicite ou explicite (ex, indiquée dans la preuve fournie par le signataire). La stratégie de non-répudiation peut spécifier, entre-autre, la période permise par un signataire pour déclarer la compromission d'un clé de signature utilisée pour la génération des signatures numérique. Donc une signature ne peut pas garantir d'être valide jusqu'à la fin de cette période.
\vspace{5mm} \\
 
 
\hspace{1mm}  Pour vérifier une signature numérique, la technique basique suivante peut être utilisée:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} A)]{Les informations d'horodatage doivent être obtenus juste après la production de la signature}
\end{description}
 
\begin{description} \normalsize
\item[\hspace{6mm} 1)]{La signature est présentée au TSA. Le TSA retourne un TimeStampToken (TST).}
\item[\hspace{6mm} 2)]{Le demandeur du service doit vérifier que le TimeStampToken est correct.}
\end{description}
 
\begin{description} \normalsize
\item[\hspace{1mm} B)]{La validité de la signature numérique peut ainsi être vérifiée de la manière suivante:}
\end{description}
 
\begin{description} \normalsize
\item[\hspace{6mm} 1)]{Le jeton d'horodatage lui-même doit être vérifié et qu'il s'applique à la signature du signataire}
\item[\hspace{6mm} 2)]{La date indiquée par le TSA dans le TimeStampToken doit être retrouvée.}
\item[\hspace{6mm} 3)]{Le certificat utilisé par le signataire doit être identifié et récupéré}
\item[\hspace{6mm} 4)]{La date indiquée par le TSA doit être dans la période de validité du certificat du signataire}
\item[\hspace{6mm} 5)]{Les informations de révocation sur ce certificat, à la date de l'opération d'horodatage, doit être récupéré}
\item[\hspace{6mm} 6)]{Si le certificat est révoqué, la date de révocation doit être ultérieur à la date indiquée par le TSA.}
\end{description}
 
\hspace{1mm}  Si toutes ces conditions sont réussies, la signature numérique doit être déclarée comme valide.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge APPENDIX C - Module ASN.1 utilisant la syntaxe 1988 }
 
\
 
{\ttfamily
PKIXTSP \{iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)\}\\ \hspace{2mm}\\ DEFINITIONS IMPLICIT TAGS ::=\\ \hspace{2mm}\\ BEGIN\\ \hspace{2mm}\\ -- EXPORTS ALL --\\ \hspace{2mm}\\ IMPORTS\\ Extensions, AlgorithmIdentifier FROM PKIX1Explicit88 \{iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)\}\\ GeneralName FROM PKIX1Implicit88 \{iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)\}\\ ContentInfo FROM CryptographicMessageSyntax \{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)\}\\ PKIFreeText FROM PKIXCMP \{iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cmp(9)\} ;\\ \hspace{2mm}\\ -- Locally defined OIDs --\\ \hspace{2mm}\\ -- eContentType for a time-stamp token\\ \hspace{2mm}\\ id-ct-TSTInfo OBJECT IDENTIFIER ::= \{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4\}\\ \hspace{2mm}\\ -- 2.4.1\\ \hspace{2mm}\\ TimeStampReq ::= SEQUENCE \{\\ \hspace{2mm}version INTEGER \{ v1(1) \},\\ \hspace{2mm}messageImprint MessageImprint,\\ \hspace{2mm}\hspace{2mm}--a hash algorithm OID and the hash value of the data to be time-stamped\\ \hspace{2mm}reqPolicy TSAPolicyId OPTIONAL,\\ \hspace{2mm}nonce INTEGER OPTIONAL,\\ \hspace{2mm}certReq BOOLEAN DEFAULT FALSE,\\ \hspace{2mm}extensions \texttt{[}0\texttt{]} IMPLICIT Extensions OPTIONAL \}\\ \hspace{2mm}\\ MessageImprint ::= SEQUENCE \{\\ \hspace{2mm}hashAlgorithm AlgorithmIdentifier,\\ \hspace{2mm}hashedMessage OCTET STRING \}\\ \hspace{2mm}\\ TSAPolicyId ::= OBJECT IDENTIFIER\\ \hspace{2mm}\\ -- 2.4.2\\ \hspace{2mm}\\ TimeStampResp ::= SEQUENCE \{\\ \hspace{2mm}status PKIStatusInfo,\\ \hspace{2mm}timeStampToken TimeStampToken OPTIONAL \}\\ \hspace{2mm}\\ PKIStatusInfo ::= SEQUENCE \{\\ \hspace{2mm}status PKIStatus,\\ \hspace{2mm}statusString PKIFreeText OPTIONAL,\\ \hspace{2mm}failInfo PKIFailureInfo OPTIONAL \}\\ \hspace{2mm}\\ PKIStatus ::= INTEGER \{\\ \hspace{2mm}granted (0),\\ \hspace{2mm}\hspace{2mm}-- when the PKIStatus contains the value zero a TimeStampToken, as requested, is present.\\ \hspace{2mm}grantedWithMods (1),\\ \hspace{2mm}\hspace{2mm}-- when the PKIStatus contains the value one a TimeStampToken, with modifications, is present.\\ \hspace{2mm}rejection (2),\\ \hspace{2mm}waiting (3),\\ \hspace{2mm}revocationWarning (4),\\ \hspace{2mm}\hspace{2mm}-- this message contains a warning that a revocation is imminent\\ \hspace{2mm}\hspace{2mm}revocationNotification (5)\\ -- notification that a revocation has occurred \}\\ \hspace{2mm}\\ PKIFailureInfo ::= BIT STRING \{\\ \hspace{2mm}badAlg (0),\\ \hspace{2mm}badRequest (2),\\ \hspace{2mm}badDataFormat (5),\\ \hspace{2mm}timeNotAvailable (14),\\ \hspace{2mm}unacceptedPolicy (15),\\ \hspace{2mm}unacceptedExtension (16),\\ \hspace{2mm}addInfoNotAvailable (17)\\ \hspace{2mm}systemFailure (25)\\ \hspace{2mm}\\ TimeStampToken ::= ContentInfo\\ \hspace{2mm}\\ TSTInfo ::= SEQUENCE \{\\ \hspace{2mm}version INTEGER \{ v1(1) \},\\ \hspace{2mm}policy TSAPolicyId,\\ \hspace{2mm}messageImprint MessageImprint,\\ \hspace{2mm}\hspace{2mm}-- MUST have the same value as the similar field in TimeStampReq\\ \hspace{2mm}serialNumber INTEGER,\\ \hspace{2mm}\hspace{2mm}-- Time-Stamping users MUST be ready to accommodate integers up to 160 bits.\\ \hspace{2mm}genTime GeneralizedTime,\\ \hspace{2mm}accuracy Accuracy OPTIONAL,\\ \hspace{2mm}ordering BOOLEAN DEFAULT FALSE,\\ \hspace{2mm}nonce INTEGER OPTIONAL,\\ \hspace{2mm}\hspace{2mm}-- MUST be present if the similar field was present in TimeStampReq. In that case it MUST have the same value.\\ \hspace{2mm}tsa \texttt{[}0\texttt{]} GeneralName OPTIONAL,\\ \hspace{2mm}extensions \texttt{[}1\texttt{]} IMPLICIT Extensions OPTIONAL \}\\ Accuracy ::= SEQUENCE \{\\ \hspace{2mm}seconds INTEGER OPTIONAL,\\ \hspace{2mm}millis \texttt{[}0\texttt{]} INTEGER (1..999) OPTIONAL,\\ \hspace{2mm}micros \texttt{[}1\texttt{]} INTEGER (1..999) OPTIONAL \}\\ END\\
}
\vspace{8mm}
\end{flushleft}
\end{document}
