Eddig nem találtam specifikációt (RFC vagy hasonló) a fájlformátumhoz, amely a BEGIN RSA PRIVATE KEY előtagot és az END RSA PRIVATE KEY utótagot használja . Hol van meghatározva? Van-e hivatalos neve? Úgy tűnik, hogy legalább a PEM RFC-k sorozatához kapcsolódik.
Hivatkozási információkat keresek a szóközök kezelésének részleteiről, base64 részletek , különböző kulcsok összekapcsolása egy fájlban stb.
Ez a kérdés NEM a hasznos teher ASN-kódolásáról szól.
Megjegyzések
- Az OpenPGP specifikáció hasonló ASCII-Armor formátumokat ír le.
- tls.mbed.org/kb/cryptography/asn1-key-structures-in- der-and-pem
- A legtöbb PEM formátum (az RSA magánkulcson kívül) az RFC 7468 dokumentumban van dokumentálva: PKIX, PKCS és CMS struktúrák . Vannak például útmutatások a szóközök kezelésével kapcsolatban. Az RFC alapvetően megjegyzi hogy a részletek elemzőnként változnak.
- Köszönet a user4982-nek: Ezt a fajta forrást keresem. Az RFC 7468 azonban információkat tartalmaz a ” TITKOSÍTOTT PRIVÁT KULCS ” címkével kapcsolatban, de nem tartalmaz ‘ t a ” RSA PRIVÁT KULCS “.
- A PEM a RFC 1421 , amely leírja a fejléc általános formátumát, stb. De nem tudtam ‘ megtalálni a ” RSA PRIVÁT KULCS “. Ez az 1997-es cikk már említi az OpenSSL használatát.
Válasz
Itt vagyok, mert ugyanazt a kérdést teszem fel magamnak, mint az OP.
A PKCS # 1 (RFC 3447) meghatározza az ASN.1 struktúrát: RSAPrivateKey, engedélyezve csak egy RSA magánkulcs kifejezése.
A PKCS # 8 (RFC 5208) meghatározza az ASN.1 struktúrát: PrivateKeyInfo, amely lehetővé teszi bármely privát kulcs kifejezését. (Az RSA magánkulcs esetében a PrivateKeyInfo néhány csomagolási információ, és az RSAPrivateKey újrafelhasználása a PKCS # 1-ből).
A PEM (Privacy Enhanced Mail) a biztonságos e-mail megszüntetett módszere. De a konténer formátumát kriptográfiai elemek csomagolására kölcsönözték.
RFC 7468 (Bevezetés): “ Olyan okokból, amelyek alapvetően nem koordináció vagy figyelmetlenség miatt merülnek fel, sok PKIX, PKCS és CMS könyvtár implementáljon egy szöveges kódolást, amely hasonló – de nem azonos a PEM kódolás hoz. “
Ami így hangzik: Hm, a folk úgy döntött, hogy PEM biteket használ a kriptofájljaik csomagolásához . Itt nagyon jó erőfeszítéseket teszünk annak kipróbálására és formalizálására …
Sajnos az RFC 7468 egyértelművé teszi a PKCS # 8 / PrivateKeyInfo csomagolását “BEGIN PRIVATE KEY” néven. De nem a PKCS # 1 / RSAPrivateKey csomagolása, mint “BEGIN RSA PRIVATE KEY”.
A “BEGIN RSA PRIVATE KEY” csomagolást néha “SSLeay formátumnak” vagy “hagyományos formátumnak” nevezik a magánkulcs számára. Ami legalább nevet ad nekünk ennek a formátumnak, de Önhöz hasonlóan én sem találok, és örömmel fogadnék valamit, amely megközelítené a formátum hivatalos leírását. Gyanítom, hogy ez nem létezik.
Megjegyzések
-
I'm here, because, I'm asking myself the same question as the OP.– – Tisztázandó: ez a válasz a fenti kérdésre, vagy valóban ugyanazt a kérdést teszi fel magának?
Válasz
A benne található base64 tartalom formátuma:
-----BEGIN RSA PRIVATE KEY----- ...base64 encoded DER ASN.1 RSAPrivateKey... -----END RSA PRIVATE KEY----- a RFC3447 – A.1.2. függelék – RSA magánkulcs szintaxisa :
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 } Már tudja, hogyan kell ezt kódolni a DER használatával ASN.1 íze; és a kérdés arról szól, hogy hogyan lehet valóban beírni a DER bináris adatokat egy fájlba.
Ezt a következő lépést az RFC 1421 – 4.3.2.4 4. lépés tartalmazza. : Nyomtatható kódolás
- dokumentálják a bináris adatok kódolását az base64-ben
- a kimenetet szövegsorokként kódolják
- minden egyes sorral ( az utolsó kivételével pontosan 64 nyomtatható karaktert tartalmaz
- és az utolsó sort, amely 64 vagy kevesebb nyomtatható karaktert tartalmaz
Ezután a “Tömítés határ” (EB) van használva tokozott PEM üzenetek elhatárolására.
- az EB előtti karakterlánc:
-----BEGIN PRIVACY-ENHANCED MESSAGE----- - az EB utáni karakterlánc:
-----END PRIVACY-ENHANCED MESSAGE-----
A defekt Privacy Enhanced Mail használta:
- öt kötőjelet (
-----) -
BEGINsomething - öt kötőjel (
-----)
, amelyet követ
- öt kötőjel (
-----) -
ENDsomething - öt kötőjel (
-----)
Ezeket a PEM-konvenciókat átvitték a nyilvános kulcsra, a magánkulcsra és a tanúsítványokra, de megfelelő megváltozott a megfogalmazás:
-----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----- Válasz
Igen. RFC7468 – PKIX, PKCS és CMS struktúrák szöveges kódolása
Ez a dokumentum megfogalmazza a tényleges szabályok, amelyek alapján a meglévő megvalósítások működnek, és definiálja azokat, hogy a jövőbeni megvalósítások működjenek együtt.
Itt “releváns kivonat:
10. Egy aszimmetrikus kulcs és a PKCS # 8 magánkulcs információjának szöveges kódolása
Titkosítatlan PKCS # 8 titkos kulcs információs szintaxis struktúrák (PrivateKeyInfo), átnevezve aszimmetrikus kulcscsomagokra (OneAsymmetricKey), a “PRIVATE KEY” címkével vannak kódolva. A kódolt adatoknak BER-nek KELL lenniük ( A DER előnyben részesített; lásd a B függeléket) kódolt ASN.1 PrivateKeyInfo struktúrát a PKCS # 8 [RFC5208] leírása szerint, vagy egy OneAsymmetricKey struktúrát, ahogyan azt az [RFC5958] leírja. A kettő szemantikailag azonos és verziószámmal megkülönböztethető. >
-----BEGIN PRIVATE KEY----- MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ -----END PRIVATE KEY----- Megjegyzések
- Kérem az ” RSA PRIVÁT KULCSOT “, nem a ” HITELESÍTÉSI KÉRELEM “. Egyébként a PKCS # 8-ra vagy a PKCS # 1-re számítanék, nem a PKCS # 10-re. A 10. fejezet közelebb lenne. De nem ‘ nem adja meg az RSA-t a címkében, ezért van értelme itt használni a 8. PKCS-t. Mivel a kulcsalgoritmust redundánsan adnák meg, rendben lehet (és láttam példákat), ha az 1. PKCS-t egy ” RSA PRIVÁT KULCS ” fájl.
- @Mint már mondtam, az ” RSA PRIVÁTKULCS ” -t keresem, nem a ” MAGÁNKULCS ” esetén. Tehát még a 10. fejezet sem alkalmazható, az RFC7468 pedig helytelen válasz.
- @Gustave I ‘ tudatában vagyok annak, hogy ” RSA PRIVÁT KULCS “, azonban a fejlécben a magánkulcs formátumának megadása felesleges, és a specifikáció releváns.
- Az ABNF < < textualmsg = preeb * WSP (…) > > és < < preeb = ” —- -BEGIN ” label ” —– ” (…) > >. Tehát miért gondolja, hogy nincs szükség a fejlécre?
- PKCS # 1 ( tools.ietf.org/html/rfc8017#app függelék-A.1.2 ) nem ad meg ‘ t semmilyen ASCII base64 kódolást, és nem adja meg ‘ t sem a
-----BEGIN RSA PRIVATE KEY-----fejléc. A PKCS # 8 nem ad meg ‘ semmilyen ASCII base64 kódolást sem. A 10. fejezet valóban meghatározza a következőt:-----BEGIN PRIVATE KEY-----. Van linkje egy szabványra, amely meghatározza a-----BEGIN RSA PRIVATE KEY-----fejlécet?