Tot nu toe heb ik “geen specificatie (RFC of vergelijkbaar) gevonden voor het bestandsformaat dat het BEGIN RSA PRIVATE KEY-voorvoegsel en het END RSA PRIVATE KEY-achtervoegsel gebruikt . Waar wordt het gedefinieerd? Is er een officiële naam voor? Het lijkt op zijn minst gerelateerd te zijn aan de reeks PEM RFCs.
Ik ben op zoek naar referentie-informatie over de details van de verwerking van witruimten, base64-details , het samenvoegen van verschillende sleutels in één bestand enz ..
Deze vraag gaat NIET over de ASN-codering van de payload.
Opmerkingen
- De OpenPGP-specificatie beschrijft vergelijkbare ASCII-Armor-formaten.
- tls.mbed.org/kb/cryptography/asn1-key-structures-in- der-and-pem
- De meeste PEM-indelingen (ook anders dan RSA-privésleutel) worden gedocumenteerd in RFC 7468: tekstuele coderingen van PKIX-, PKCS- en CMS-structuren . Er zijn bijvoorbeeld enkele richtlijnen over het afhandelen van witruimten. Dat RFC in feite opmerkt die details verschillen per parser.
- Dankzij user4982: dit is het soort bron dat ik zoek. RFC 7468 bevat echter informatie over het label ” VERSLEUTELDE PRIVATE KEY “, maar ‘ t voor ” RSA PRIVATE KEY “.
- PEM is gedefinieerd in RFC 1421 die de algemene indeling van de koptekst beschrijft, enz. Maar ik kon ‘ niet vinden over de ” RSA PRIVÉSLEUTEL “. Dit artikel uit 1997 vermeldt al dat OpenSSL het gebruikt.
Antwoord
Ik “ben hier, omdat ik mezelf dezelfde vraag stel als het OP.
PKCS # 1 (RFC 3447) definieert de ASN.1-structuur: RSAPrivateKey, waardoor de uitdrukking van alleen een RSA-privésleutel.
PKCS # 8 (RFC 5208) definieert de ASN.1-structuur: PrivateKeyInfo, waardoor de expressie van elke privésleutel mogelijk is. (Voor een RSA-privésleutel is PrivateKeyInfo wat verpakkingsinformatie en een hergebruik van RSAPrivateKey van PKCS # 1).
PEM (Privacy Enhanced Mail) is een ter ziele gegane methode voor veilige e-mail. Maar het containerformaat werd geleend voor het verpakken van cryptografische items.
RFC 7468 (inleiding): “ Om redenen die in feite neerkomen op niet-coördinatie of onoplettendheid, zijn veel PKIX-, PKCS- en CMS-bibliotheken een op tekst gebaseerde codering implementeren die vergelijkbaar is met – maar niet identiek is aan – PEM-codering . “
Wat luidt als: Eh, mensen hebben besloten stukjes PEM te gebruiken om hun cryptobestanden te verpakken . Hier hebben we een heel goede poging om te proberen dat te formaliseren …
Helaas, RFC 7468 verduidelijkt de PKCS # 8 / PrivateKeyInfo-verpakking als “BEGIN PRIVATE KEY”. Maar niet de verpakking van PKCS # 1 / RSAPrivateKey als “BEGIN RSA PRIVATE KEY”.
De “BEGIN RSA PRIVATE KEY” -verpakking wordt ook wel: “SSLeay-formaat” of “traditioneel formaat” voor privésleutel genoemd. Wat ons op zijn minst een naam geeft voor dit formaat, maar, net als jij, kan ik iets vinden dat een formele beschrijving van dit formaat benadert, en dat zou ik graag zien. Ik vermoed dat dit niet bestaat.
Reacties
-
I'm here, because, I'm asking myself the same question as the OP.– – Ter verduidelijking: is dit uw antwoord op de bovenstaande vraag, of stelt u zichzelf eigenlijk dezelfde vraag?
Antwoord
Het formaat van de base64-inhoud binnen:
-----BEGIN RSA PRIVATE KEY----- ...base64 encoded DER ASN.1 RSAPrivateKey... -----END RSA PRIVATE KEY----- is gedocumenteerd in RFC3447 – Bijlage A.1.2 – Syntaxis van RSA-privésleutel :
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 } Je weet al hoe je dat moet coderen met de DER smaak van ASN.1; en de vraag is hoe je die binaire DER-gegevens daadwerkelijk naar een bestand schrijft.
Die volgende stap wordt gedocumenteerd in RFC 1421 – 4.3.2.4 Stap 4 : Afdrukbare codering
- ze documenteren de codering van de binaire gegevens in base64
- codering van de uitvoer als tekstregels
- met elke regel ( behalve de laatste) met precies 64 afdrukbare tekens
- en de laatste regel met 64 of minder afdrukbare tekens
Er is dan de “Encapsulation Boundary” (EB), gebruikt om ingekapselde PEM-berichten af te bakenen.
- de pre-EB-string is:
-----BEGIN PRIVACY-ENHANCED MESSAGE----- - de post-EB-string is:
-----END PRIVACY-ENHANCED MESSAGE-----
Het was de defuct Privacy Enhanced Mail die gebruikte:
- vijf streepjes (
-----) -
BEGINsomething - vijf koppeltekens (
-----)
gevolgd door
- vijf koppeltekens (
-----) -
ENDsomething - vijf koppeltekens (
-----)
Die PEM-conventies zijn overgenomen voor openbare sleutel, privésleutel en certificaten, maar met geschikte gewijzigde bewoording:
-----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----- Antwoord
Ja. RFC7468 – Tekstuele coderingen van PKIX-, PKCS- en CMS-structuren
Dit document articuleert de feitelijke regels waarmee bestaande implementaties werken en definieert ze zodat toekomstige implementaties kunnen samenwerken.
Hier is een relevant fragment:
10. Een asymmetrische sleutel en de tekstuele codering van PKCS # 8 privésleutelinformatie
Onversleutelde PKCS # 8 Private Key Information Syntax-structuren (PrivateKeyInfo), hernoemd naar Asymmetric Key Packages (OneAsymmetricKey), worden gecodeerd met het label PRIVATE KEY. De gecodeerde gegevens MOETEN een BER ( DER heeft de voorkeur; zie bijlage B) gecodeerde ASN.1 PrivateKeyInfo-structuur zoals beschreven in PKCS # 8 [RFC5208], of een OneAsymmetricKey-structuur zoals beschreven in [RFC5958]. De twee zijn semantisch identiek en kunnen worden onderscheiden door versienummer.
-----BEGIN PRIVATE KEY----- MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ -----END PRIVATE KEY----- Reacties
- Ik vraag naar ” RSA PRIVATE KEY “, niet over ” CERTIFICAATVERZOEK “. Ik zou trouwens PKCS # 8 of PKCS # 1 verwachten, niet PKCS # 10. Hoofdstuk 10 zou dichterbij zijn. Maar het specificeert niet ‘ RSA in het label, dus het is logisch om PKCS # 8 hier te gebruiken. Omdat het sleutelalgoritme redundant zou worden gespecificeerd, zou het goed kunnen zijn (en ik heb voorbeelden gezien) om PKCS # 1 in een ” RSA PRIVATE KEY “.
- @ Zoals ik al zei, ben ik op zoek naar ” RSA PRIVATE KEY “, niet voor ” PRIVATE KEY “. Dus zelfs hoofdstuk 10 is niet van toepassing, en RFC7468 is een verkeerd antwoord.
- @Gustave Ik ‘ weet dat je ” RSA PRIVATE KEY “, maar het specificeren van het formaat van de private key in de header is niet nodig en de specificatie is relevant.
- De ABNF leest < < textualmsg = preeb * WSP (…) > > en < < preeb = ” —- -BEGIN ” label ” —– ” (…) > >. Dus waarom denk je dat de koptekst niet nodig is?
- PKCS # 1 ( tools.ietf.org/html/rfc8017#appendix-A.1.2 ) specificeert niet ‘ t geen ASCII base64-codering, en het specificeert ook niet ‘ t de
-----BEGIN RSA PRIVATE KEY-----koptekst. PKCS # 8 specificeert ook geen ASCII base64-codering ‘. Hoofdstuk 10 specificeert inderdaad-----BEGIN PRIVATE KEY-----. Heeft u een link naar een standaard die de-----BEGIN RSA PRIVATE KEY-----header specificeert?