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

[Daniel McCarney <[e-mail]>]

Hi Ilari,

I guess if you find any use for the key at all depends on if authorizations
> are order-scoped or account-scoped.


See this follow-up thread[0] - it seems like "scope" on orders is
unnecessary & confusing. I vote it be removed and Richard Barnes seems to
be supportive of that.

There is at least one method in "10 methods" that absolutely requires the
> key to be known (number 9). Also, if the variant of the validation method
> uses the key, it does not seem safe to reuse it for different key.


Can you cite the specific challenge method you mean (or the section of the
baseline requirements) - I don't know which specific validation method
you're referring to.

More broadly: ACME defines a number of validation challenge methods. It
does not define a validation method based on using the public key from a
CSR. Using unspecified challenge types as an argument for why the CSR
should be submitted early doesn't seem very convincing to me.

What is the rationale for needing such a challenge type?
What problems does this challenge type resolve that are not resolved by the
current challenge types?
Do you or any other ACME servers have interest in specifying & implementing
such a challenge type?

I'm extremely hesitant to make design decisions based on allowing for very
open-ended features in the future when there isn't a strong case for the
feature or any established interest in implementing & shipping it.

If orders can live over 8 hours, then one MUST be prepared to take rejection
> at finalization anyway. Because even if CAA was checked at  authorization
> creation, it might have been changed and consequently fail the recheck.


Yes, this is something I mentioned in my reply[1] to one of your earlier
messages as well as in my reply to Brad Warren[2].

- Daniel / cpu


[0] - https://mailarchive.ietf.org/arch/msg/acme/wkQH2AqypoGnByiuCfYgq2UI3nI

[1] - https://mailarchive.ietf.org/arch/msg/acme/
KEB3sLRswTT3m_XIbZSW52r3lxM/?qid=abcabbc372443fbe31c952558aa3392f
[2] - https://mailarchive.ietf.org/arch/msg/acme/-uamQ4SPkxHR_eschpBSqkG1-yE

On Thu, Nov 2, 2017 at 12:18 PM, Ilari Liusvaara <[e-mail]>
wrote:

> On Thu, Nov 02, 2017 at 10:29:58AM -0400, Daniel McCarney wrote:
>
> >
> > I understand that these corner cases aren't a super convincing line of
> > argument, but I also don't think a slight preference for double CSR
> > strictly because it allows delivering a public key rejection error
> slightly
> > earlier in the order flow is a very convincing argument either. Does
> > someone have something stronger in mind?
>
> I guess if you find any use for the key at all depends on if
> authorizations are order-scoped or account-scoped.
>
> If authorizations are order-scoped, then the keys could be used for
> additional validation methods... There is at least one method in "10
> methods" that absolutely requires the key to be known (number 9).
> Also, if the variant of the validation method uses the key, it does
> not seem safe to reuse it for different key.
>
> If orders can live over 8 hours, then one MUST be prepared to take
> rejection at finalization anyway. Because even if CAA was checked at
> authorization creation, it might have been changed and consequently
> fail the recheck.
>
>
> -Ilari
>