10

This is a question that's not really about security proper. It's about security/crypto nomenclature. It's been bugging me a bit, so here goes:

I know two approaches for bundling related certificates/keys together:

  • Heavy weight approach: PFX. There is the PKCS #12 file format. Windows saves these as .PFX or .P12 files.
  • Light weight approach: Just-cat-everything (aka "PEM bundle"). Just running cat on all the certificates/keys (in your desired order) and redirecting this into a new text file.

Question

  • Is there an actual standard for the "PEM bundle" approach? Is it even called that or is there a more official name? (Citation please!)

It was my impression that this is just the ad hoc way that OpenSSL used to handle bundle of certs/keys and it's been adopted as a de facto standard. Is this true? Or is the "just-cat-everything"-approach part of the PEM standards?

Nomenclature survey

What do people call these PEM bundle files?

Anders
  • 64,406
  • 24
  • 178
  • 215
StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86

1 Answers1

10

There is no real standard for things in "PEM" format. There was a proposed standard called Privacy-enhanced Electronic Mail, from which the "PEM" acronym was derived; however, that standard never gained traction against its competition (PGP and S/MIME) and nobody implements it.

OpenSSL picked up PEM and "enhanced" the PEM format with extra functionalities and headers, without any actual specification or documentation worth that name, so that nowadays, "PEM" really means "whatever OpenSSL produces and can parse". Other vendors followed, e.g. Microsoft, whose software can decode PEM-encoded certificates.

The principle of PEM (Base64-encoded data, with a '-----BEGIN XXX-----' header and corresponding '-----END XXX-----' trailer) has been used for other things; PGP calls it "ASCII armor". The point of that way of doing things is to be able to locate the interesting data within a sequence of text data, regardless of the various tortures inflicted to that text as it is transferred (e.g. sent as e-mail, copy&pasted, included in a Word document, printed and scanned...). This is an important point: it means that the whole point of PEM is to be able to store the certificates together and haphazardly without having to follow a specific, precise standard. In that sense, a standard for a "PEM bundle" would be a self-contradiction: a "PEM bundle" is what you do when there is no standard.

It is not incorrect to call it a "de facto standard".

When you want to encode and send certificates, there are in fact more than two methods; possibilities include:

  • Encode each certificate separately, using ASN.1 DER encoding (which is standard).
  • Use PEM to further make these certificates more resilient to ASCII-based transfer; this also allows storing several of them in a single file (that which you call a "PEM bundle");
  • Store the certificates in a PKCS#7 (aka CMS) SignedData object. A SignedData is nominally a format for embedding data which is signed; but you can omit the data and include exactly zero signature, in which case you have some sort of shell that includes a field for embedding "extra certificates" (nominally, these certificates are there to help in validating the signatures). This is the reuse of an existing standard for something that the standard was not meant to do, but existing software does that. Microsoft calls that a "PKCS#7 certificate" or a "P7B file".
  • Use a PKCS#7 SignedData but also PEM-encode it (so you could conceptually store several of them in a single file).
  • PKCS#12 (also known as "PFX"). This format also allows storing other kind of objects, and includes provisions for password-based encryption, so it is commonly used to store a certificate and its private key. (Apparently, nobody ever thought of PEM-encoding a PKCS#12 archive.)

Private keys also have their own formats. For instance, PKCS#1 defines an ASN.1-based encoding for RSA private keys, that OpenSSL will gleefully use and then PEM-encode with a "BEGIN RSA PRIVATE KEY" header. That format may be further wrapped into a PKCS#8 object, which includes an ASN.1-based identifier for the algorithm, and also optional support of password-based encryption; and then, OpenSSL will also encode a PKCS#8 file, this time with "BEGIN PRIVATE KEY" or "BEGIN ENCRYPTED PRIVATE KEY" (no indication of the algorithm in the PEM header), depending on whether password-based encryption was used or not. Alternatively, the raw PKCS#1 format may also be password-encrypted, using the extensions to PEM that OpenSSL implements but does not document (OpenSSL's source code being supposed to be the specification).

To sum up: it is a mess.

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • I feared that much. But for practical purposes: what term you use if you need such a "cat-every-pen" file? Do you say "PEM bundle"? – StackzOfZtuff Jul 24 '15 at 15:18
  • I would probably use a term relative to the meaning of the certificates, e.g. I would talk of "the server certificate chain", rather than using a term that describes how that chain is to be encoded. – Thomas Pornin Jul 24 '15 at 15:22
  • But what if you need exactly that encoding? – StackzOfZtuff Jul 24 '15 at 15:39
  • https://tools.ietf.org/html/rfc7468 formalizes some of OpenSSL's PEM-style formats but not all; the second paragraph of the Introduction gives "concatenat[ing] several certificates to form a certificate chain" as an advantage of this format, but does not actually standardize (or name) that. In addition to PGP, 7468 also references the 'portable' SSH pubkey format in 4716 (but wrongly calls it OpenSSH, when actual OpenSSH does NOT use this format). – dave_thompson_085 Oct 18 '17 at 04:26