I agree that end certificate data should be inlined in the certificate object, rather than being hosted at a separate certificate URI, so long as GET requests for order resources do not require authentication and can thus be easily polled (which is currently the case).
I'm indifferent as to whether certificate data in the certificate object is a PEM formatted JSON string or base64url-encoded DER formatted JSON string. I think it's essential to support multiple certificate chains and referencing these by an array of URIs makes sense to me. I think it should be a requirement that the server always list its "recommended" chain first in that array, so that clueless clients can always have a sensible default to go with. (i.e., Let's Encrypt would list its current IdenTrust-based chain first, and its ISRG-based ahin second). I think having the certificate chains encoded in a format other than concatenated PEM is likely to be more trouble than it's worth. I think it's important that those certificate chains should include the root certificate, because it's required for some applications (DANE). Clients which do not require the root certificate can simply be mandated to strip off the last certificate returned in the chain. This is my preference. Alternatively, if that's viewed as too error-prone, a link rel=up link from the chain URL to the root URL could be used. I don't agree that including the certificate in the certificate object will cause badly implemented clients to assume synchronous issuance; one simply polls the order resource until the certificate appears. This is no different than waiting for a certificate URI to appear. (The current specification doesn't provide for requests to the certificate URI to defer a response; that was in a previous version.) On Mon, Apr 03, 2017 at 01:28:58PM +0200, Niklas Keller wrote: > One potential issue I can see with embedding certificates with the > currently proposed format directly into orders are alternative chains. > Chains usually do not change between orders, so they could be kept with > separate URIs for cachability and less bloat in the order response. > e.g. > "certificate": base64url(derEncodedCertificate), > "chains": [ > "https://.../chain";, > "https://.../alternate-chain"; > ] > Regards, Niklas _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
