Czy istnieje specyfikacja formatu “ BEGIN RSA PRIVATE KEY ”?

Jestem tutaj, ponieważ zadaję sobie to samo pytanie co OP.

PKCS # 1 (RFC 3447) definiuje strukturę ASN.1: RSAPrivateKey, pozwalając wyrażenie tylko klucza prywatnego RSA.

PKCS # 8 (RFC 5208) definiuje strukturę ASN.1: PrivateKeyInfo, zezwalając na wyrażenie dowolnego klucza prywatnego. (W przypadku klucza prywatnego RSA PrivateKeyInfo to niektóre informacje dotyczące pakowania i ponowne użycie RSAPrivateKey z PKCS # 1).

PEM (Privacy Enhanced Mail) to nieaktualna metoda bezpiecznej poczty e-mail. Ale jego format kontenera został zapożyczony do pakowania elementów kryptograficznych.

RFC 7468 (Wprowadzenie): „ Z powodów, które w zasadzie sprowadzają się do braku koordynacji lub nieuwagi, wiele bibliotek PKIX, PKCS i CMS zaimplementuj kodowanie tekstowe, które jest podobne – ale nie identyczne – do kodowania PEM . „

Który brzmi następująco: Hm, ludzie zdecydowali się użyć bitów PEM do pakowania swoich plików kryptograficznych . Tutaj mamy niezły wysiłek, aby spróbować sformalizować to …

Niestety, RFC 7468 wyjaśnia opakowanie PKCS # 8 / PrivateKeyInfo jako „BEGIN PRIVATE KEY”. Ale nie opakowanie PKCS # 1 / RSAPrivateKey jako „BEGIN RSA PRIVATE KEY”.

Opakowanie „BEGIN RSA PRIVATE KEY” jest czasami nazywane „formatem SSLeay” lub „formatem tradycyjnym” dla klucza prywatnego. Co przynajmniej daje nam nazwę dla tego formatu, ale, podobnie jak ty, nie mogę znaleźć i z zadowoleniem przyjąłbym coś, co zbliżałoby się do formalnego opisu tego formatu. Podejrzewam, że to nie istnieje.

Komentarze

• I'm here, because, I'm asking myself the same question as the OP. – – Aby wyjaśnić: czy to jest Twoja odpowiedź na pytanie zadane powyżej, czy w rzeczywistości zadajesz sobie to samo pytanie?

Format zawartości base64 wewnątrz:

-----BEGIN RSA PRIVATE KEY----- ...base64 encoded DER ASN.1 RSAPrivateKey... -----END RSA PRIVATE KEY----- 

jest udokumentowany w RFC3447 – Dodatek A.1.2 – Składnia klucza prywatnego 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 } 

Wiesz już, jak to zakodować za pomocą DER smak ASN.1; a pytanie dotyczy tego, jak zapisać dane binarne DER do pliku.

Następny krok jest udokumentowany w RFC 1421 – 4.3.2.4 Krok 4 : Kodowanie do druku

• dokumentują kodowanie danych binarnych w base64
• kodując dane wyjściowe jako wiersze tekstu
• z każdym wierszem ( z wyjątkiem ostatniego) zawierającego dokładnie 64 drukowalne znaki
• i ostatnią linię zawierającą 64 lub mniej drukowalnych znaków

Następnie używana jest „granica enkapsulacji” (EB) do oddzielania hermetyzowanych wiadomości PEM.

• ciąg znaków sprzed EB to: -----BEGIN PRIVACY-ENHANCED MESSAGE-----
• ciąg znaków po EB to: -----END PRIVACY-ENHANCED MESSAGE-----

To defuct Privacy Enhanced Mail zawiera:

• pięć myślników (-----)
• BEGIN something
• pięć łączników (-----)

, po których następuje

• pięć łączników (-----)
• END something
• pięć myślników (-----)

Te konwencje PEM zostały przeniesione dla klucza publicznego, klucza prywatnego i certyfikatów, ale z odpowiednimi zmienione sformułowanie:

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

Tak. RFC7468 – kodowanie tekstowe struktur PKIX, PKCS i CMS

Ten dokument wyjaśnia de facto zasady, według których działają istniejące implementacje i definiują je tak, aby przyszłe implementacje mogły współdziałać.

Oto odpowiedni fragment:

10. Jeden klucz asymetryczny i kodowanie tekstowe informacji o kluczu prywatnym PKCS # 8

-----BEGIN PRIVATE KEY----- MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ -----END PRIVATE KEY----- 

Komentarze

• Pytam o ” PRYWATNY KLUCZ RSA „, a nie ” PROŚBA O CERTYFIKAT „. Nawiasem mówiąc, spodziewałbym się PKCS # 8 lub PKCS # 1, a nie PKCS # 10. Rozdział 10 będzie bliżej. Ale nie ' nie określa RSA w etykiecie, więc sensowne jest użycie tutaj PKCS # 8. Ponieważ algorytm klucza zostałby określony nadmiarowo, można by było (i widziałem przykłady) umieścić PKCS # 1 w ” KLUCZ PRYWATNY RSA „.
• @ Jak już powiedziałem, szukam ” KLUCZU PRYWATNEGO RSA „, nie dla ” KLUCZA PRYWATNEGO „. Tak więc nawet rozdział 10 nie ma zastosowania, a RFC7468 jest błędną odpowiedzią.
• @Gustave I ' Mam świadomość, że napisałeś ” KLUCZ PRYWATNY RSA „, jednak określenie formatu klucza prywatnego w nagłówku jest niepotrzebne, a specyfikacja ma znaczenie.
• ABNF czyta < < textualmsg = preeb * WSP (…) > > i < < preeb = ” —- -BEGIN ” etykieta ” —– ” (…) > >. Więc dlaczego uważasz, że nagłówek jest niepotrzebny?
• PKCS # 1 ( tools.ietf.org/html/rfc8017#appendix-A.1.2 ) nie ' nie określa kodowania ASCII base64, a także nie ' nie określa -----BEGIN RSA PRIVATE KEY----- nagłówek. PKCS # 8 nie ' nie określa również żadnego kodowania ASCII base64. Rozdział 10 rzeczywiście określa -----BEGIN PRIVATE KEY-----. Czy masz łącze do standardu, który określa nagłówek -----BEGIN RSA PRIVATE KEY-----?