On Sat, Jan 30, 2016 at 09:26:24PM -0800, Andrew Ayer wrote: > On Sun, 31 Jan 2016 03:39:25 +0000 > Hugo Landau <[email protected]> wrote: > > > A proposed scheme for wildcard support. > > <https://github.com/ietf-wg-acme/acme/pull/74> > > 1. I don't think ACME should support wildcard characters anywhere but > the leftmost label. RFC6125 says TLS clients SHOULD NOT match wildcards > in other labels, and in practice neither clients nor CAs support them. > > 2. The validation mechanism is insecure when a domain allows > users to register arbitrary sub-domains and host content on them > (e.g. github.io, Amazon S3). For example, if I create a wildcard > authz for *.github.io, the server will issue challenges for some > random sub-domains (e.g. df2icxw7mg5gbbfc636ttbwsmi.github.io, > fonm6ymv77dlpac2qfvyjns4u4.github.io). I can go register those > sub-domains at github.io (since the sub-domain labels have high entropy, > they will be available with high probability), complete the challenges, > and then be authorized for all of *.github.io. To fix this, the server > should also require I complete a challenge for the "underlying" > identifier (github.io in this example). > > 3. It's not specified how the server communicates to the > client what sub-domains need to be validated. You misunderstand, perhaps I should clarify the wording; the server never tells. You don't get to know the random subdomains it requests. This ensures that the wildcard exists and is under control.
Adding a requirement for base domain control would be fine but I don't see the need. > > I suggest that the HTTP, DNS, and TLS SNI challenge objects be extended > to include a "hostname" field, which specifies the hostname under which > the challenge must be completed. The server can then make use of the > existing combinations mechanism to require the client complete > challenges under several sub-domains. > > Perhaps ACME shouldn't even specify how wildcard identifiers are > validated, but leave it as a matter of CA policy. Some CAs might be > fine only requiring a challenge on the underlying domain (which is how > some CAs currently validate wildcard certs), while others would require > challenges on random sub-domains. The policy might even be different > depending on challenge type: the CA might accept either a single DNS > challenge on the underlying domain, or a combination of HTTP challenges > on the underlying domain and several random sub-domains. This might be a good idea. > > -- Andrew _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
