Doposud jsem nenašel specifikaci (RFC nebo podobnou) pro formát souboru, který používá předponu BEGIN RSA PRIVATE KEY a END RSA PRIVATE KEY. . Kde je definována? Existuje pro ni oficiální název? Zdá se, že to alespoň souvisí s řadou PEM RFC.
Hledám referenční informace o podrobnostech manipulace s mezerami, podrobnosti base64 , spojování různých klíčů v jednom souboru atd.
Tato otázka NENÍ o kódování ASN užitečného zatížení.
Komentáře
- Specifikace OpenPGP popisuje podobné formáty ASCII-Armor.
- tls.mbed.org/kb/cryptography/asn1-key-structure-in- der-and-pem
- Většina formátů PEM (také jiných než soukromý klíč RSA) je dokumentována v RFC 7468: Textual Encodings of Struktury PKIX, PKCS a CMS . Existují např. Určité pokyny k manipulaci s mezerami. Že RFC v podstatě bere na vědomí tyto podrobnosti se liší podle analyzátoru.
- Díky user4982: Toto je druh zdroje, který hledám. RFC 7468 však obsahuje informace týkající se štítku “ ENCRYPTED PRIVATE KEY „, ale ‚ t pro “ SOUKROMÝ KLÍČ RSA „.
- PEM je definován v RFC 1421 , který popisuje celkový formát záhlaví atd. Ale o „
SOUKROMÝ KLÍČ RSA „. Tento článek z roku 1997 již zmiňuje použití OpenSSL.
Odpověď
Jsem tady, protože si kladu stejnou otázku jako OP.
PKCS # 1 (RFC 3447) definuje strukturu ASN.1: RSAPrivateKey, povolující výraz pouze soukromého klíče RSA.
PKCS # 8 (RFC 5208) definuje strukturu ASN.1: PrivateKeyInfo, což umožňuje vyjádření jakéhokoli soukromého klíče. (Pro soukromý klíč RSA je PrivateKeyInfo několik informací o balení a opětovné použití RSAPrivateKey z PKCS # 1).
PEM (Privacy Enhanced Mail), je zaniklá metoda zabezpečeného e-mailu. Ale jeho kontejnerový formát byl vypůjčen pro balení kryptografických položek.
RFC 7468 (Úvod): „ Z důvodů, které v zásadě spadají do nekoordinace nebo nepozornosti, mnoho knihoven PKIX, PKCS a CMS implementujte textové kódování, které je podobné – ale ne totožné – s kódováním PEM . „
Který zní jako: Hm, lidé se rozhodli použít kousky PEM k zabalení svých krypto souborů . Tady máme obrovskou snahu zkusit to formalizovat …
Bohužel, RFC 7468 objasňuje balení PKCS # 8 / PrivateKeyInfo jako „ZAČÍNAT SOUKROMÝ KLÍČ“. Ale ne obal PKCS # 1 / RSAPrivateKey jako „BEGIN RSA PRIVATE KEY“.
Balení „BEGIN RSA PRIVATE KEY“ se někdy nazývá: „SSLeay format“ nebo „tradiční formát“ pro soukromý klíč. Což nám přinejmenším dává název tohoto formátu, ale stejně jako vy nemohu najít a uvítal bych něco, co by se blížilo k formálnímu popisu tohoto formátu. Mám podezření, že to neexistuje.
Komentáře
-
I'm here, because, I'm asking myself the same question as the OP.
– – K objasnění: je to vaše odpověď na otázku položenou výše, nebo si vlastně kladete stejnou otázku?
Odpověď
Formát obsahu base64 uvnitř:
-----BEGIN RSA PRIVATE KEY----- ...base64 encoded DER ASN.1 RSAPrivateKey... -----END RSA PRIVATE KEY-----
je zdokumentován v RFC3447 – dodatek A.1.2 – syntaxe soukromého klíče 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 }
Již víte, jak to zakódovat pomocí DER příchuť ASN.1; a otázkou je, jak ve skutečnosti zapsat tato binární data DER do souboru.
Tento další krok je dokumentován v RFC 1421 – 4.3.2.4 Krok 4 : Tisknutelné kódování
- dokumentují kódování binárních dat v base64
- kódující výstup jako řádky textu
- s každým řádkem ( kromě posledního) obsahujícího přesně 64 tisknutelných znaků
- a poslední řádek obsahující 64 nebo méně tisknutelných znaků
Pak se používá hranice „zapouzdření“ (EB) k vymezení zapouzdřených zpráv PEM.
- řetězec před EB je:
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
- řetězec po EB je:
-----END PRIVACY-ENHANCED MESSAGE-----
Byl to defekt Ochrana osobních údajů rozšířená , který používal:
- pět pomlček (
-----
) -
BEGIN
something
- pět pomlček (
-----
)
následovaných
- pěti pomlčkami (
-----
) -
END
something
- pět pomlček (
-----
)
Tyto konvence PEM byly přeneseny pro veřejný klíč, soukromý klíč a certifikáty, ale s vhodnými změněno znění:
-----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-----
Odpověď
Ano. RFC7468 – textové kódování struktur PKIX, PKCS a CMS
Tento dokument formuluje de facto pravidla, podle kterých fungují stávající implementace, a definuje je tak, aby budoucí implementace mohly spolupracovat.
Zde je relevantní výňatek:
10. Jeden asymetrický klíč a textové kódování informací soukromého klíče PKCS # 8
Nešifrované struktury syntaxe informací o soukromém klíči PKCS č. 8 (PrivateKeyInfo), přejmenované na balíčky asymetrických klíčů (OneAsymmetricKey), jsou kódovány pomocí štítku „SOUKROMÝ KLÍČ“. DER preferováno; viz dodatek B) kódovaná struktura ASN.1 PrivateKeyInfo, jak je popsáno v PKCS # 8 [RFC5208], nebo struktura OneAsymmetricKey, jak je popsána v [RFC5958]. Oba jsou sémanticky identické a lze je odlišit číslem verze.
-----BEGIN PRIVATE KEY----- MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ -----END PRIVATE KEY-----
Komentáře
- Žádám o “ SOUKROMÝ KLÍČ RSA „, ne o “ ŽÁDOST O CERTIFIKÁT „. Mimochodem, očekával bych PKCS # 8 nebo PKCS # 1, ne PKCS # 10. Kapitola 10 by byla blíže. Ale ‚ t neurčuje RSA na štítku, takže má smysl použít PKCS # 8. Protože klíčový algoritmus by byl zadán redundantně, mohlo by být v pořádku (a viděl jsem příklady) dát PKCS # 1 do “ RSA PRIVATE KEY “ soubor.
- @ Jak jsem již řekl, hledám “ RSA SOUKROMÝ KLÍČ „, ne pro “ SOUKROMÝ KLÍČ „. Ani kapitola 10 tedy není použitelná a RFC7468 je špatná odpověď.
- @Gustave I ‚ jsem si vědom toho, že jste napsali “ RSA PRIVATE KEY „, je však zbytečné určovat formát soukromého klíče v záhlaví a specifikace je relevantní.
- ABNF čte < < textualmsg = preeb * WSP (…) > > a < < preeb = “ —- -BEGIN “ label “ —– “ (…) > >. Proč si tedy myslíte, že je záhlaví zbytečné?
- PKCS # 1 ( tools.ietf.org/html/rfc8017#appendix-A.1.2 ) neurčuje ‚ t žádné kódování ASCII base64 a také ‚ neuvádí
-----BEGIN RSA PRIVATE KEY-----
záhlaví. PKCS # 8 neurčuje ‚ žádné kódování ASCII base64. Kapitola 10 skutečně specifikuje-----BEGIN PRIVATE KEY-----
. Máte odkaz na normu, která určuje záhlaví-----BEGIN RSA PRIVATE KEY-----
?