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 <[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
