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

Reply via email to