On 4/2/2017 1:06 PM, Richard Barnes wrote:
On Fri, Mar 31, 2017 at 5:23 PM, Sean Leonard <[email protected]
<mailto:[email protected]>> 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
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
