Existuje specifikace pro “ ZAČÍNAT SOUKROMÝ KLÍČ RSA ”?

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-----?

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *