I think that having separate URIs to reduce bloat is a good idea. I
understand that the client needs to send the CSR as a field in the
new-order request payload for security. However, in the server response,
could the CSR be a URI that would allow the client to retrieve the CSR that
the client submitted in DER format? So, could new-order requests look like:
{
csr: "base64url(derEncodedCSR)"
//rest of fields in new-order here
}
And the server's order response look like:
{
csrLink: "[link to DER encoded CSR]"
certificate: "[link to DER encoded certificate]"
chains: [array of links to chains as suggested by Niklas]
//rest of fields in order response here (except for "csr")
}
For consistency, I think the chain links (when retrieved) should be
concatenated DER.
Sincerely,
Logan Widick
On Apr 3, 2017 06:29, "Niklas Keller" <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
