Since the best thing to get adoption probably involves “Send Text”, I will try to send a proposed textual change to draft-ietf-acme-acme-06 over the next few days (most likely by Monday May 8). Therefore I would ask that we get a bit of a time extension for folks to think about it (and also for me, to write the text).
Kind regards, Sean > On Apr 19, 2017, at 9:44 PM, Logan Widick <[email protected]> wrote: > > > > On Apr 3, 2017 16:07, "Sean Leonard" <[email protected] > <mailto:dev%[email protected]>> wrote: > On 4/3/2017 5:54 AM, Logan Widick wrote: >> 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: >> […] > > > Finally, here is how you convert from p7s to textual certificates: > openssl pkcs7 -inform DER -in yourfile.p7s -print_certs > > The advantage of the command-line/OpenSSL recipe above, is that you are > guaranteed that the output will only be -----BEGIN CERTIFICATE----- things. > Non-certificates shall not pass. > > That already standardized type would be better. > >> >> On Apr 3, 2017 06:29, "Niklas Keller" <[email protected] >> <mailto:[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://.../chain>, >> "https://.../alternate-chain" <https://.../alternate-chain> >> ] >> >> Regards, Niklas
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
