Hi all I am not responsing to latest message in thread currently (Daniels reply to Ilari) because it lost the content to which I would like to refer.
I would prefer the third approach suggested by Richard - authorizationFirst. In that approach in case the authorizationFirst happened, the server can provide authorizations to be fulfilled without binding them to some order – so no order is allocated at this step (just as it is in new-authz of v1). Next, after client fulfilled the authorizations and places new-order then it can be issued (just like new-cert of v1) In identifiers+CSR: the new-order would create an orderId and after that provide the client with links to authorizations to be fulfilled. Personally I prefer the authorizationFirst. It is from one side simpler, more similar to v1 way and also seems to be less resource demanding on server. Since identifiers+CSR approach would need to create/go through all authorizations on new-order step and later on finalization at once. Also in cases when clients are unable to fulfill the order it will still stay in the db Regards, Andriy From: Daniel McCarney [mailto:c...@letsencrypt.org] Sent: fredag 10. november 2017 15:03 To: Richard Barnes <r...@ipv.sx> Cc: Ilari Liusvaara <ilariliusva...@welho.com>; Brad Warren <b...@eff.org>; Hugo Landau <hlan...@devever.net>; IETF ACME <acme@ietf.org> Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR 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: I think this is a mis-characterization. What are the legacy issues that can't be handled with identifiers+CSR? The opposition to this approach on-list has focused on challenge types that could exist that would require the CSR public key & the benefits of delivering errors to clients regarding the CSR earlier. Neither of which seem to be a question of legacy issues. 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. This returns to issuing a certificate on a GET request - I think there was some opposition to this approach. From a client perspective, it admits a pretty simple flow: This flow seems more complicated than my original proposal. How is it simpler than: a. submit new-order with identifiers b. fulfill the authorizations c. finalize the order with CSR This is also *much* closer to the current "V1" issuance process where clients request authzs, fulfill them, and then submit to new-cert with a CSR. Given that 100% of existing ACME clients implement a finalization based approach (using new-cert), would it not be easier for them to adapt current code if we matched this behaviour for the new-order flow? - Daniel / cpu On Thu, Nov 9, 2017 at 5:18 PM, Richard Barnes <r...@ipv.sx<mailto:r...@ipv.sx>> wrote: 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 <c...@letsencrypt.org<mailto:c...@letsencrypt.org>> 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/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 <ilariliusva...@welho.com<mailto:ilariliusva...@welho.com>> 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 Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
