> To be clear, in the current spec, the new-app flow is not optional. > The new-cert endpoint has been eliminated, so clients have to be able > to at least use new-app to request a certificate. Right. To rephrase: If part of the rationale for new-application is that some CAs want all validation to be connected to a CSR, then those CAs won't be able to implement an independent new-authz flow. So the new-authz flow is incompatible with one of the main reasons you proposed a new-application flow. > > The other motivation for the new-application flow was to provide a > framework that could support validation and issuance of wildcard > names. > However, the current spec doesn't actually go into detail about a > validation method for wildcard names. > > > What else do you think is required for interoperability? ISTM that > the current spec captures most current and suggested practices, > including everything from "validate the base name" to "validate some > random subdomains" to "validate some WHOIS information" (via OOB). > I'm skeptical that we can define much more without ruling out some > CAs' practices. I think providing one "ACME-approved" process for wildcards doesn't rule out existing CA practices, any more than the ACME HTTP-01, TLS-SNI-02, and DNS-01 challenges rule out existing DV methods.
The CA/Browser Forum's recent Ballot 169 specifies that validating control of a base domain is sufficient to issue a wildcard. But I think folks have have expressed a feeling that that's not strong enough. ACME hasn't hesitated to take a stance on challenge methods. Similarly I think it would be worthwhile to say "this is the default ACME way to get a wildcard, but you can also use out-of-band methods."
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
