Re: [Acme] Revisiting Proactive Issuance & new-order CSR

[Andrew Ayer]

FWIW, I previously expressed support for proactive issuance because 
I thought it would lay the groundwork for a better renewal process,
especially for short-lived certificates.  However, this idea never
gained traction and the other necessary bits weren't added.  Instead,
STAR seems to be handling this use case.

Therefore, I no longer see a compelling reason for proactive issuance.
If it's causing problems it should be removed.  I also agree with Roland
that issuing upon an unauthenticated GET request is a bad idea.

Regards,
Andrew

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

[Daniel McCarney]

I've proposed a first cut at implementing the changes I described in my
original post as an ACME PR https://github.com/ietf-wg-acme/acme/pull/342



On Fri, Sep 22, 2017 at 7:19 PM, Roland Bracewell Shoemaker <
rol...@letsencrypt.org> wrote:

> Broad points:
>
> I understand that this group has been moving towards standardization for
> a while but I really think that attempting to fix these issues with
> creative readings of the existing language and minimal editorial changes
> is asking for trouble and return trips to the WG in the future when
> these band-aids turn out to not be fully thought out or themselves
> introduce new problems.
>
> These issues have come up during, as far as I'm aware, the only full-fat
> implementation of the current version of this specification and that
> implementation itself is maybe only 40-50% done. Assuming that these
> will be the only issues that are discovered seems to be, again, asking
> for trouble.
>
> Comments on the proposed fixes:
>
> 1. Causing issuance really seems like it should be required to be an
> authorized action, allowing this to happen by a GET allows anyone who is
> able to determine the order URL to cause issuance to happen.
> Implementing this behavior, even if not explicitly defined in the
> specification, will almost definitely lead to users relying on it
> (Hyrum's Law) which again will be a problem if another user is able to
> simply send of a handful of GETs and cause another users certificate to
> be issued.
>
> 2. Unless another implementer comes along this would mean that the only
> existing implementation of the current specification before
> standardization would not be implementing a major section of this
> document. At this point why not just go back to the -03/-04 draft
> new-authz flow. As Daniel has already pointed out this also completely
> breaks one of the major reasons to use the new-order flow: policy based
> authorization creation. How would a CA indicate that a user _may not_
> need an authorization for www.example.com when issuing for example.com
> or that they require a specific set of authorizations when issuing for
> *.example.com?
>
> Like I said at the start these band-aid editorial fixes seem to just
> create another set of problems that cannot themselves be solved with
> further minor editorial  changes.
>
> On 09/21/2017 11:40 AM, Richard Barnes wrote:
> > I talked a bit with Daniel about this off-list. Here's a summary of
> > where we got to:
> >
> > 1. In the current "new-order" flow, the server doesn't *really* have to
> > be proactive -- instead of updating an order object when an authz
> > changes state, it can wait to update/issue until the client polls for
> > the order object, indicating that it's actually interested in having a
> > certificate.  That doesn't alleviate the pain of storing the CSR, but it
> > at least avoids the expense of finding affected orders and issuing in
> > cases where the client abandons the order.  If we think this approach is
> > OK, I would propose that we revise the document to make clear that it is
> > OK.  What do folks think?  Daniel noted that there might be some issues
> > with GET idempotency here, but I don't think this actually makes GET
> > non-idempotent.
> >
> > 2. Some CAs might want to support only the "new-authz" flow, i.e., never
> > allow a "new-order" request if the relevant authorizations haven't
> > already been done.  It seems like this could be addressed in a pretty
> > straightforward manner just by defining a new error code (say
> > "preauthRequired") that the server can return in this case.
> >
> > Personally, it seems to me that if we make the clarification (1) and add
> > the error code (2) described here, that would address the pain points
> > Daniel raises, without a whole lot of new mechanism.  I'm not really
> > seeing much additional value to be had from an explicit "ok issue now"
> > request (vs. the GET poll).
> >
> > --Richard
> >
> >
> >
> > On Wed, Sep 20, 2017 at 1:22 PM, Richard Barnes  > > wrote:
> >
> > Hey Daniel,
> >
> > Thanks for the input.  I can see why you might be feeling some pain
> > here, but I'm not sure the proposed solution is quite right.
> >
> > Note that ACME already has the "new-authorization" flow, which does
> > pretty much exactly what you're proposing.  The only difference is
> > that instead of authorizations being created all at once in response
> > to a "new-cert" request, they're created individually by the
> > client.  But it's ultimately the same number of RTTs (authz fetch ~
> > new-authz) -- or rather, one fewer in the new-authz case because
> > there's no new-cert request.  To what degree would your problem be
> > solved simply by having the affected integrators move over to that
> flow?
> >
> > I can sympathize that the new-order flow might not be suitable for
> > all use cases.  Maybe it would be useful to write down some