web-dev-qa-db-fra.com

Où le format de fichier PEM est-il spécifié?

J'ai besoin d'analyser les fichiers .PEM.
Je sais que la norme pour le "courrier électronique à confidentialité renforcée" est définie dans les RFC 1421-24. Mais ils ne semblent pas mentionner du texte que je trouve dans les fichiers OpenSSL .pem (par exemple "Attributs clés", "BEGIN CERTIFICATE", etc ...) Est-ce un format spécifique à OpenSSL?

securityopensslcryptographycertificate
49
hopia

Pendant assez longtemps, il n'y avait pas de spécification formelle du format PEM en ce qui concerne l'échange cryptographique d'informations. PEM est l'encodage textuel, mais ce qui est réellement encodé dépend du contexte. En avril 2015, l'IETF a approuvé RFC 7468 , qui documente enfin comment diverses implémentations échangent des données à l'aide du codage textuel PEM. La liste suivante, extraite directement du RFC, décrit le format PEM utilisé pour les scénarios suivants:

  1. Certificats, listes de révocation de certificats (CRL) et structures d'informations de clé publique sujet dans le profil de la liste de révocation de certificats et de certificats d'infrastructure de clé publique Internet X.509 [RFC5280] .
  2. PKCS # 10: Syntaxe de demande de certification [RFC2986] .
  3. PKCS # 7: Syntaxe des messages cryptographiques [RFC2315] .
  4. Syntaxe des messages cryptographiques [RFC5652] .
  5. PKCS # 8: Syntaxe des informations de clé privée [RFC5208] , renommée en Une seule clé asymétrique dans le package de clé asymétrique [RFC5958] , et Syntaxe des informations de clé privée cryptée dans la même documents.
  6. Certificats d'attribut dans un profil de certificat d'attribut Internet pour l'autorisation [RFC5755] .

Selon cette RFC, pour les scénarios ci-dessus, vous pouvez vous attendre à ce que les étiquettes suivantes soient dans l'en-tête [~ # ~] commence [~ # ~] et [~ # ~] fin [~ # ~] pied de page. La figure 4 de la RFC a plus de détails, y compris les types ASN.1 correspondants.

Ce n'est pas l'histoire complète, cependant. Le RFC a été écrit en examinant les implémentations existantes et en documentant ce qu'elles ont fait. Le RFC n'a pas été écrit en premier, ni sur la base d'une documentation existante faisant autorité. Donc, si vous vous retrouvez dans une situation où vous souhaitez interagir avec une implémentation, vous devrez peut-être examiner le code source de l'implémentation pour comprendre ce qu'il prend en charge.

Par exemple, OpenSSL définit ces marqueurs BEGIN et END dans crypto/pem/pem.h . Voici un extrait du fichier d'en-tête avec toutes les étiquettes BEGIN et END qu'ils prennent en charge.

# define PEM_STRING_X509_OLD     "X509 CERTIFICATE"
# define PEM_STRING_X509         "CERTIFICATE"
# define PEM_STRING_X509_TRUSTED "TRUSTED CERTIFICATE"
# define PEM_STRING_X509_REQ_OLD "NEW CERTIFICATE REQUEST"
# define PEM_STRING_X509_REQ     "CERTIFICATE REQUEST"
# define PEM_STRING_X509_CRL     "X509 CRL"
# define PEM_STRING_EVP_PKEY     "ANY PRIVATE KEY"
# define PEM_STRING_PUBLIC       "PUBLIC KEY"
# define PEM_STRING_RSA          "RSA PRIVATE KEY"
# define PEM_STRING_RSA_PUBLIC   "RSA PUBLIC KEY"
# define PEM_STRING_DSA          "DSA PRIVATE KEY"
# define PEM_STRING_DSA_PUBLIC   "DSA PUBLIC KEY"
# define PEM_STRING_PKCS7        "PKCS7"
# define PEM_STRING_PKCS7_SIGNED "PKCS #7 SIGNED DATA"
# define PEM_STRING_PKCS8        "ENCRYPTED PRIVATE KEY"
# define PEM_STRING_PKCS8INF     "PRIVATE KEY"
# define PEM_STRING_DHPARAMS     "DH PARAMETERS"
# define PEM_STRING_DHXPARAMS    "X9.42 DH PARAMETERS"
# define PEM_STRING_SSL_SESSION  "SSL SESSION PARAMETERS"
# define PEM_STRING_DSAPARAMS    "DSA PARAMETERS"
# define PEM_STRING_ECDSA_PUBLIC "ECDSA PUBLIC KEY"
# define PEM_STRING_ECPARAMETERS "EC PARAMETERS"
# define PEM_STRING_ECPRIVATEKEY "EC PRIVATE KEY"
# define PEM_STRING_PARAMETERS   "PARAMETERS"
# define PEM_STRING_CMS          "CMS"

Ces étiquettes sont un début, mais vous devez toujours voir comment l'implémentation code les données entre les étiquettes. Il n'y a pas une seule bonne réponse pour tout.

