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

[Andrew Ayer <[e-mail]>]

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.

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.

-- Andrew