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 Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