24
indiv

Réponse mise à jour pour 2015 : Comme les utilisateurs ont déjà répondu deux fois, avant que le modérateur @royhowie n'ait supprimé les réponses: il y a maintenant RFC 7468 qui définit le En-têtes PEM . La citation suivante n'est qu'une petite partie, et vous devriez lire les spécifications réelles, qui resteront probablement sur Internet beaucoup plus longtemps que StackOverflow.

Cependant, @royhowie supprime chaque réponse qui pointe vers le RFC en tant que "lien uniquement", sauf s'il contient du texte. Voici donc du texte:

  1. Encodage textuel de la syntaxe de demande de certification PKCS # 10

    Les demandes de certification PKCS # 10 sont codées à l'aide de l'étiquette "DEMANDE DE CERTIFICAT". Les données codées DOIVENT être un BER (DER fortement préféré; voir l'Annexe B) ​​codé ASN.1 CertificationRequest structure comme décrit dans [RFC2986].

----- COMMENCER LA DEMANDE DE CERTIFICAT -----

MIIBWDCCAQcCAQAwTjELMAkGA1UEBhMCU0UxJzAlBgNVBAoTHlNpbW9uIEpvc2Vm c3NvbiBEYXRha29uc3VsdCBBQjEWMBQGA1UEAxMNam9zZWZzc29uLm9yZzBOMBAG ByqGSM49AgEGBSuBBAAhAzoABLLPSkuXY0l66MbxVJ3Mot5FCFuqQfn6dTs + 9/CM EOlSwVej77tj56kj9R/j9Q + LfysX8FO9I5p3oGIwYAYJKoZIhvcNAQkOMVMwUTAY BgNVHREEETAPgg1qb3NlZnNzb24ub3JnMAwGA1UdEwEB/wQCMAAwDwYDVR0PAQH/BAUDAwegADAWBgNVHSUBAf8EDDAKBggrBgEFBQcDATAKBggqhkjOPQQDAgM/ADA8 AhxBvfhxPFfbBbsE1NoFmCUczOFApEuQVUw3ZP69AhwWXk3dgSUsKnuwL5g/féjour dEQc8B8jAcnuOrfU

----- FIN DE LA DEMANDE DE CERTIFICAT -----

Figure 9: Exemple PKCS # 10

Le label "NOUVELLE DEMANDE DE CERTIFICAT" est également largement utilisé. Les générateurs conformes à ce document DOIVENT générer des étiquettes "DEMANDE DE CERTIFICAT". Les analyseurs PEUVENT traiter la "NOUVELLE DEMANDE DE CERTIFICAT" comme équivalente à "LA DEMANDE DE CERTIFICAT". ^

20
mikemaccana

Pour commencer: pour autant que je sache, s'il y a une partie lisible par l'homme (avec des mots et des trucs), c'est destinée aux opérateurs humains de savoir quelle est la certification en question, les dates d'expiration, etc., pour une vérification manuelle rapide . Vous pouvez donc ignorer cela.

Vous voudrez analyser ce qui se trouve entre les blocs BEGIN-END.

À l'intérieur, vous trouverez une entité encodée Base64 dont vous avez besoin pour décoder Base64 en octets. Ces octets représentent un certificat/clé/etc codé en DER. Je ne sais pas quelles bonnes bibliothèques vous pourriez utiliser pour analyser les données DER.

Pour tester les données contenues dans chaque bloc, vous pouvez coller ce qui se trouve entre les blocs BEGIN-END sur ce site qui effectue le décodage ASN.1 en JavaScript:

http://lapo.it/asn1js/

Bien que je n'irais pas coller des clés privées d'environnement de production à n'importe quel site (bien que cela semble être juste un javascript).

Base64: http://en.wikipedia.org/wiki/Base64

DER: http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules

ASN.1: http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One

13
Sami Koivu

J'ai trouvé un ancien fil concernant ce problème. Il semble qu'il n'y ait pas de format standard "officiel" pour les limites d'encapsulation et la meilleure façon de le déterminer est de deviner le contenu en fonction de mots clés bien connus que vous trouvez dans l'instruction BEGIN.

Comme l'indiv a répondu, pour la liste complète des mots-clés, reportez-vous au fichier d'en-tête OpenSSL crypto/pem/pem.h.

8
hopia

Je ne sais pas si c'est spécifique à OpenSSL, mais la documentation pour PEM Encryption Format peut être ce que vous recherchez.

2
jathanism

Où le format de fichier PEM est-il spécifié?

Il n'y a pas un seul endroit. Cela dépend de la norme. Vous pouvez même créer vos propres limites d'encapsulation et les utiliser dans votre propre logiciel.

Comme l'a indiqué @indiv, OpenSSL a une liste assez complète sur <openssl dir>/crypto/pem/pem.h.

Quelqu'un a demandé au groupe de travail PKIX de fournir une liste comme vous l'aviez demandé en 2006. Le groupe de travail a refusé. Voir demande de brouillon de format de fichier PEM rfc .

0
jww