Since people don't seem happy about either of these alternatives (identifiers+CSR because of legacy issues; CSR+CSR because of fragility), here's one last attempt at a different approach:
1. Add an error code for new-order, say "authorizationFirst", which means "I only accept orders with all authz fulfilled; go and do these authz and then submit new-order" 2. When you send an "authorizationFirst" error, you MUST send authorizations for the client to complete 3. Add a note that the server MAY delay issuance until it receives the first GET request to the certificate URL This is basically equivalent to the CSR+CSR proposal from the server POV, but now there's no formal relationship between the two CSRs (they're independent orders), so you don't have to worry about what happens if they're different. It also removes the authentication on the "finalize" step (replacing it with a GET), but I don't think we had heard a reason for the authentication anyway. From a client perspective, it admits a pretty simple flow: a. Submit new-order b. If response is 2XX or authzNeeded, go do the authz c. If you got authzNeeded, re-submit new-order; else poll order until cert URL shows up d. Poll cert URL Draft PR: https://github.com/ietf-wg-acme/acme/pull/350 In any case, it would be helpful if people could provide thoughts on which of the three options they prefer here: 1. Identifiers + CSR (https://github.com/ietf-wg-acme/acme/pull/342) 2. CSR + CSR (same, but with a CSR instead of identifiers) 3. authorizationFirst (https://github.com/ietf-wg-acme/acme/pull/350) Personally, my current preference is for (3), because it seems like the least complex / error prone way to support both back-end cases (CSR first / CSR last). Thanks, --Richard On Wed, Nov 8, 2017 at 9:05 AM, Daniel McCarney <[email protected]> wrote: > 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/wkQH2AqypoGnByi > uCfYgq2UI3nI > [1] - https://mailarchive.ietf.org/arch/msg/acme/KEB3sLRswTT3m_X > IbZSW52r3lxM/?qid=abcabbc372443fbe31c952558aa3392f > [2] - https://mailarchive.ietf.org/arch/msg/acme/-uamQ4SPkxHR_ > eschpBSqkG1-yE > > On Thu, Nov 2, 2017 at 12:18 PM, Ilari Liusvaara <[email protected] > > 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 >> > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
