On Wed, Mar 29, 2017 at 02:32:17PM -0500, Sean Leonard wrote: > Hello, > > Second of all, I see negative value in transmitting certificates in > the proposed “PEM Certificate Chain” format (Section 7.4.2., Section > 9.1). Again, I understand that some popular tools (i.e., OpenSSL) > dump out this format by default, but one command-line switch or > pipe can change it to a much better format. Don’t be lazy.
AFAIK, the PEM format is intended for transporting the End-Entity and intermediate certificates at once, as incomplete chains are extremely common. > I don’t see value in specifying an order to the certificates > in the text: “Each following certificate SHOULD directly certify > one preceding it.” Again I know what the tools out there do, > but a robust receiver still needs to handle out-of-order > certificates, as well as certificates that end up not being > part of the chain. CMS/PKCS #7 deals with this by just supplying > an arbitrary set of certificates. TLS 1.2 has a MUST for ordering certificates. And nothing that doesn't build paths itself (and thus can fetch certiifcates itself) handles CMS/PKCS#7. This is way too much logic to expect from ACME client. And handling unordered certificates is quite a bit of extra attack surface. I took not just one but two vulns on that (one being auth bypass, which barring type safety bugs are just about the worst that can happen). -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
