Re: [Acme] orders, authorizations, and identifiers (oh my)
>
> 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.
Ahhh, gotcha! Apologies for misunderstanding that was the crux of the
follow-up q.
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?
Yes, I think it does. Maybe there's something clever you could do with the
problems returned during the initial order flow that would help hint to
this but I'm uncertain.
On Tue, Jul 16, 2019 at 10:35 AM Felipe Gasper
wrote:
> 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
> 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
> wrote:
> >
> > > On Jul 16, 2019, at 9:28 AM, Daniel McCarney
> 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
Re: [Acme] orders, authorizations, and identifiers (oh my)
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 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
> wrote:
>
> > On Jul 16, 2019, at 9:28 AM, Daniel McCarney 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
Re: [Acme] orders, authorizations, and identifiers (oh my)
> > 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. For the second part, the server decides what identifiers the client needs to prove control of in order to authorize the overall order. It may not be both identifiers in the requested order. It happens that Let's Encrypt return orders with an authorization matching each requested identifier and requires all to be validated but the returned authorizations and associated challenges are entirely up to server policy. Hope that helps, On Mon, Jul 15, 2019 at 5:56 PM Felipe Gasper wrote: > Hi all, > > The new RFC (8555) states (on p26), for order objects, that a 1:1 > relationship may not exist between an order’s identifiers and its authzs. > > Given that each authz object contains exactly 1 identifier, how > would this play out for CAs that accept authz against a base domain as > substitutive for authz on a subdomain? > > Consider an order to the hypothetical “AwesomeSSL” CA for > example.com and www.example.com. AwesomeSSL considers authz against “ > example.com” to implicitly demonstrate control over “www.example.com”. > Since the order requires successful authz for both domains, and (for > AwesomeSSL) authz for “example.com” suffices for both domains, having a > separate authz against “www” is superfluous. 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? > > Thank you! > > -Felipe Gasper > Mississauga, Ontario > ___ > 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
[Acme] orders, authorizations, and identifiers (oh my)
Hi all, The new RFC (8555) states (on p26), for order objects, that a 1:1 relationship may not exist between an order’s identifiers and its authzs. Given that each authz object contains exactly 1 identifier, how would this play out for CAs that accept authz against a base domain as substitutive for authz on a subdomain? Consider an order to the hypothetical “AwesomeSSL” CA for example.com and www.example.com. AwesomeSSL considers authz against “example.com” to implicitly demonstrate control over “www.example.com”. Since the order requires successful authz for both domains, and (for AwesomeSSL) authz for “example.com” suffices for both domains, having a separate authz against “www” is superfluous. 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? Thank you! -Felipe Gasper Mississauga, Ontario ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
