Subject: [Acme] "Slide 21" follow-up (textual encoding question) PART 2

From: Sean Leonard <[email-masked]>
Date: Fri, 31 Mar 2017 17:23:42 -0500

Hi ACME:

SECOND PART.

I think some of my comments may have been misconstrued about the “**Don't call it PEM certificate chain** (slide 21)” issue.

Textual encoding amounts to a way to ASCII-armor binary data in plain text. This is obvious because the human usability that it enables is: “copy-and-paste from your web browser or e-mail client into a text file”. And the problem with human usability is that when you tell people to copy and paste things, they don’t know or they ignore *what* they are copying and pasting, so they can facilitate transmitting malicious content across security boundaries.

Human interaction is not a design goal in ACME. You want humans to touch this stuff as little as possible. By letting software “copy and paste” the ACME server’s response to anything, *without validating it*, you facilitate attacks such as the private key substitution attack. (There are others, for example, OpenSSL behaves differently when you supply it with -----TRUSTED CERTIFICATE-----.)

If the WG’s consensus is that you really want a separate certificate URI (seriously: why? you want it retrievable over ldap:// or ni:// or something?), then the URI dereference should return *just* certificates in a well-defined way. Blobs of text (regardless of what MIME type you serve it as) are not well-defined compared to the gold standard of application/pkix-cert. If your goal really is so that a human being can take the certificate URI and put it in their web browser and copy and paste the certificate, then it should be served as text/plain; charset=us-ascii. Or if you want, text/html and include some dancing hamsters and last-minute unilateral changes to the CA contract (because hunting-and-picking for -----BEGIN CERTIFICATE----- in HTML source works exactly the same way, it’s called “page scraping”). But I thought that the point of ACME is to get away from page scraping techniques.

Anyway, if you want a format at a separate URI that includes the certificate and the ACME server’s proposed chain and is automatable, my first suggestion is multipart/mixed where each part is application/pkix-cert. Most web browsers don't handle multipart/mixed responses well, but the point is that you’re not supposed to use a web browser to get this URI.

My second suggestion is (what I wrote initially): a new binary type, application/pkix-certs (or cert-chain), with concatenated DER-encoded certificates: the first one is the subject certificate you’re interested in and the others “SHOULD” be in TLS order.

Thanks,

Sean

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 1 Apr 2017 00:26:50 +0000

Sean,

The working group felt pretty clearly that the BEGIN/END base64 encoding was the format used by "all" web servers and that anything else would require the client to translate into that format.

Hope this helps.