15
$\begingroup$

Until now I didn't find a specification (RFC or similar) for the file format that uses the BEGIN RSA PRIVATE KEY prefix and END RSA PRIVATE KEY suffix. Where is it defined? Is there an official name for it? It seems to be at least related to the series of PEM RFCs.

I am looking for reference information about the details of whitespace handling, base64 details, joining of different keys in one file etc..

This question is NOT about the ASN encoding of the payload.

$\endgroup$
9
  • $\begingroup$ The OpenPGP specification describes similar ASCII-Armor formats. $\endgroup$ Apr 25, 2017 at 11:27
  • $\begingroup$ tls.mbed.org/kb/cryptography/asn1-key-structures-in-der-and-pem $\endgroup$ Apr 25, 2017 at 11:45
  • 1
    $\begingroup$ The most of PEM formats (also other than RSA Private Key) are documented in RFC 7468: Textual Encodings of PKIX, PKCS, and CMS Structures. There are e.g. some guidance on topic of whitespace handling. That RFC basically notes that details vary according to parser. $\endgroup$
    – user4982
    Apr 25, 2017 at 13:09
  • 1
    $\begingroup$ Thanks to user4982: This is the kind of source I am looking for. However, RFC 7468 contains information regarding the label "ENCRYPTED PRIVATE KEY", but it doesn't for "RSA PRIVATE KEY". $\endgroup$
    – Gustave
    Apr 25, 2017 at 15:06
  • 1
    $\begingroup$ PEM is defined in RFC 1421 which describes the overall format of the header, etc. But I couldn't find about the "RSA PRIVATE KEY". This article from 1997 already mentions OpenSSL using it. $\endgroup$
    – Conrado
    Apr 25, 2017 at 16:46

3 Answers 3

13
$\begingroup$

I'm here, because, I'm asking myself the same question as the OP.

PKCS#1 (RFC 3447) defines the ASN.1 structure: RSAPrivateKey, permitting the expression of an RSA private key only.

PKCS#8 (RFC 5208) defines the ASN.1 structure: PrivateKeyInfo, permitting the expression of any private key. (For an RSA private key, PrivateKeyInfo is some packaging information, and a reuse of RSAPrivateKey from PKCS#1).

PEM (Privacy Enhanced Mail), is a defunct method for secure email. But, its container format was borrowed for packaging cryptographic items.

RFC 7468 (Introduction): "For reasons that basically boil down to non-coordination or inattention, many PKIX, PKCS, and CMS libraries implement a textbased encoding that is similar to -- but not identical with -- PEM encoding."

Which reads as: Um, folk have decided to use bits of PEM to package thier crypto files. Here we have a jolly good effort to try and formalise that...

Alas, RFC 7468 clarifies the PKCS#8/PrivateKeyInfo packaging as "BEGIN PRIVATE KEY". But not the packaging of PKCS#1/RSAPrivateKey as "BEGIN RSA PRIVATE KEY".

The "BEGIN RSA PRIVATE KEY" packaging is sometimes called: "SSLeay format" or "traditional format" for private key. Which, as least, gives us a name for this format, but, like yourself, I cannot find, and would welcome, something that approaches a formal description of this format. I suspect this does not exist.

$\endgroup$
1
  • 1
    $\begingroup$ I'm here, because, I'm asking myself the same question as the OP. --- To clarify: is this your answer to the question asked above, or are you actually asking yourself the same question? $\endgroup$
    – e-sushi
    May 15, 2017 at 19:03
6
$\begingroup$

The format of the base64 contents inside:

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

is documented in RFC3447 - Appendix A.1.2 - RSA private key syntax:

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
}

You already know how to encode that using the DER flavor of ASN.1; and the question is about how to actually write that DER binary data to a file.

That next step is documented in RFC 1421 - 4.3.2.4 Step 4: Printable Encoding

  • they document encoding the binary data in base64
  • encoding the output as lines of text
  • with each line (except the last) containing exactly 64 printable characters
  • and the final line containing 64 or fewer printable characters

There is then the "Encapsulation Boundary" (EB), used to delimit encapsulated PEM messages.

  • the pre-EB string is: -----BEGIN PRIVACY-ENHANCED MESSAGE-----
  • the post-EB string is: -----END PRIVACY-ENHANCED MESSAGE-----

It was the defuct Privacy Enhanced Mail that used:

  • five hyphens (-----)
  • BEGIN something
  • five hyphens (-----)

followed by

  • five hyphens (-----)
  • END something
  • five hyphens (-----)

Those PEM conventions were carried over for public key, private key, and certificates, but with suitable changed wording:

-----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-----
$\endgroup$
2
$\begingroup$

Yes. RFC7468 - Textual Encodings of PKIX, PKCS, and CMS Structures

This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate.

Here's a relevant extract:

10. One Asymmetric Key and the Textual Encoding of PKCS #8 Private Key Info

Unencrypted PKCS #8 Private Key Information Syntax structures (PrivateKeyInfo), renamed to Asymmetric Key Packages (OneAsymmetricKey), are encoded using the "PRIVATE KEY" label. The encoded data MUST be a BER (DER preferred; see Appendix B) encoded ASN.1 PrivateKeyInfo structure as described in PKCS #8 [RFC5208], or a OneAsymmetricKey structure as described in [RFC5958]. The two are semantically identical and can be distinguished by version number.

-----BEGIN PRIVATE KEY-----
MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf
jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK
H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ
-----END PRIVATE KEY-----
$\endgroup$
7
  • 2
    $\begingroup$ I am asking about "RSA PRIVATE KEY", not about "CERTIFICATE REQUEST". By the way, I would expect PKCS #8 or PKCS #1, not PKCS #10. Chapter 10 would be closer. But it doesn't specify RSA in the label, so it makes sense to use PKCS #8 here. As the key algorithm would be specified redundantly, it could be OK (and I saw examples) to put PKCS #1 in a "RSA PRIVATE KEY" file. $\endgroup$
    – Gustave
    Apr 28, 2017 at 19:10
  • 1
    $\begingroup$ @As I already said, I am looking for "RSA PRIVATE KEY", not for "PRIVATE KEY". So, even chapter 10 is not applicable, and RFC7468 is a wrong answer. $\endgroup$
    – Gustave
    May 11, 2017 at 5:33
  • 2
    $\begingroup$ @Gustave I'm aware you wrote "RSA PRIVATE KEY", however specifying the format of the private key in the header is unnecessary and the spec is relevant. $\endgroup$ May 12, 2017 at 12:42
  • 1
    $\begingroup$ The ABNF reads <<textualmsg = preeb *WSP (...)>> and <<preeb = "-----BEGIN " label "-----" (...)>>. So, why do you think the header is unnecessary? $\endgroup$
    – Gustave
    May 16, 2017 at 6:33
  • 1
    $\begingroup$ PKCS #1 (tools.ietf.org/html/rfc8017#appendix-A.1.2) doesn't specify any ASCII base64 encoding, and it also doesn't specify the -----BEGIN RSA PRIVATE KEY----- header. PKCS #8 doesn't specify any ASCII base64 encoding either. Chapter 10 indeed specifies -----BEGIN PRIVATE KEY-----. Do you have a link to a standard which specifies the the -----BEGIN RSA PRIVATE KEY----- header? $\endgroup$
    – pts
    May 1, 2020 at 21:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.