Hello: I noticed that issue #194 defaults to PEM with chain for certificates.
However, the text in Section 6.4.2 is not correct. [RFC7468] is the correct reference but it should be called “PKIX textual encoding” or simply “textual encoding”, not “PEM”. Furthermore, application/x-pem-file is not a registered media type. It should be served as text/plain, or can be served as anything “reasonable” but not application/pkix-cert. The text should say something like: The default format of the certificate is textual as specified by [RFC7468]. with no discussion of media type(s) in that sentence. If you want to serve multiple certificates in a single response, it could be served as: * textual encoding [RFC7468] as described in Section 6.4.2 (which, I suppose, most people will do...) * a multipart where each part is application/pkix-cert * application/pkcs7-mime; smime-type=certs-only (AKA CMS or PKCS #7 “degenerate” case) * application/cms; encapsulatingContent=signedData RECIPE FOR THE LAZY: openssl crl2pkcs7 -nocrl -certfile cert1.cer -certfile cert2.cer -out outfile.p7c Not hard, and don’t need to base64-encode and boundary-encapsulate each one on the wire. Section 6.4.2 also says: This format should contain the end-entity certificate first, followed by any intermediate certificates that are needed to build a path to a trusted root. Since it says “should” I suppose this is normative language. However, although it might be nice to put the certificates in order for stylistic reasons, it should be a normative requirement. Is your client really going to fail if the certificates are in a different order? Some implementations emit certificates in “anchor-to-end-entity order”: the utility is just the same. The client needs to inspect the certificates anyway. When using PKCS #7 / CMS SignedData, the certificates are stored as a SET OF and therefore order is not material. Regards, Sean _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
