Re: [Acme] Directory metadata; wildcard support; conditional authz creation

[Hugo Landau <[e-mail]>]

On Sat, Jan 30, 2016 at 09:26:24PM -0800, Andrew Ayer wrote:
> On Sun, 31 Jan 2016 03:39:25 +0000
> Hugo Landau <[e-mail]> 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