Hi Ilari, Also, do not confuse challege types and validation methods. Neither contains > the other.
Thanks for clarifying. So there does not seem much reason to provode keys up front in order to support > different validation methods. Great! I agree with your reasoning here. So to update my earlier statement it seems that the only argument in favour of presenting the CSR in the new-order request that has appeared on-list is that it helps provide some potential errors to clients earlier. We both agree that clients will still have to handle errors at finalization time so it seems like a weak argument. - Daniel / cpu On Fri, Nov 10, 2017 at 10:13 AM, Ilari Liusvaara <[email protected]> wrote: > On Fri, Nov 10, 2017 at 09:03:03AM -0500, Daniel McCarney 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: > > > > > > 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. > > Also, do not confuse challege types and validation methods. Neither > contains the other. > > > Actually looking at the "10 methods" and seeing if they are key- > dependent or key-independent (only key-independent works if just domain > list is given up front): > > Key-Independent: > > - Method 1 (Authenticate DC via registry) > - Method 2 (Message DC) > - Method 3 (Call DC) > - Method 4 (E-Mail domain) > - Method 5 (Domain Authorization Document) > - Method 10 (Certificate Random Value) > > Key-Dependent: > > - Method 9 (Test certificate) > > Can be either: > > - Method 6 (HTTP) > - Method 7 (DNS) > - Method 8 (IP address) > > So every one of the present methods can be key-independent (situation > is similar with proposed IP address validation methods), except 9. > > Method 9 can be replaced with method 10, and since the client (or TLS > server) constructs the certificate, it can understand the scope of the > authorization if the validation method is so designed (I have a feeling > this is supposed to be required, but apparently not, given that TLS-SNI > fails this... But then, method 10 allows blatantly insecure stuff). > > I have seen some proposed methods (I think four), and those are pretty > much all key-independent or can be either. > > So there does not seem much reason to provode keys up front in order to > support different validation methods. > > > On checking earlier, the client needs to be prepared to get a fault on > order finalization anyway. Especially if order can take over 8 hours to > fill (Due to CAA recheck), which it can easily do if one hits pending > OOB challenges. > > > > -Ilari >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
