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

[Sean Leonard <[e-mail]>]

On 4/2/2017 1:06 PM, Richard Barnes wrote:
>
>
> On Fri, Mar 31, 2017 at 5:23 PM, Sean Leonard <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi ACME:
>
>     SECOND PART.
>     [...]
>
> That said, the idea of "inlining" the certificate / chain doesn't seem 
> completely awful.  On the one hand, it would save an HTTP round-trip 
> in the common case, and we don't have anything else in the protocol 
> that relies on a certificate being referenced indepenedently from the 
> order that created it.  On the other hand, it seems like there could 
> be some utility in the future to being able to refer to the 
> certificate per se, vs. the order that created it. I could go either way.

That's the idea (in PART 1, anyway).

The issue of whether a certificate should be referred to by reference 
(URI) or by value (supplied as the certificate itself) is discussed in 
draft-seantek-certspec-11. In this case, I do not see any additional 
value in /requiring/ a separate URI to access the certificate octets. 
Put another way: if you want a separate URI instead of the certificate, 
because you don't want to store the certificate, then you will have to 
store the separate URI somewhere. And, if you are storing the separate 
URI, you have a place to store the certificate in the first place.

Perhaps there is business value in a CA standing up a sensible 
(well-known) URI scheme, such as:

https://www.cawebsite.com/.well-known/getcert?host=FOO.BAR.COM&{other 
parameters}

...but that is outside of the scope of the (current) protocol for this 
working group. Compare with draft-bhjl-x509-srv-03. I could see it being 
added to the ACME server as a "feature", but that is up to you all.

>
> If we do inline the certificate into the order, ISTM the natural thing 
> to do would be to just present it in base64url-encoded form:
>
> {
>   // existing order fields
>   "certificate": "[[ base64url data ]]",
>   "chain": ["[[ base64url data ]]", ...]
> }
>
> Then it would just be a syntactic transformation to whatever an HTTP 
> server accepts.

Something like that could be okay. Although I suppose some "aesthetics" 
are involved, the choice for JSON format is not exactly bikeshedding. If 
it's in JSON then some part of it ought to be an array. The main point 
(raised in PART 1) is that inlining makes things faster and sidesteps 
all of the problems raised by MIME types and text blobs in PART 2.

I note that a base64url-encoded version of the DER octets of a 
certificate are already included in this protocol, in Certificate 
Revocation Section 7.6.

Sean