On Fri, Mar 31, 2017 at 5:23 PM, Sean Leonard <[email protected]> wrote:
> 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-----.)
>
You're confusing parsing with validation. Yes, if we provide things in
some non-de-facto-standard format, then clients will have to reformat
things. That introduces some likelihood that the reformatting will break
on invalid inputs, but it's far from guaranteed.
That said, the idea of "inlining" the certificate / chain doesn't seem
completely awful. On the one hand, it would save an HTTP round-trip in the
common case, and we don't have anything else in the protocol that relies on
a certificate being referenced indepenedently from the order that created
it. On the other hand, it seems like there could be some utility in the
future to being able to refer to the certificate per se, vs. the order that
created it. I could go either way.
If we do inline the certificate into the order, ISTM the natural thing to
do would be to just present it in base64url-encoded form:
{
// existing order fields
"certificate": "[[ base64url data ]]",
"chain": ["[[ base64url data ]]", ...]
}
Then it would just be a syntactic transformation to whatever an HTTP server
accepts.
--Richard
>
> 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
>
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
