Avez-vous un compte?
Ce document décrit les formats des données et les codages d'Infrastructure à clés publiques (PKI) les plus communs.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
L'Abstract Syntax Notation One (ASN.1) est un langage formel pour la définition des types et des valeurs de données, et comment ces types et valeurs de données sont utilisés et combinés dans diverses structures de données. Le but de la norme est de définir l'abstract syntax des informations sans contraindre comment les informations sont encodées pour la transmission.
Voici un exemple extrait du RFC X.509 :
Version ::= INTEGER { v1(0), v2(1), v3(2) }
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE {
notBefore Time,
notAfter Time }
Time ::= CHOICE {
utcTime UTCTime,
generalTime GeneralizedTime }
Référez-vous à ces documents des sites de normes de l'Union internationale des télécommunications (ITU-T) :
Recherche de recommandations ITU-T - Recherchez X.509 dans Rec. ou norme avec le langage réglé à ASN.1.
L'ITU-T a défini une méthode standard des structures de données de codage décrites dans ASN.1 dans des données binaires. X.690 définit des règles d'encodage simple (JUJUBES) et ses deux sous-ensembles, règles canoniques de codage (CER) et règles distinguées de codage (DER). Chacun des trois est basé sur des zones d'information de type-longueur-valeur emballées dans une structure hiérarchique, qui est établie des ordres, des positionnements, et des choix, avec ces différences :
Exemple : Dans DER, 20-bit la valeur 1010 1011 1100 1101 1110 est encodée en tant que :
0x03
(bitstring)0x04
(octets)0x04ABCDE 0
0x030404ABCDE0
Les 04
principaux signifie que les 4 derniers bits (égale les 0
chiffres de remorquage) de la valeur encodée doivent être jetés parce que la valeur encodée ne finit pas sur une borne d'octet.
Référez-vous à ces documents du site de normes TU-T :
Du site de Wikipedia, référez-vous à ces documents :
Le Cisco IOS, l'appliance de sécurité adaptable (ASA), et d'autres périphériques affichent le contenu DER comme vidage hexadécimal avec la commande show running-config. Voici la sortie :
crypto pki certificate chain root
certificate ca 01
30820213 3082017C A0030201 02020101 300D0609 2A864886 F70D0101 04050030
1D310C30 0A060355 040B1303 54414331 0D300B06 03550403 1304726F 6F74301E
170D3039 30373235 31313436 33325A17 0D313230 37323431 31343633 325A301D
...
Ce genre de vidage hexadécimal peut être converti de nouveau à DER dans diverses manières. Par exemple, vous pouvez enlever les caractères espace et les siffler au programme de xxd :
$ cat ca.hex | tr -d ' ' | xxd -r -p -c 32 | openssl x509 -inform der -text -noout
Une autre méthode facile est d'utiliser ce script Perl :
#!/usr/bin/perl
foreach (<>) {
s/[^a-fA-F0-9]//g;
print join("", pack("H*", $_));
}
$ perl hex2der.pl < hex-file.txt > der-file.der
En outre, une manière compacte de convertir des vidages mémoire de CERT, chacun a précédemment manuellement copié sur un fichier avec l'extension .hex, d'une ligne de commande de coup comme affiché ici :
for hex in *.hex; do
b="${hex%.hex}"
hex2der.pl < "$hex" > "$b".der
openssl x509 -inform der -in "$b".der > "$b".pem
openssl x509 -in "$b".pem -text -noout > "$b".txt
done
Chaque fichier a comme conséquence :
Le codage Base64 représente les données binaires avec seulement 64 caractères imprimables (A-Za-z0-9+/
) pareillement à l'uuencode. Dans la conversion de la binaire en Base64, chaque bloc 6-bit des données d'origine est encodé dans un caractère ASCII imprimable de 8 bits avec une table de traduction. Par conséquent, la taille des données après encoder a augmenté de 33 pour cent (données chronomètre 8 divisés par 6 bits, égaux 1.333).
Une mémoire tampon 24-bit est utilisée pour la traduction de trois (3) groupes de huit (8) bits dans quatre (4) groupes de six (6) bits. Par conséquent un (1) ou deux (2) octets de remplissage pourraient être exigés à la fin du flux de données en entrée. La remplissage est indiquée à la fin des données Base64-encoded, par les égaux un (=)
signent pour des bits de chaque remplissage du Groupe des Huit (8) ajoutés à l'entrée pendant le codage.
Référez-vous à cet exemple de Wikipedia.
Référez-vous à la plupart d'informations récentes dans RFC 4648 : Les codages des données Base16, Base32, et Base64.
Le Privacy Enhanced Mail (PEM) est une pleine norme de PKI de l'Internet Engineering Task Force (IETF) afin de permuter les messages sécurisés. Il n'est plus très utilisé en soi, mais sa syntaxe d'encapsulation a été largement empruntée afin de formater et permuter des données liées à la PKI Base64-encoded.
Le RFC 1421 PEM, section 4.4 : Le mécanisme d'encapsulation, définit des messages PEM comme délimités par des bornes d'encapsulation (EBs), qui sont basés sur RFC 934, avec ce format :
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Header: value
Header: value
...
Base64-encoded data
...
-----END PRIVACY-ENHANCED MESSAGE-----
Dans la pratique aujourd'hui, quand des données PEM-formatées sont distribuées, ce format de borne est utilisé :
-----BEGIN type-----
...
-----END type-----
le type peut être avec d'autres clés ou Certificats comme :
CLÉ PRIVÉE RSA
CLÉ PRIVÉE CHIFFRÉE
CERTIFICAT
DEMANDE DE CERTIFICAT
X509 CRL
Note: Bien que les RFC ne fassent pas cet obligatoire, le nombre de tirets principaux et de remorquages (-
) dans l'EBs est significatif et devrait toujours être cinq (5). Autrement, quelques applications, telles qu'OpenSSL, obstruent sur l'entrée. D'autre part, d'autres applications, telles que le Cisco IOS, n'exigent pas EBs du tout.
Référez-vous à ces RFC les plus récents pour de plus amples informations :
X.509 est un sous-ensemble de X.500, qui est une spécification étendue ITU au sujet d'Open Systems Interconnection. Il traite spécifiquement des Certificats et des clés publiques et a été adapté comme norme Internet par l'IETF. X.509 fournit à une structure et à une syntaxe, exprimées en RFC la notation ASN.1, afin d'enregistrer les informations de certificat et des listes des révocations de certificat.
Dans un PKI X.509, un CA délivre un certificat qui lie une clé publique, par exemple : un Rivest-Shamir-Adleman (RSA) ou clé de l'algorithme de signature numérique (DSA) à un nom unique particulier (DN), ou à un nom alternatif tel qu'une adresse e-mail ou un nom de domaine complet (FQDN). Le DN suit la structure dans les normes X.500. Voici un exemple :
CN=common-name, OU=organizational-unit, O=organization, L=location, C=country
En raison de la définition ASN.1, les données X.509 peuvent être encodées dans DER afin de pour être permutées en forme binaire, et sur option, convertie en Base64/PEM pour des moyens de communication basés par texte, tels que la copie-pâte sur un terminal.
Les normes de cryptographie à clé publique (PKCS) sont des caractéristiques des laboratoires RSA qui se sont en partie transformés en des standards de l'industrie. Ceux le plus souvent produits, affaire avec ces thèmes ; cependant, pas tous affaire avec des formats des données.
PKCS#1 (RFC 3347) - Couvre les aspects d'implémentation du chiffrement basé sur RSA (cryptos primitifs, schémas de cryptage/signature, syntaxe ASN.1).
PKCS#5 (RFC 2898) - Couvre la dérivation de clé basée sur mot de passe.
PKCS#7 (RFC 2315) et RFC 3852 S/MIME - définit une syntaxe de message pour transmettre signé et des données cryptées et des Certificats associés. Employé souvent simplement comme conteneur pour les Certificats X.509.
PKCS#8- définit une syntaxe de message pour transporter le libellé ou les keypairs chiffrés RSA.
PKCS#9 (RFC 2985) - Définit les classes d'objets et les attributs d'identité supplémentaires.
PKCS#10 (RFC 2986) - Définit une syntaxe de message pour des demandes de signature de certificat (CSRs). Un CSR est envoyé par une entité à un CA et contient les informations à signer par le CA, tel que l'information principale publique, l'identité, et les attributs supplémentaires.
PKCS#12 - Définit un conteneur pour des données relatives de empaquetage de PKI (typiquement, keypair d'entité + CERT + racine d'entité et les Certificats CA intermédiaires) dans un fichier unique. C'est une évolution du format de l'échange des données personnelles de Microsoft (PFX).
Référez-vous à ces ressources :