Inntil nå fant jeg ikke en spesifikasjon (RFC eller lignende) for filformatet som bruker prefikset BEGIN RSA PRIVATE KEY og END RSA PRIVATE KEY suffiks Hvor er det definert? Er det et offisielt navn på det? Det ser ut til å være i det minste relatert til serien med PEM RFCer.
Jeg leter etter referanseinformasjon om detaljene i håndtering av hvitt rom, detaljer om base64 , sammenføyning av forskjellige nøkler i en fil osv.
Dette spørsmålet handler IKKE om ASN-koding av nyttelasten.
Kommentarer
- OpenPGP-spesifikasjonen beskriver lignende ASCII-Armor-formater.
- tls.mbed.org/kb/cryptography/asn1-key-structures-in- der-and-pem
- Det meste av PEM-format (også annet enn RSA Private Key) er dokumentert i RFC 7468: Textual Encodings of PKIX-, PKCS- og CMS-strukturer . Det er f.eks. Noen veiledninger om emnet for håndtering av mellomrom. at detaljene varierer i henhold til parser.
- Takk til bruker4982: Dette er den typen kilde jeg leter etter. RFC 7468 inneholder imidlertid informasjon om etiketten » Kryptert privat nøkkel «, men det
t for » RSA PRIVATE NØKKEL «.
Svar
Jeg er her, fordi jeg stiller meg selv det samme spørsmålet som OP.
PKCS # 1 (RFC 3447) definerer ASN.1-strukturen: RSAPrivateKey, tillater kun uttrykk for en RSA privat nøkkel.
PKCS # 8 (RFC 5208) definerer ASN.1-strukturen: PrivateKeyInfo, som tillater uttrykk for en hvilken som helst privat nøkkel. (For en RSA-privatnøkkel er PrivateKeyInfo noe informasjon om emballasje, og gjenbruk av RSAPrivateKey fra PKCS # 1).
PEM (Privacy Enhanced Mail) er en utgått metode for sikker e-post. Men containerformatet ble lånt for emballering av kryptografiske gjenstander.
RFC 7468 (Introduksjon): « Av grunner som i utgangspunktet koker ned til manglende koordinering eller uoppmerksomhet, er det mange PKIX-, PKCS- og CMS-biblioteker implementere en tekstbasert koding som ligner på – men ikke identisk med – PEM-koding . «
Som lyder som: Um, folk har bestemt seg for å bruke biter av PEM til å pakke deres kryptofiler . Her har vi en veldig god innsats for å prøve å formalisere det …
Alas, RFC 7468 presiserer PKCS # 8 / PrivateKeyInfo-emballasjen som «BEGIN PRIVATE KEY». Men ikke emballasjen til PKCS # 1 / RSAPrivateKey som «BEGIN RSA PRIVATE KEY».
Emballasjen «BEGIN RSA PRIVATE KEY» kalles noen ganger: «SSLeay format» eller «tradisjonelt format» for privat nøkkel. Som i det minste gir oss et navn på dette formatet, men som deg selv, kan jeg ikke finne, og vil ønske det, noe som nærmer seg en formell beskrivelse av dette formatet. Jeg mistenker at dette ikke eksisterer.
Kommentarer
-
I'm here, because, I'm asking myself the same question as the OP.– – For å avklare: er dette svaret på spørsmålet du har stilt ovenfor, eller stiller du deg selv det samme spørsmålet?
Svar
Formatet til base64-innholdet inne:
-----BEGIN RSA PRIVATE KEY----- ...base64 encoded DER ASN.1 RSAPrivateKey... -----END RSA PRIVATE KEY----- er dokumentert i RFC3447 – Vedlegg A.1.2 – RSA privatnøkkel-syntaks :
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 } Du vet allerede hvordan du skal kode det ved hjelp av DER smak av ASN.1; og spørsmålet handler om hvordan du faktisk skriver at DER binære data til en fil.
Det neste trinnet er dokumentert i RFC 1421 – 4.3.2.4 Trinn 4 : Utskrivbar koding
- de dokumenterer koding av binære data i base64
- som koder utdata som tekstlinjer
- med hver linje ( bortsett fra det siste) som inneholder nøyaktig 64 utskrivbare tegn
- og den endelige linjen som inneholder 64 eller færre utskrivbare tegn
Der er da «Encapsulation Boundary» (EB), brukt for å avgrense innkapslede PEM-meldinger.
- strengen før EB er:
-----BEGIN PRIVACY-ENHANCED MESSAGE----- - strengen etter EB er:
-----END PRIVACY-ENHANCED MESSAGE-----
Det var mangelen Privacy Enhanced Mail som brukte:
- fem bindestreker (
-----) -
BEGINsomething - fem bindestreker (
-----)
etterfulgt av
- fem bindestreker (
-----) -
ENDsomething - fem bindestreker (
-----)
Disse PEM-konvensjonene ble overført til offentlig nøkkel, privat nøkkel og sertifikater, men med passende endret ordlyd:
-----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----- Svar
Ja. RFC7468 – Tekstkoding av PKIX-, PKCS- og CMS-strukturer
Dette dokumentet artikulerer de facto-reglene som eksisterende implementeringer fungerer etter og definerer dem slik at fremtidige implementeringer kan samhandle.
Her «er et relevant utdrag:
10. En asymmetrisk nøkkel og tekstkoding av PKCS # 8 Privat nøkkelinformasjon
Ukryptert PKCS # 8 privat nøkkelinformasjon Syntaksstrukturer (PrivateKeyInfo), omdøpt til asymmetriske nøkkelpakker (OneAsymmetricKey), er kodet ved hjelp av «PRIVATE KEY» -merket. De kodede dataene MÅ være en BER ( DER foretrukket, se vedlegg B) kodet ASN.1 PrivateKeyInfo-struktur som beskrevet i PKCS # 8 [RFC5208], eller en OneAsymmetricKey-struktur som beskrevet i [RFC5958]. De to er semantisk identiske og kan skilles ut med versjonsnummer.
-----BEGIN PRIVATE KEY----- MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ -----END PRIVATE KEY----- Kommentarer
- Jeg spør om » RSA PRIVATE KEY «, ikke om » SERTIFIKAT FORESPØRSEL «. Forresten, jeg forventer PKCS # 8 eller PKCS # 1, ikke PKCS # 10. Kapittel 10 ville være nærmere. Men det ‘ spesifiserer ikke RSA i etiketten, så det er fornuftig å bruke PKCS # 8 her. Ettersom nøkkelalgoritmen ville bli spesifisert overflødig, kan det være OK (og jeg så eksempler) å sette PKCS # 1 i en » RSA PRIVATE KEY » fil.
- @ Som jeg allerede har sagt, leter jeg etter » RSA PRIVATE NØKKEL «, ikke for » PRIVATE NØKKEL «. Så selv kapittel 10 er ikke aktuelt, og RFC7468 er et feil svar.
- @Gustave Jeg ‘ Jeg er klar over at du skrev » RSA PRIVATE NØKKEL «, men å spesifisere formatet til den private nøkkelen i overskriften er unødvendig og spesifikasjonen er relevant.
- ABNF leser < < textualmsg = preeb * WSP (…) > > og < < preeb = » —- -BEGIN » label » —– » (…) > >. Så hvorfor tror du overskriften er unødvendig?
- PKCS # 1 ( tools.ietf.org/html/rfc8017#appendix-A.1.2 ) spesifiserer ikke ‘ t hvilken som helst ASCII base64-koding, og den spesifiserer heller ikke ‘ t
-----BEGIN RSA PRIVATE KEY-----topptekst. PKCS # 8 spesifiserer ikke ‘ noen ASCII base64-koding heller. Kapittel 10 spesifiserer faktisk-----BEGIN PRIVATE KEY-----. Har du en lenke til en standard som spesifiserer-----BEGIN RSA PRIVATE KEY-----overskrift?