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.

  • $\begingroup$ The OpenPGP specification describes similar ASCII-Armor formats. $\endgroup$ – CodesInChaos Apr 25 '17 at 11:27
  • $\begingroup$ tls.mbed.org/kb/cryptography/asn1-key-structures-in-der-and-pem $\endgroup$ – CodesInChaos Apr 25 '17 at 11:45
  • $\begingroup$ These two comments let me suppose the answer is "no". $\endgroup$ – Gustave Apr 25 '17 at 12:06
  • 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 '17 at 13:09
  • $\begingroup$ It's basically PEM + the ASN.1 module, but I don't see it described anywhere. You could argue that specifying the key type in the text part is a bit spurious if it already has been defined within ASN.1. $\endgroup$ – Maarten Bodewes Apr 25 '17 at 13:54

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.

  • $\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 '17 at 19:03

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.

  • $\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 '17 at 19:10
  • $\begingroup$ @Gustave Excellent spot, I've updated the extract to be Chapter 10. And yes as you mentioned key format is redundant, non-RSA private keys are similarly formatted. $\endgroup$ – mikemaccana May 2 '17 at 13:53
  • $\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 '17 at 5:33
  • 1
    $\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$ – mikemaccana May 12 '17 at 12:42
  • $\begingroup$ The ABNF reads <<textualmsg = preeb *WSP (...)>> and <<preeb = "-----BEGIN " label "-----" (...)>>. So, why do you think the header is unnecessary? $\endgroup$ – Gustave May 16 '17 at 6:33

The format of the base64 contents inside:

...base64 encoded DER ASN.1 RSAPrivateKey...

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 - 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 (-----)
  • BEGINsomething
  • five hyphens (-----)

followed by

  • five hyphens (-----)
  • ENDsomething
  • five hyphens (-----)

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

...base64 encoded DER ASN.1 RSAPublicKey...


...base64 encoded DER ASN.1 RSAPrivateKey...


...base64 encoded DER ASN.1 SubjectPublicKeyInfo...
-----END PUBLIC KEY-----


...base64 encoded DER ASN.1 PrivateKeyInfo...
-----END PUBLIC KEY-----


...base64 encoded DER ASNl.1 Certificate...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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