On Sun, Mar 12, 2017 at 12:11:19PM -0700, Jacob Hoffman-Andrews wrote: > Thanks for the feedback, Hugo! And sorry I've taken so long to reply. I > think most of your comments have been addressed in merged or active PRs. > > On 02/07/2017 09:15 PM, Hugo Landau wrote: > > Finally, I may as well mention wildcard domains again. I don't really > > get the aversion to standardizing this. I previously proposed that these > > be validated by n verification requests from a server to > > randomly-generated, unguessable labels substituting for a wildcard. This > > adequately proves that a wildcard is actually configured and that the > > service located by it is under account control. These would be blind; > > the hostnames used for the requests wouldn't be shown in the > > authorization or challenge objects, so the client wouldn't know what > > names would be used until the verification request comes in. Arguably, > > though, even this is overkill, and just creating authorization objects > > for unblinded, randomly generated names substituting for the wildcard > > would suffice. (In fact, as far as I can tell, nothing in the current > > spec actually prohibits doing this.) > > > > There are real applications for wildcard domains. For example, the > > ability to create unlimited numbers of secure origins has real value to > > some classes of web application. > Yep, I also think it would be nice to standardize wildcard issuance! > Richard's introduction of the "new-order" flow was intended to make > wildcard issuance at least possible, but there's still a big question > mark about what authorizations a server *should* create. To some extent > that is up to server policy, but I think it's worthwhile to recommend on > option. > > Note that the CA/Browser Forum Ballot 169 validation rules indicated > that validating the base domain is sufficient to issue a wildcard > certificate, so we could just echo that. But my feeling of the group is > that folks would like to define a standard way of validating wildcards > that is better than that baseline.
Actually, AFAICT, Ballot 169 rules say something stronger for connection-based methods: Wildcards are validated via base domain. And all ACME methods are connection-based. So from viewpoint of ACME, wildcards are validated by contacting the name identified by stripping the '*.' from beginning. And when it comes to interaction with PSL, the resulting name can be 'PRIVATE' but not 'ICANN'. One pretty obvious thing is strongly splitting challenge responses, so that there is no way wildcard and non-wildcard challenge responses can be mixed up (I think TLS-SNI is the hardest here, as DNS and HTTP are just dumb textual fields)... -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
