\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]{mer. nov. 26 10:17:57 CET 2014}
\lfoot{\Large \textit{Uubu.fr}}
\hypersetup{pdfinfo={
Title={rfc5208},
Author={Sylvain Girod},
Creator={Bash script from uubu.fr's format version 1},
Producer={Bash script and PDFLaTeX},
Subject={Syntaxe et conteneur pour les informations de clé privée},
CreationDate={D:20141126101757},
ModDate={D:20141126101757},
Keywords={chiffrement;sécurité;certificats}
}}
\begin{document}
 
\begin{center}
{\Huge rfc5208 }
\end{center}
\vspace{1cm}
 
\begin{flushleft}
 
{\large Syntaxe et conteneur pour les informations de clé privée}
 
\vspace{10mm}
 
\vspace{1cm}{\huge Définitions }
 
\
 
\hspace{1mm}  Les informations de clé privée incluent une clé privée pour un algorithme à clé publique spécifié, et un jeu d'attributs. La syntaxe de message cryptographique, dénifis dans la rfc5652, peut être utilisé pour signer numériquement, hasher, authentifier ou chiffrer le type de contenu de clé asymétrique.
\vspace{5mm} \\
 
 
\hspace{1mm}  La liste suivante sont les mises à jours de la rfc5208:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{PrivateKeyInfo a été changé en OneAsymmetricKey. Cela reflète l'ajout du champ publicKey pour permettre aux 2 parties de la clé asymétrique d'être transportés séparément.}
\item[\hspace{1mm} -]{Définition du type de contenu CMS asymmetric Key Package}
\item[\hspace{1mm} -]{Suppression de la redondance IMPLICIT des attributs}
\item[\hspace{1mm} -]{Ajout de publicKey à OneAsymmetricKey et mise à jour du numéro de version}
\item[\hspace{1mm} -]{Ajout du support des attributs PKCS \#9}
\item[\hspace{1mm} -]{Ajout d'une discussion sur la compatibilité avec d'autres formats de clé privée}
\item[\hspace{1mm} -]{Ajout des pré-requis pour le jeu de règle d'encodage}
\item[\hspace{1mm} -]{Changement des imports depuis PKCS \#5}
\item[\hspace{1mm} -]{Remplacement de ALGORITHM-IDENTIFIER avec ALGORITHM depuis la rfc 5912}
\item[\hspace{1mm} -]{Enregistrement du type de média application/pkcs8 et de l'extension de fichier .p8}
\end{description}
 
\vspace{1cm}{\huge Asymmetric Key Package CMS Content Type }
 
\
 
\hspace{1mm}  Le type de contenu CMS paquet de clé asymétrique est utilisé pour transférer une ou plusieurs clé asymétrique d'un partie à un autre. Un paquet de clé asymétrique peut être encapsulé dans un ou plusieurs types de contenu CMS de protection. Les anciennes versions de cette spécification de spécifiaient pas de jeu de règle d'encodage particulier, mais les générateurs devraient utiliser DER et les destinataires doivent supporter BER, qui inclus également DER.
\vspace{5mm} \\
 
 
\hspace{1mm} Ce type de contenu a la syntaxe suivante:
 
{\ttfamily
ct-asymmetric-key-package CONTENT-TYPE ::=\\ \hspace{2mm}\{ AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage \}\\ \hspace{2mm}\\ id-ct-KP-aKeyPackage OBJECT IDENTIFIER ::=\\ \hspace{2mm}\{ joint-iso-itu-t(2) country(16) us(840) organization(1)\\ \hspace{2mm}\hspace{2mm}gov(101) dod(2) infosec(1) formats(2)\\ \hspace{2mm}\hspace{2mm}key-package-content-types(78) 5\\ \hspace{2mm}\}\\ \hspace{2mm}\\ AsymmetricKeyPackage ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey\\ \hspace{2mm}\\ OneAsymmetricKey ::= SEQUENCE \{\\ \hspace{2mm}version Version,\\ \hspace{2mm}privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,\\ \hspace{2mm}privateKey PrivateKey,\\ \hspace{2mm}attributes \texttt{[}0\texttt{]} Attributes OPTIONAL,\\ \hspace{2mm}...,\\ \hspace{2mm}\texttt{[}\texttt{[}2: publicKey \texttt{[}1\texttt{]} PublicKey OPTIONAL \texttt{]}\texttt{]},\\ \hspace{2mm}...\\ \}\\ \hspace{2mm}\\ PrivateKeyInfo ::= OneAsymmetricKey\\ \hspace{2mm}\\ \hspace{2mm}-- PrivateKeyInfo est utilisé par \texttt{[}P12\texttt{]}. Si un élément taggé en version 2 est utilisé,\\ \hspace{2mm}-- La version doit être v2, sinon la version devrait être 1. Quand v1 est utilisé,\\ \hspace{2mm}-- PrivateKeyInfo est le même que dans la \texttt{[}RFC5208\texttt{]}.\\ \hspace{2mm}\\ Version ::= INTEGER \{ v1(0), v2(1) \} (v1, ..., v2)\\ \hspace{2mm}\\ PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier\\ \hspace{2mm}\{ PUBLIC-KEY,\\ \hspace{2mm}\hspace{2mm}\{ PrivateKeyAlgorithms \} \}\\ \hspace{2mm}\\ PrivateKey ::= OCTET STRING\\ \hspace{2mm}-- Le contenu varie en fonction du type de clé. L'identifiant d'algorithme dicte le format de la clé\\ \hspace{2mm}\\ PublicKey ::= BIT STRING\\ \hspace{2mm}-- Le contenu varie en fonction du type de clé. L'identifiant d'algorithme dicte le format de la clé\\ \hspace{2mm}\\ Attributes ::= SET OF Attribute \{ \{ OneAsymmetricKeyAttributes \} \}\\
}
\vspace{8mm}
 
\hspace{1mm}  AsymmetricKeyPackage contient un ou plusieurs élément OneAsymmetricKey.
\vspace{5mm} \\
 
 
\hspace{1mm}  La syntaxe de OneAsymmetricKey accueille un numéro de version, une indication de l'algorithme asymétrique à utiliser avec la clé privée, une clé privée, des attributs optionnels ( par ex. userCertificate de X.520 ), et une clé publique optionnelle. En général, doit la clé publique, soit le certificat est présent. Dans de très rare cas les 2 sont présents, vu qu'ils incluent chacun une copie de la clé publique. OneAsymmetricKey renomme la syntaxe PrivateKeyInfo définie dans la rfc5208. Le nouveau nom reflète mieux la capacité de s'occuper des composant clé publique et privée. La compatibilité avec PrivateKeyInfo est préservée via le numéro de version. Les champs dans OneAsymmetricKey sont utilisé comme suit:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} version]{Identifie la version de OneAsymmetricKey. Si publicKey est présent, la version est v2 sinon v1.}
\item[\hspace{1mm} privateKeyAlgorithm]{Identifie l'algorithme de clé privée et optionnellement les paramètres associés avec la paire de clé asymétrique. L'algorithme est identifiée par un OID et le format des paramètres dépend de cet OID, mais le jeu d'objets privateKeyAlgorithms restreins les OID permis. La valeur placée dans PrivateKeyAlgorithmIdentifier est la valeur d'un algorithme utilisé avec la clé privée.}
\item[\hspace{1mm} privateKey]{Est une chaîne d'octets qui contiennent la valeur de la clé privée. L'interprétation du contenu est définis dans l'enregistrement de l'algorithme de clé privée. Par exemple, une clé DSA est un entier, une clé RSA est représentée en RSAPrivateKey comme définis dans la rfc3447, et une clé ECC est représentée comme ECPrivateKey comme définie dans la rfc5915.}
\item[\hspace{1mm} attributes]{est optionnel et contient les informations correspondantes à la clé publique (par ex: les certificats). Les champs attributes utilise la classe ATTRIBUTE qui est restreins par le jeu d'objet OneAsymmetricKeyAttributes. Les attributs de la rfc2985 peuvent être supportés.}
\item[\hspace{1mm} publicKey]{est optionnel. Si présent, il contient la clé publique encodée en chaîne de bits. L structure dans cette chaîne dépend de privateKeyAlgorithm. Par exemple, une clé DSA est un entier. Noter que les clé publiques RSA sont inclues dans RSAPrivateKey, comme dans rfc 3447, et les clé publiques ECC sont inclues dans ECPrivateKey, comme dans rfc 5915.}
\end{description}
 
\vspace{1cm}{\huge Informations de clé privée chiffrée }
 
\
 
\hspace{1mm} Cette section donne la syntaxe pour les informations de clé privée chiffrée qui sont utilisées par [P12]:
 
{\ttfamily
EncryptedPrivateKeyInfo ::= SEQUENCE \{\\ \hspace{2mm}encryptionAlgorithm EncryptionAlgorithmIdentifier,\\ \hspace{2mm}encryptedData EncryptedData \}\\ \hspace{2mm}\\ EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier\\ \hspace{2mm}\{ CONTENT-ENCRYPTION,\\ \hspace{2mm}\hspace{2mm}\{ KeyEncryptionAlgorithms \} \}\\ \hspace{2mm}\\ EncryptedData ::= OCTET STRING\\
}
\vspace{8mm}
 
\begin{description} \normalsize
\item[\hspace{1mm} encryptionAlgorithm]{Identifie l'algorithme sous lequel les informations de clé privée sont chiffrées.}
\item[\hspace{1mm} encryptedData]{Est le résulta du chiffrement des informations de clé privée.}
\end{description}
 
\hspace{1mm}  Le processus de chiffrement est constitué des étapes suivantes:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{Les informations de clé privée sont encodées. Les générateurs devraient utiliser DER et les destinataires doivent supporter BER, qui inclus également DER}
\item[\hspace{1mm} 2.]{Le résultat de la première étape est chiffré avec la clé secrète pour donner une chaîne d'octets, le résultat du processus de chiffrement.}
\end{description}
 
\vspace{1cm}{\huge Protection de AsymmetricKeyPackage }
 
\
 
\hspace{1mm}  Les types de contenu de protection CMS peuvent être utilisés pour fournir une sécurité à AsymmetricKeyPackage:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} SignedData]{Peut être utilisé pour appliquer une signature numérique à AsymmetricKeyPackage}
\item[\hspace{1mm} EncryptedData]{Peut être utilisé pour chiffrer AsymmetricKeyPackage avec un chiffrement symétrique, où l'émetteur et le destinataire partagent déjà la clé de chiffrement nécessaire.}
\item[\hspace{1mm} EnvelopedData]{Peut être utilisé pour chiffrer AsymmetricKeyPackage avec un chiffrement symétrique, où l'émetteur et le destinataire ne partagent pas la clé de chiffrement nécessaire.}
\item[\hspace{1mm} AuthenticatedData]{Peut être utilisé pour protéger AsymmetricKeyPackage avec MAC, où les informations de gestion de clé sont manipulées d'une manière similaire à EnvelopedData.}
\item[\hspace{1mm} AuthEnvelopedData]{Peut être utilisé pour protéger AsymmetricKeyPackage avec des algorithmes qui supportent de chiffrement authentifié, où les informations de gestion de clé sont manipulées d'une manière similaire à EnvelopedData.}
\end{description}
 
\vspace{1cm}{\huge Considérations d'autres format de clé privée }
 
\
 
\hspace{1mm}  Ce document définis la syntaxe et les sémantiques pour un type de contenu qui échange des clé privées asymétriques. Il y a 2 autres formats qui ont été utilisés pour le transport de clé privée asymétiques:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} Personal Information Exchange]{Est une syntaxe transfert pour les informations d'identité personnelle, incluant les clés privées, certificats, divers autres secrets, et des extensions. OneAsymmetricKey, PrivateKeyInfo, et EncryptedPrivateKeyInfo peuvent être inclus dans un message p12. Les informations de clé privée, OneAsymmetricKey et PrivateKeyInfo, sont inclus dans le KeyBag BAG-TYPE P12. EncryptedPrivateKeyInfo est inclu dans le pkcs8ShroudedKeyBag BAG-TYPE P12. Dans les implémentations courantes, les extensions pfx et p12 peuvent être utilisées.}
\item[\hspace{1mm} Microsoft's private-key]{l'extension pvk est utilisé pour des stockages locaux. pvk et p12 ne sont pas interchangeables.}
\end{description}
 
\hspace{1mm}  Pour extraire les information de clé privée du AsymmetricKeyPackage les couches d'encapsulations doivent être enlevées. Au minimum, la couche ContentInfo doit être enlevée. Si le AsymmetricKeyPackage est encapsulée dans une donnée signée, puis les couches SignedData et EncapsulatedContentInfo doivent également être supprimées. C'est la même chose pour EnvelopedData, EncryptedData, et AuthenticatedData. Une fois toutes les couches supprimées, il y a autant de jeux d'information de clé privée qu'il y a de structure OneAsymmetricKey. OneAsymmetricKey et PrivateKeyInfo ont la même structure, donc peuvent être sauvées en tant que fichier p8 ou copiés dans un BAG-TYPE KeyBag p12. Supprimer les couches de sécurité encapsulantes va invalider toute signature et peut exposer la clé.
\vspace{5mm} \\
 
 
\hspace{1mm} Les fichiers p8 sont parfois encodés PEM, et dans ce cas utilisent l'extension pem. L'encodage PEM est soit l'encodage Base64 ou de type EncryptedPrivateKeyInfo encodé DER inclus entre:
 
{\ttfamily
-----BEGIN ENCRYPTED PRIVATE KEY-----\\ -----END ENCRYPTED PRIVATE KEY-----\\
}
\vspace{8mm}
 
\hspace{1mm} ou l'encodage Base64 du PrivateKeyInfo encodé DER entre:
 
{\ttfamily
-----BEGIN PRIVATE KEY-----\\ -----END PRIVATE KEY-----\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge Media application/pkcs8 }
 
\
 
\begin{description} \normalsize
\item[\hspace{1mm} Type name:]{application}
\item[\hspace{1mm} Subtype name:]{pkcs8}
\item[\hspace{1mm} Required parameters:]{None}
\item[\hspace{1mm} Optional parameters:]{None}
\item[\hspace{1mm} Encoding considerations:]{binary}
\item[\hspace{1mm} Security considerations:]{Carries a cryptographic private key}
\item[\hspace{1mm} Interoperability considerations:]{The PKCS \#8 object inside this media type MUST be DER-encoded PrivateKeyInfo.}
\item[\hspace{1mm} Published specification:]{RFC 5958}
\item[\hspace{1mm} Applications which use this media type:]{Any MIME-compliant transport that processes asymmetric keys.}
\item[\hspace{1mm} Additional information:]{Magic number(s): None}
\item[\hspace{1mm} ]{File extension(s): .p8}
\item[\hspace{1mm} ]{Macintosh File Type Code(s): Person \& email address to contact for further information: Sean Turner <turners@ieca.com>}
\item[\hspace{1mm} Restrictions on usage:]{none}
\end{description}
\end{flushleft}
\end{document}
