décembre 26, 2020
Articles
Aucun commentaire

Existe-t-il une spécification pour le format “ BEGIN RSA PRIVATE KEY ”?

Jusquà présent, je nai pas trouvé de spécification (RFC ou similaire) pour le format de fichier qui utilise le préfixe BEGIN RSA PRIVATE KEY et le suffixe END RSA PRIVATE KEY . Où est-il défini? Y a-t-il un nom officiel pour cela? Il semble être au moins lié à la série de RFC PEM.

Je cherche des informations de référence sur les détails de la gestion des espaces, les détails base64 , jonction de différentes clés dans un fichier etc.

Cette question ne concerne PAS lencodage ASN de la charge utile.

Commentaires

  • La spécification OpenPGP décrit des formats ASCII-Armor similaires.
  • tls.mbed.org/kb/cryptography/asn1-key-structures-in- der-and-pem
  • La plupart des formats PEM (également autres que la clé privée RSA) sont documentés dans RFC 7468: Textual Encodings of Structures PKIX, PKCS et CMS . Il existe par exemple des conseils sur la gestion des espaces blancs. Cette RFC note essentiellement que les détails varient selon lanalyseur.
  • Merci à user4982: Cest le genre de source que je recherche. Cependant, la RFC 7468 contient des informations concernant le libellé  » ENCRYPTED PRIVATE KEY « , mais ce nest pas le cas ‘ t pour  » RSA PRIVATE KEY « .
  • PEM est défini dans RFC 1421 qui décrit le format global de len-tête, etc. Mais je nai pas pu ‘ trouver le  » CLÉ PRIVÉE RSA « . Cet article de 1997 mentionne déjà OpenSSL qui lutilise.

Réponse

Je « suis ici, parce que je me pose la même question que lOP.

PKCS # 1 (RFC 3447) définit la structure ASN.1: RSAPrivateKey, permettant lexpression dune clé privée RSA uniquement.

PKCS # 8 (RFC 5208) définit la structure ASN.1: PrivateKeyInfo, permettant lexpression de toute clé privée. (Pour une clé privée RSA, PrivateKeyInfo est une information dempaquetage, et une réutilisation de RSAPrivateKey de PKCS # 1).

PEM (Privacy Enhanced Mail), est une méthode obsolète pour le courrier électronique sécurisé. Mais son format de conteneur a été emprunté pour empaqueter des éléments cryptographiques.

RFC 7468 (Introduction): «  Pour des raisons qui se résument essentiellement à la non-coordination ou à linattention, de nombreuses bibliothèques PKIX, PKCS et CMS implémenter un encodage textuel qui est similaire – mais pas identique – à lencodage PEM . « 

Ce qui se lit comme suit: Euh, les gens ont décidé dutiliser des bits de PEM pour empaqueter leurs fichiers cryptographiques . Ici, nous avons un très bon effort pour essayer de formaliser cela …

Hélas, la RFC 7468 clarifie le packaging PKCS # 8 / PrivateKeyInfo comme « BEGIN PRIVATE KEY ». Mais pas le packaging de PKCS # 1 / RSAPrivateKey comme « BEGIN RSA PRIVATE KEY ».

Le packaging « BEGIN RSA PRIVATE KEY » est parfois appelé: « format SSLeay » ou « format traditionnel » pour la clé privée. Ce qui, au moins, nous donne un nom pour ce format, mais, comme vous, je ne trouve pas, et je serais heureux, quelque chose qui se rapproche dune description formelle de ce format. Je soupçonne que cela nexiste pas.

Commentaires

  • I'm here, because, I'm asking myself the same question as the OP. – – Pour clarifier: est-ce votre réponse à la question posée ci-dessus ou vous posez-vous réellement la même question?

Réponse

Le format du contenu base64 à lintérieur: 

-----BEGIN RSA PRIVATE KEY----- ...base64 encoded DER ASN.1 RSAPrivateKey... -----END RSA PRIVATE KEY-----

est documenté dans RFC3447 – Annexe A.1.2 – Syntaxe de la clé privée RSA : 

RSAPrivateKey ::= SEQUENCE { version Version, modulus INTEGER, -- n publicExponent INTEGER, -- e privateExponent INTEGER, -- d prime1 INTEGER, -- p prime2 INTEGER, -- q exponent1 INTEGER, -- d mod (p-1) exponent2 INTEGER, -- d mod (q-1) coefficient INTEGER, -- (inverse of q) mod p otherPrimeInfos OtherPrimeInfos OPTIONAL }

Vous savez déjà comment encoder cela en utilisant le DER saveur de lASN.1; et la question est de savoir comment écrire réellement ces données binaires DER dans un fichier.

