I get that; what I’m looking to confirm--and I’m reasonably sure is the
case--is that, given a failed order, it’s up to server policy to spell out
whether a client may reasonably suppose that a 2nd order against a subset of
the identifiers from the 1st order would pass all of the 2nd set of authzs.
For LE, for example, a client can simply look at the ids of the failed authzs
and omit those ids from the 2nd order.
Going back to the hypothetical Fred/Jane/Pat CA, though, for a client to know
how to submit that 2nd order there would need to be some policy external to
ACME that would indicate the feasibility of such a thing.
Does that sound right?
-F
> On Jul 16, 2019, at 10:24 AM, Daniel McCarney <c...@letsencrypt.org> wrote:
>
> So if we tell the human operator, “Jane & Pat gave the OK, but Fred said
> not”, then it’s left to server policy to determine whether that means a
> hypothetical order with just one or the other domain would pass all authzs?
>
> No, if the server returned three authorizations all three must be
> status=valid for the order to be ready for issuance. Earlier drafts had a
> notion of challenge combinations that would allow something sort of similar
> but it was dropped.
>
> Per 7.1.6:
>
> Order objects are created in the "pending" state. Once all of the
> authorizations listed in the order object are in the "valid" state, the order
> transitions to the "ready" state.
>
> The server policy is exercised by the choice of authorizations/challenges in
> the pending order, not by the client deciding which authorizations in an
> order to satisfy.
>
> On Tue, Jul 16, 2019 at 10:11 AM Felipe Gasper <fel...@felipegasper.com>
> wrote:
>
> > On Jul 16, 2019, at 9:28 AM, Daniel McCarney <c...@letsencrypt.org> wrote:
> >
> > So it would be reasonable for this order to contain a single authz … and
> > would that authz’s identifier be just “example.com”, then? Thus that authz
> > object would not reference “www”, even though it is that domain’s
> > corresponding authz object? Or would a client be accountable for
> > implementing a “best-match authz” lookup to determine which authz
> > corresponds to a given domain?
> >
> > Yes, I would expect the order's one authorization to have the identifier
> > "example.com".
> >
> > I believe the confusion here is when you say "even though it is that
> > domain's corresponding authz object" and "Since the order requires
> > successful authz for both domains".
> >
> > For the first part, as I understand there is no guaranteed correspondence
> > between any of the identifiers in the order request and the identifiers in
> > the returned authorizations. That's what the sentence you quoted on p26 is
> > meant to convey. The client shouldn't attempt to match authz's to requested
> > identifiers at all, it should just look at the identifiers in the
> > authorizations returned by the server and prove control of those
> > identifiers with the challenges available.
>
> Thank your for your response. I think I see what’s going on.
>
> To flesh out a hypothetical a bit more:
>
> order identifiers: example.com, www.example.com
>
> authzs:
> 0)
> - identifier: { type: person, value: Fred }
> - challenge: ask if it’s ok
> 1)
> - identifier: { type: person, value: Jane }
> - challenge: ask if it’s ok
> 2)
> - identifier: { type: person, value: Pat }
> - challenge: ask if it’s ok
>
> So if we tell the human operator, “Jane & Pat gave the OK, but Fred said
> not”, then it’s left to server policy to determine whether that means a
> hypothetical order with just one or the other domain would pass all authzs?
>
> -F
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
