Subject: Re: [Acme] "Slide 21" follow-up (textual encoding question) PART 2

From: Sean Leonard <[email-masked]>
Date: Thu, 4 May 2017 00:04:45 -0700

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-masked]> wrote:
> 
> 
> 
> On Apr 3, 2017 16:07, "Sean Leonard" <[email-masked] <mailto:[email-masked]>> 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-masked] <mailto:[email-masked]>> 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