Cette étape suivante est documentée dans RFC 1421 – 4.3.2.4 Étape 4 : Encodage imprimable

  • ils documentent lencodage des données binaires en base64
  • encodant la sortie sous forme de lignes de texte
  • avec chaque ligne ( sauf le dernier) contenant exactement 64 caractères imprimables
  • et la dernière ligne contenant 64 caractères imprimables ou moins

Il y a alors la «frontière dencapsulation» (EB), utilisée pour délimiter les messages PEM encapsulés.

  • la chaîne pré-EB est: -----BEGIN PRIVACY-ENHANCED MESSAGE-----
  • la chaîne post-EB est: -----END PRIVACY-ENHANCED MESSAGE-----

Cétait le defuct Privacy Enhanced Mail qui utilisait:

  • cinq tirets (-----)
  • BEGIN something
  • cinq tirets (-----)

suivis de

  • cinq tirets (-----)
  • END something
  • cinq tirets (-----)

Ces conventions PEM ont été reportées pour la clé publique, la clé privée et les certificats, mais avec des formulation modifiée: 

-----BEGIN RSA PUBLIC KEY----- ...base64 encoded DER ASN.1 RSAPublicKey... -----END RSA PUBLIC KEY-----

  

-----BEGIN RSA PRIVATE KEY----- ...base64 encoded DER ASN.1 RSAPrivateKey... -----END RSA PRIVATE KEY-----

  

-----BEGIN PUBLIC KEY----- ...base64 encoded DER ASN.1 SubjectPublicKeyInfo... -----END PUBLIC KEY-----

  

-----BEGIN PRIVATE KEY----- ...base64 encoded DER ASN.1 PrivateKeyInfo... -----END PUBLIC KEY-----

  

-----BEGIN CERTIFICATE----- ...base64 encoded DER ASNl.1 Certificate... -----END CERTIFICATE-----

Réponse

Oui. RFC7468 – Encodages textuels de structures PKIX, PKCS et CMS

Ce document articule les règles de facto selon lesquelles les implémentations existantes opèrent et les définit pour que les futures implémentations puissent interagir.

Voici « un extrait pertinent:

10. Une clé asymétrique et lencodage textuel de PKCS # 8 Informations sur la clé privée

Les structures de syntaxe des informations de clé privée PKCS # 8 non chiffrées (PrivateKeyInfo), renommées en packages de clés asymétriques (OneAsymmetricKey), sont codées à laide du libellé « PRIVATE KEY ». Les données codées DOIVENT être un BER ( DER préféré; voir lannexe B) structure ASN.1 PrivateKeyInfo codée comme décrit dans PKCS # 8 [RFC5208], ou une structure OneAsymmetricKey comme décrit dans [RFC5958]. Les deux sont sémantiquement identiques et peuvent être distingués par numéro de version. 

-----BEGIN PRIVATE KEY----- MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ -----END PRIVATE KEY-----

Commentaires

  • Je pose une question sur  » CLÉ PRIVÉE RSA « , pas à propos de  » DEMANDE DE CERTIFICAT « . Au fait, je mattendrais à PKCS # 8 ou PKCS # 1, pas PKCS # 10. Le chapitre 10 serait plus proche. Mais cela ‘ ne spécifie pas RSA dans létiquette, il est donc logique dutiliser PKCS # 8 ici. Comme lalgorithme de clé serait spécifié de manière redondante, il pourrait être OK (et jai vu des exemples) de mettre PKCS # 1 dans un  » CLÉ PRIVÉE RSA  » fichier.
  • @Comme je lai déjà dit, je recherche  » CLÉ PRIVÉE RSA « , pas pour  » CLÉ PRIVÉE « . Donc, même le chapitre 10 nest pas applicable, et RFC7468 est une mauvaise réponse.
  • @Gustave Je ‘ je sais que vous avez écrit  » CLÉ PRIVÉE RSA « , cependant la spécification du format de la clé privée dans len-tête est inutile et la spécification est pertinente.
  • LABNF lit < < textualmsg = preeb * WSP (…) > > et < < preeb =  » —- -BEGIN  » label  » —–  » (…) > >. Alors, pourquoi pensez-vous que len-tête est inutile?
  • PKCS # 1 ( tools.ietf.org/html/rfc8017#appendix-A.1.2 ) ne ‘ t spécifie aucun encodage ASCII base64, et il ne spécifie pas ‘ le -----BEGIN RSA PRIVATE KEY----- en-tête. PKCS # 8 ne spécifie ‘ aucun encodage ASCII base64 non plus. Le chapitre 10 spécifie en effet -----BEGIN PRIVATE KEY-----. Avez-vous un lien vers une norme qui spécifie len-tête -----BEGIN RSA PRIVATE KEY-----?

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *