> On Mar 30, 2017, at 1:07 AM, Jacob Hoffman-Andrews <[email protected]> wrote: > > On 03/29/2017 01:48 PM, Sean Leonard wrote: >> If you are saying that the receiver is only expected to handle TLS >> 1.2-ordered certificates: “Each following certificate MUST directly >> certify the one preceding it” (MUST, not SHOULD) then we have a >> different situation and PKCS #7/CMS certs-only may not be appropriate. >> But the text does not currently say that, so I need clarification >> before suggesting a better data format for the certificate chain. > In general, the expectation is that the ACME client passes the > certificate chain straight to a web server or other TLS server. > Generally speaking, the TLS server will then pass along the chain in the > same order to the TLS client during the handshake. So I assume by > "receiver" you mean TLS client, right? > > My understanding of TLS deployment is that, even though TLS 1.2, 1.1, > and 1.0 required strict ordering of certificates in the chain, deployed > clients were actually tolerant of out-of-order certificates. I haven't > followed TLS 1.3 standardization closely, but my guess is that that's > the reason the ordering requirement was relaxed. > > So I think the answer to your question is: The receiver (TLS client) is > expected to handle TLS 1.3-ordered certificates, and our belief is that > that's reasonable given today's deployments.
Thank you. In the message above, the first sentence’s “receiver” was meant to be the receiver that is the HTTP client in the ACME protocol that issues the GET /acme/cert request, and receives back the certificate chain. Therefore the “receiver” is the ACME client, which also is the web/TLS server that incorporates the chain into its operations. I spoke with Rich Salz in person about this yesterday, sorry that I probably won’t be at the ACME meeting today due to a scheduling conflict. But if your purpose is to communicate an ordered list of certificates in TLS 1.2 order (according to Section 7.4.2 of RFC 5246), I have a simple solution for you: application/tls-certificate-list [or tls-cert-list] Contents: DER-encoded certificates, concatenated in RFC 5246 Section 7.4.2 order The end. This is very simple and makes it easy for both sides to deal with the certificates. The first certificate is the end-entity/TLS subject certificate. The remaining certificates are supposed to chain to some root (use the appropriate RFC 5246 language). It is safe to concatenate binary (X.690/BER/DER) certificates because the first TLV indicates the full length of the certificate; therefore they are self-delimiting. This is easier and better than stringing the textual encoded versions because you don’t have to deal with text metadata issues, charsets, line endings, and extra processing. Specifically, an ACME server is going to have to take the certificate bytes and base64-encode each one, followed by ASCII armoring. Then the ACME client is going to have to reverse this. No point and confusing. For those who don’t like binary, ACME is JSON-based, so you can just have an application/json response that is just an array: [“MIICAS...base64 of end-entity cert”,“MIICAS…base64 of second cert…”…to root] This way you don’t have to register a media type and you can ingest the response using the same JSON stack. Also, you can encapsulate this very simple JSON structure in more articulated JSON entities if you want to include other metadata or whatever down the line. Regards, Sean _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
