Hello, I reviewed draft-ietf-acme-acme-06. As the co-author of RFC 7468, I have concerns.
First of all as an editorial matter there is no such thing as “PEM encoding”--that term is not defined in RFC 7468. The correct term is “textual encoding”. PEM is dead: just because some popular tools (i.e., OpenSSL) call it PEM doesn’t mean that it’s PEM, which is a mail format from RFC 1421. Therefore the text in Section 9.1.: “File should contain one or more certificates encoded as PEM according to RFC 7468.” is wrong because RFC 7468 doesn’t define “encoded as PEM”. 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. A bunch of textually encoded certificates are *text* data, and text is in a charset, so something like text/plain; charset=us-ascii is appropriate. Registering application/pem-certificate-chain is counterproductive because it omits the charset (and if you really want to omit the charset, then Section 9.1 is wrong because it needs to say “US-ASCII ONLY” or some such). A bunch of certificates as text data can include arbitrary text in between the encapsulation boundaries, such as printouts of the certificates (also OpenSSL options). This is superfluous and in my opinion dangerous. If you want such arbitrary text as a design matter, maybe for debugging purposes, that’s fine but that’s all the more reason why the contents should be text/* contents rather than application/* contents. It’s a lot cleaner to emit certificates in a blob as application/pkcs7-mime; smime-type=certs-only. This is also a trivial OpenSSL option. If you want to ASCII-armor it, you can put it in a -----BEGIN CMS-----, -----BEGIN PKCS7----- , or if you really want, -----BEGIN CERTIFICATE CHAIN----- (see Section 8 of RFC 7468). But you gain 37% size reduction by letting it be binary CMS/binary PKCS #7 over HTTP, and the certificate processing libraries can deal with the sorting issues. If it’s so important to put the subject certificate first, there are several other format choices to deal with that (including a multipart response). 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. Thank you, Sean _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
