I'm not sure how helpful this is, but we've typically found that allowing a client to specify certificate delivery in one of 3 formats addresses >99% of use-cases. I would shy away from connecting this to the MIME parameter and would prefer something along the lines of what Richard offered as an example. I also agree with this being WONTFIXed for the moment.
Since the spec already allows the client to specify additional MIME values in the Accept header, such as application/x-pkcs7-certificates, application/pkix-cert, or application/x-x509-ca-cert, this may not need to be addressed by changes in the draft. If we wanted to be more prescriptive, however, a field that allows specifying one of the following delivery formats would provide some incremental value, imo: 1. A response as described in 7.4.2, but which only includes the end-entity. 2. A response as described in 7.4.2. 3. A response as described in 7.4.2, but which additionally includes the root. On Fri, Aug 10, 2018 at 10:50 AM Salz, Rich <rsalz= [email protected]> wrote: > In general, the root of a chain is often "out of band" and you don't send > it. The receiving party gets a cert chain, and validates everything to > make sure that it lists up to a root that is in their local trust store. > They maintain and decide what's in that trust store, via out-of-band > mechanisms. So while it could be an issue, in overall practice it usually > isn't. > > Hope this helps. > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
