> > 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> 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> > 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_es >> chpBSqkG1-yE >> >> On Thu, Nov 2, 2017 at 12:18 PM, Ilari Liusvaara < >> 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
