Subject: [Acme] optional MIME parameter for application/pem-certificate-chain

From: Felix Fontein <[email-masked]>
Date: Fri, 10 Aug 2018 12:35:25 +0200

Hello,

this came up in the discussion of
https://github.com/ietf-wg-acme/acme/issues/435 ("An optional MIME
parameter for  application/pem-certificate-chain?"). I'm interested in
a reliable way to retrieve the root certificate, resp. the complete
certificate chain including a root certificate. This is sometimes
needed, for example for setting up an AWS ELB load balancer, or for
configuring OCSP verification in nginx, and also to simply verify the
validity of the returned chain down to the root.

During the discussion in the Github issue, Logan Widick suggested a
boolean MIME parameter (with suggested name "includeroot") for
application/pem-certificate-chain.

Since the issue (originally about another MIME parameter) is now
closed, I want to bring this suggestion up on the mailing list. My
suggestion would be that this parameter is optional (with no explicit
default value, i.e. the default is to do what the ACME server already
did before), and a formulation which suggests the server SHOULD respect
this parameter. I think the name "includeroot" is fine, but it could
also be "include-root" or something different.

Are there any opinions on this?

Thanks and best regards,
Felix Fontein

---

From: Richard Barnes <[email-masked]>
Date: Fri, 10 Aug 2018 09:16:13 -0400

Hi Felix,

Thanks for reflecting this back to the list.  The concrete implementation
concerns are helpful.

I'm concerned that the need here is more than just a simple MIME
parameter.  The MIME parameter is just an aspect of the media type; it just
tells you what's in the object you're looking at.  It sounds like for your
use cases, you would also need a way for the client to *request* that the
root be included.  In fact, it's not clear to me that you need the MIME
parameter if you have that.

In addition, I think these concerns can be handled cleanly in an extension,
e.g., by adding an optional field to the new-order object that requests the
root cert be included.

So while I'm not opposed to addressing this issue in general, I'll propose
that we not address this in the base spec.

--Richard

On Fri, Aug 10, 2018 at 6:38 AM Felix Fontein <felix=
[email-masked]> wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 10 Aug 2018 09:27:14 -0400

My feelings are similar to Richard's. There are probably some niche
usecases for this feature that merit thought but I think it would benefit
from larger design discussion. Given that we're very close to finishing the
base specification and there hasn't been significant demand for this to
date I think it makes the most sense to defer for a follow up.

On Fri, Aug 10, 2018 at 9:16 AM, Richard Barnes <[email-masked]> wrote:

> In addition, I think these concerns can be handled cleanly in an
> extension, e.g., by adding an optional field to the new-order object that
> requests the root cert be included.
>
> On Fri, Aug 10, 2018 at 6:38 AM Felix Fontein <felix=40fontein.de@dmarc.
> ietf.org> wrote:
>
>> Hello,
>>

---

From: Felix Fontein <[email-masked]>
Date: Fri, 10 Aug 2018 18:47:00 +0200

Hi Richard and Daniel,

I agree that this is a minor point which shouldn't delay the base
specification. Having it as an extension is totally fine for me. It's
just that I'm not happy with the situation that I as a client
developer have to ask the user for both the ACME endpoint *and* an URL
of the corresponding root certificate to be able to provide the whole
chain, so I wanted to raise awareness about this issue :)

@Richard: I'm not too familiar with MIME parameters, and I took my
inspiration mainly from the Github issue. I think I now see that this
doesn't work; my understanding was that the client sends something like

    Accept: application/pem-certificate-chain; include-root: yes

to indicate it wants a PEM certificate chain with the root included. I
missed that Accept: only accepts MIME types without parameters (if I
understand https://tools.ietf.org/html/rfc7231#section-5.3.2
correctly). Sorry for the confusion!

Best,
Felix

On Fri, 10 Aug 2018 09:27:14 -0400
Daniel McCarney <[email-masked]> wrote:

> usecases for this feature that merit thought but I think it would
> benefit from larger design discussion. Given that we're very close to
> finishing the base specification and there hasn't been significant
> demand for this to date I think it makes the most sense to defer for
> a follow up.
> 
> > Thanks for reflecting this back to the list.  The concrete
> > implementation concerns are helpful.
> >
> > parameter.  The MIME parameter is just an aspect of the media type;
> > it just tells you what's in the object you're looking at.  It
> > sounds like for your use cases, you would also need a way for the
> > client to *request* that the root be included.  In fact, it's not
> > clear to me that you need the MIME parameter if you have that.
> >
> > extension, e.g., by adding an optional field to the new-order
> > object that requests the root cert be included.
> >
> > So while I'm not opposed to addressing this issue in general, I'll
> > propose that we not address this in the base spec.
> >
> > --Richard
> >
> > On Fri, Aug 10, 2018 at 6:38 AM Felix Fontein
> > <felix=40fontein.de@dmarc. ietf.org> wrote:  
> >  
> >> Hello,
> >>
> >> parameter for  application/pem-certificate-chain?"). I'm
> >> interested in a reliable way to retrieve the root certificate,
> >> resp. the complete certificate chain including a root certificate.
> >> This is sometimes needed, for example for setting up an AWS ELB
> >> load balancer, or for configuring OCSP verification in nginx, and
> >> also to simply verify the validity of the returned chain down to
> >> the root.
> >>
> >> suggestion would be that this parameter is optional (with no
> >> explicit default value, i.e. the default is to do what the ACME
> >> server already did before), and a formulation which suggests the
> >> server SHOULD respect this parameter. I think the name
> >> "includeroot" is fine, but it could also be "include-root" or
> >> something different.
> >>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 10 Aug 2018 16:49:52 +0000

In general, the root of a chain is often "out of band" and you don't send it.  The receiving party gets a cert chain, and validates everything to make sure that it lists up to a root that is in their local trust store. They maintain and decide what's in that trust store, via out-of-band mechanisms. So while it could be an issue, in overall practice it usually isn't.

Hope this helps.

---

From: Clint Wilson <[email-masked]>
Date: Fri, 10 Aug 2018 12:45:20 -0600

I'm not sure how helpful this is, but we've typically found that allowing a
client to specify certificate delivery in one of 3 formats addresses >99%
of use-cases. I would shy away from connecting this to the MIME parameter
and would prefer something along the lines of what Richard offered as an
example. I also agree with this being WONTFIXed for the moment.

Since the spec already allows the client to specify additional MIME values
in the Accept header, such as application/x-pkcs7-certificates,
application/pkix-cert, or application/x-x509-ca-cert, this may not need to
be addressed by changes in the draft. If we wanted to be more prescriptive,
however, a field that allows specifying one of the following delivery
formats would provide some incremental value, imo:
1. A response as described in 7.4.2, but which only includes the
end-entity.
2. A response as described in 7.4.2.
3. A response as described in 7.4.2, but which additionally includes the
root.

On Fri, Aug 10, 2018 at 10:50 AM Salz, Rich <rsalz=
[email-masked]> wrote:

> In general, the root of a chain is often "out of band" and you don't send
> it.  The receiving party gets a cert chain, and validates everything to
> make sure that it lists up to a root that is in their local trust store.
> They maintain and decide what's in that trust store, via out-of-band
> mechanisms. So while it could be an issue, in overall practice it usually
> isn't.
>
> Hope this helps.
>
>