>
> 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
