Indtil nu kunne jeg ikke finde en specifikation (RFC eller lignende) til filformatet, der bruger BEGIN RSA PRIVATE KEY præfikset og END RSA PRIVATE KEY suffix Hvor er det defineret? Er der et officielt navn til det? Det synes i det mindste at være relateret til serien af PEM RFCer.
Jeg leder efter referenceoplysninger om detaljerne i håndtering af hvidt rum, detaljer om base64 , sammenføjning af forskellige nøgler i en fil osv.
Dette spørgsmål handler IKKE om ASN-kodning af nyttelasten.
Kommentarer
- OpenPGP-specifikationen beskriver lignende ASCII-rustningsformater.
- tls.mbed.org/kb/cryptography/asn1-key-structures-in- der-and-pem
- De fleste af PEM-formater (også andre end RSA Private Key) er dokumenteret i RFC 7468: Tekstkodning af PKIX-, PKCS- og CMS-strukturer . Der er f.eks. Nogle vejledninger om emnet hvidt rumhåndtering. Den RFC bemærker dybest set at detaljerne varierer alt efter parser.
- Tak til user4982: Dette er den slags kilde, jeg leder efter. RFC 7468 indeholder dog oplysninger om etiketten ” Krypteret privat nøgle “, men den ‘ t for ” RSA PRIVATE KEY “.
- PEM er defineret i RFC 1421 som beskriver det overordnede format på headeren osv. Men jeg kunne ikke ‘ ikke finde ud af ” RSA PRIVATE KEY “. Denne artikel fra 1997 nævner allerede OpenSSL ved hjælp af den.
Svar
Jeg er her, fordi jeg spørger mig selv det samme spørgsmål som OP.
PKCS # 1 (RFC 3447) definerer ASN.1-strukturen: RSAPrivateKey, tillader kun udtrykket af en RSA privat nøgle.
PKCS # 8 (RFC 5208) definerer ASN.1-strukturen: PrivateKeyInfo, der tillader udtryk for enhver privat nøgle. (For en RSA privat nøgle er PrivateKeyInfo nogle emballeringsoplysninger, og en genbrug af RSAPrivateKey fra PKCS # 1).
PEM (Privacy Enhanced Mail) er en afviklet metode til sikker e-mail. Men containerformatet blev lånt til emballering af kryptografiske genstande.
RFC 7468 (Introduktion): “ Af grunde, der grundlæggende koges ned til ikke-koordination eller uopmærksomhed, er der mange PKIX-, PKCS- og CMS-biblioteker implementere en tekstbaseret kodning, der ligner – men ikke er identisk med – PEM-kodning . “
Hvilket lyder som: Um, folk har besluttet at bruge bits af PEM til at pakke deres kryptofiler . Her har vi en rigtig god indsats for at forsøge at formalisere det …
Ak, RFC 7468 præciserer PKCS # 8 / PrivateKeyInfo-emballagen som “BEGIN PRIVATE KEY”. Men ikke emballagen til PKCS # 1 / RSAPrivateKey som “BEGIN RSA PRIVATE KEY”.
Emballagen “BEGIN RSA PRIVATE KEY” kaldes undertiden: “SSLeay format” eller “traditionelt format” til privat nøgle. Som i det mindste giver os et navn til dette format, men som dig selv kan jeg ikke finde og ville byde noget, der nærmer sig en formel beskrivelse af dette format. Jeg formoder, at dette ikke eksisterer.
Kommentarer
-
I'm here, because, I'm asking myself the same question as the OP.– – For at præcisere: er dette dit svar på det spørgsmål, der er stillet ovenfor, eller stiller du dig selv det samme spørgsmål?
Svar
Formatet for base64-indholdet inde:
-----BEGIN RSA PRIVATE KEY----- ...base64 encoded DER ASN.1 RSAPrivateKey... -----END RSA PRIVATE KEY----- er dokumenteret i RFC3447 – Appendiks A.1.2 – RSA privat nøglesyntaks :
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 ved allerede, hvordan du koder det ved hjælp af DER smag af ASN.1; og spørgsmålet er, hvordan man faktisk skriver, at DER-binære data til en fil.
Det næste trin er dokumenteret i RFC 1421 – 4.3.2.4 Trin 4 : Printbar kodning
- de dokumenterer kodning af de binære data i base64
- kodning af output som tekstlinjer
- med hver linje ( undtagen det sidste), der indeholder nøjagtigt 64 udskrivbare tegn
- og den sidste linje, der indeholder 64 eller færre udskrivbare tegn
Der er derefter “Encapsulation Boundary” (EB) for at afgrænse indkapslede PEM-meddelelser.
- før EB-streng er:
-----BEGIN PRIVACY-ENHANCED MESSAGE----- - post-EB-streng er:
-----END PRIVACY-ENHANCED MESSAGE-----
Det var defekten Privacy Enhanced Mail , der anvendte:
- fem bindestreger (
-----) -
BEGINsomething - fem bindestreger (
-----)
efterfulgt af
- fem bindestreger (
-----) -
ENDsomething - fem bindestreger (
-----)
Disse PEM-konventioner blev overført til offentlig nøgle, privat nøgle og certifikater, men med passende ændret 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 – Tekstkodning af PKIX-, PKCS- og CMS-strukturer
Dette dokument artikulerer de facto-reglerne, hvormed eksisterende implementeringer fungerer, og definerer dem, så fremtidige implementeringer kan interoperere.
Her “er et relevant uddrag:
10. En asymmetrisk nøgle og tekstkodning af PKCS # 8 Privat nøgleinformation
Ukrypteret PKCS # 8 Private Key Information Syntaksstrukturer (PrivateKeyInfo), omdøbt til Asymmetric Key Packages (OneAsymmetricKey), er kodet ved hjælp af “PRIVATE KEY” -mærket. De kodede data SKAL være en BER DER foretrækkes; se tillæg 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 skelnes ved versionsnummer.
-----BEGIN PRIVATE KEY----- MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ -----END PRIVATE KEY----- Kommentarer
- Jeg spørger om ” RSA PRIVATE KEY “, ikke om ” CERTIFIKATANMODNING “. Forresten ville jeg forvente PKCS # 8 eller PKCS # 1, ikke PKCS # 10. Kapitel 10 ville være tættere. Men det specificerer ikke ‘ RSA i etiketten, så det giver mening at bruge PKCS # 8 her. Da nøglealgoritmen ville blive specificeret overflødigt, kunne det være OK (og jeg så eksempler) at sætte PKCS # 1 i en ” RSA PRIVATE KEY ” fil.
- @ Som jeg allerede har sagt, leder jeg efter ” RSA PRIVATE KEY “, ikke til ” PRIVATE KEY “. Så selv kapitel 10 kan ikke anvendes, og RFC7468 er et forkert svar.
- @Gustave I ‘ Jeg er opmærksom på, at du skrev ” RSA PRIVATE KEY “, men at specificere formatet på den private nøgle i overskriften er unødvendig, og spec er relevant.
- ABNF læser < < textualmsg = preeb * WSP (…) > > og < < preeb = ” —- -BEGIN ” label ” —– ” (…) > >. Så hvorfor tror du, at overskriften er unødvendig?
- PKCS # 1 ( tools.ietf.org/html/rfc8017#appendix-A.1.2 ) angiver ikke ‘ t nogen ASCII base64-kodning, og det specificerer heller ikke ‘ t
-----BEGIN RSA PRIVATE KEY-----header. PKCS # 8 angiver ikke ‘ heller ikke nogen ASCII base64-kodning. Kapitel 10 angiver faktisk-----BEGIN PRIVATE KEY-----. Har du et link til en standard, der specificerer-----BEGIN RSA PRIVATE KEY-----header?