Fino ad ora non ho trovato una specifica (RFC o simile) per il formato di file che utilizza il prefisso BEGIN RSA PRIVATE KEY e il suffisso END RSA PRIVATE KEY . Dove è definito? Cè un nome ufficiale per esso? Sembra essere almeno correlato alla serie di RFC PEM.
Sto cercando informazioni di riferimento sui dettagli della gestione degli spazi bianchi, dettagli base64 , unione di chiavi diverse in un file, ecc.
Questa domanda NON riguarda la codifica ASN del payload.
Commenti
- La specifica OpenPGP descrive formati ASCII-Armor simili.
- tls.mbed.org/kb/cryptography/asn1-key-structures-in- der-and-pem
- La maggior parte dei formati PEM (anche diversi dalla chiave privata RSA) sono documentati in RFC 7468: Textual Encodings of Strutture PKIX, PKCS e CMS . Sono disponibili, ad esempio, alcune linee guida sullargomento della gestione degli spazi bianchi. i dettagli variano a seconda del parser.
- Grazie a user4982: questo è il tipo di sorgente che sto cercando. Tuttavia, RFC 7468 contiene informazioni relative alletichetta ” CHIAVE PRIVATA CRITTOGRAFATA “, ma non ‘ t per ” RSA PRIVATE KEY “.
- PEM è definito in RFC 1421 che descrive il formato generale dellintestazione e così via. Ma non sono riuscito a ‘ trovare informazioni su ” RSA PRIVATE KEY “. Questo articolo del 1997 menziona già OpenSSL che lo utilizza.
Risposta
Sono qui, perché, mi pongo la stessa domanda dellOP.
PKCS # 1 (RFC 3447) definisce la struttura ASN.1: RSAPrivateKey, permettendo solo lespressione di una chiave privata RSA.
PKCS # 8 (RFC 5208) definisce la struttura ASN.1: PrivateKeyInfo, consentendo lespressione di qualsiasi chiave privata. (Per una chiave privata RSA, PrivateKeyInfo è alcune informazioni sulla confezione e un riutilizzo di RSAPrivateKey da PKCS # 1).
PEM (Privacy Enhanced Mail), è un metodo defunto per la posta elettronica sicura. Tuttavia, il suo formato contenitore è stato preso in prestito per il confezionamento di elementi crittografici.
RFC 7468 (Introduzione): “ Per ragioni che fondamentalmente si riducono a non coordinamento o disattenzione, molte librerie PKIX, PKCS e CMS implementare una codifica basata sul testo che è simile, ma non identica alla, codifica PEM . “
Che si legge come: Um, la gente ha deciso di utilizzare bit di PEM per impacchettare i propri file crittografici . Qui abbiamo un ottimo sforzo per provare a formalizzare che …
Ahimè, RFC 7468 chiarisce il pacchetto PKCS # 8 / PrivateKeyInfo come “BEGIN PRIVATE KEY”. Ma non il pacchetto di PKCS # 1 / RSAPrivateKey come “BEGIN RSA PRIVATE KEY”.
Il pacchetto “BEGIN RSA PRIVATE KEY” è talvolta chiamato: “formato SSLeay” o “formato tradizionale” per chiave privata. Il che, almeno, ci dà un nome per questo formato, ma, come te, non riesco a trovare, e accetterei con favore, qualcosa che si avvicini a una descrizione formale di questo formato. Sospetto che non esista.
Commenti
-
I'm here, because, I'm asking myself the same question as the OP.– – Per chiarire: è questa la tua risposta alla domanda posta sopra o ti stai effettivamente ponendo la stessa domanda?
Risposta
Il formato dei contenuti in base64 allinterno:
-----BEGIN RSA PRIVATE KEY----- ...base64 encoded DER ASN.1 RSAPrivateKey... -----END RSA PRIVATE KEY----- è documentato in RFC3447 – Appendice A.1.2 – Sintassi della chiave privata 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 } Sai già come codificarla utilizzando il DER sapore di ASN.1; e la domanda è su come scrivere effettivamente i dati binari DER in un file.
Il passaggio successivo è documentato in RFC 1421 – 4.3.2.4 Passaggio 4 : Codifica stampabile
- documentano la codifica dei dati binari in base64
- codifica loutput come righe di testo
- con ogni riga ( tranne lultimo) contenente esattamente 64 caratteri stampabili
- e lultima riga contenente 64 o meno caratteri stampabili
Viene quindi utilizzato “Encapsulation Boundary” (EB) per delimitare i messaggi PEM incapsulati.
- la stringa pre-EB è:
-----BEGIN PRIVACY-ENHANCED MESSAGE----- - la stringa post-EB è:
-----END PRIVACY-ENHANCED MESSAGE-----
Era il defuct Privacy Enhanced Mail che utilizzava:
- cinque trattini (
-----) -
BEGINsomething - cinque trattini (
-----)
seguito da
- cinque trattini (
-----) -
ENDsomething - cinque trattini (
-----)
Queste convenzioni PEM sono state trasferite per chiave pubblica, chiave privata e certificati, ma con testo modificato:
-----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----- Risposta
Sì. RFC7468 – Codifiche testuali di strutture PKIX, PKCS e CMS
Questo documento articola le regole de facto con cui operano le implementazioni esistenti e le definisce in modo che le implementazioni future possano interagire.
Ecco “un estratto pertinente:
10. Una chiave asimmetrica e la codifica testuale delle informazioni sulla chiave privata PKCS # 8
Le strutture di sintassi delle informazioni sulla chiave privata PKCS # 8 non crittografate (PrivateKeyInfo), rinominate in Pacchetti di chiavi asimmetriche (OneAsymmetricKey), sono codificate utilizzando letichetta “PRIVATE KEY”. I dati codificati DEVONO essere un BER ( DER preferito; vedere Appendice B) struttura codificata ASN.1 PrivateKeyInfo come descritto in PKCS # 8 [RFC5208], o una struttura OneAsymmetricKey come descritto in [RFC5958]. I due sono semanticamente identici e possono essere distinti per numero di versione.
-----BEGIN PRIVATE KEY----- MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ -----END PRIVATE KEY----- Commenti
- Sto chiedendo informazioni su ” RSA PRIVATE KEY “, non su ” RICHIESTA DI CERTIFICATO “. A proposito, mi aspetterei PKCS # 8 o PKCS # 1, non PKCS # 10. Il capitolo 10 sarebbe più vicino. Ma ‘ non specifica RSA nelletichetta, quindi ha senso usare PKCS # 8 qui. Poiché lalgoritmo chiave sarebbe specificato in modo ridondante, potrebbe essere corretto (e ho visto esempi) inserire PKCS # 1 in una ” CHIAVE PRIVATA RSA ” file.
- @Come ho già detto, sto cercando ” RSA PRIVATE KEY “, non per ” PRIVATE KEY “. Quindi, anche il capitolo 10 non è applicabile e RFC7468 è una risposta sbagliata.
- @Gustave I ‘ so che hai scritto ” CHIAVE PRIVATA RSA “, tuttavia non è necessario specificare il formato della chiave privata nellintestazione e la specifica è pertinente.
- LABNF legge < < textualmsg = preeb * WSP (…) > > e < < preeb = ” —- -BEGIN ” label ” —– ” (…) > >. Allora, perché pensi che lintestazione non sia necessaria?
- PKCS # 1 ( tools.ietf.org/html/rfc8017#appendix-A.1.2 ) ‘ t specifica alcuna codifica ASCII base64 e ‘ t specifica
-----BEGIN RSA PRIVATE KEY-----intestazione. PKCS # 8 non ‘ specifica nemmeno la codifica ASCII base64. Il capitolo 10 specifica infatti-----BEGIN PRIVATE KEY-----. Hai un collegamento a uno standard che specifica lintestazione-----BEGIN RSA PRIVATE KEY-----?