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 _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
