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 protected]> wrote:
> 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 protected]> wrote:
>
> > 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=40fontein.de@dmarc. ietf.org> wrote:
> >
> >> 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
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
