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

From: Hugo Landau <[email-masked]>
Date: Sun, 31 Jan 2016 03:39:25 +0000

More proposals from me.

Add metadata to directory. This is quite needed.
<https://github.com/ietf-wg-acme/acme/pull/72>

A proposed scheme for wildcard support.
<https://github.com/ietf-wg-acme/acme/pull/74>

Allow authorizations to be created conditionally.
<https://github.com/ietf-wg-acme/acme/pull/77>

Hugo Landau

---

From: Andrew Ayer <[email-masked]>
Date: Sat, 30 Jan 2016 21:26:24 -0800

On Sun, 31 Jan 2016 03:39:25 +0000

> <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

---

From: Hugo Landau <[email-masked]>
Date: Sun, 31 Jan 2016 08:40:03 +0000

> 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.

> on the underlying domain and several random sub-domains.
This might be a good idea.

---

From: Andrew Ayer <[email-masked]>
Date: Sun, 31 Jan 2016 08:51:31 -0800

On Sun, 31 Jan 2016 08:40:03 +0000

> Adding a requirement for base domain control would be fine but I don't

Ohhh, I see.  Yes, I misunderstood.  That seems secure and I agree the
base domain doesn't need to be validated with that scheme.

Perhaps the "hostname" field I proposed could support wildcards.  If the
server sends the client a challenge with a wildcard in the hostname,
the client would need to be prepared to respond to the challenge on any
hostname matching the wildcard.  The CA can choose whether to send
a challenge for "*.example.com" or just "example.com" when validating a
wildcard authz for "*.example.com".

That said, it seems like it might be hard for the client to complete
the challenge when it doesn't know the exact hostnames. Apache and nginx
support wildcards for matching virtual hosts, but do other web servers?
DNS only supports wildcards in the left-most label, so there's no way to
provision a TXT record for _acme-challenge.*.example.com unless you have
a fancy DNS server.  (Although I don't think this scheme is needed with
DNS - I don't think there's a likely scenario where someone could set a
TXT record for _acme-challenge.example.com, but not for _acme-challenge
in any arbitrary sub-domain of example.com.)

-- Andrew

---

From: Richard Körber <[email-masked]>
Date: Sun, 31 Jan 2016 20:01:19 +0100

> wildcard authz for "*.example.com".

I couldn't think of a situation where someone owns and controls a domain, but
would be unable to control any of the subdomains.

So, wouldn't it be sufficient that for a wildcard domain (*.example.com), only
the domain itself (example.com) is challenged?

-- 
Richard Körber

---

From: Hugo Landau <[email-masked]>
Date: Sun, 31 Jan 2016 20:37:21 +0000

By this logic it should be allowed to obtain a certificate for any
domain x.y.z.example.com. if you have an authorization for example.com.
That might be justifiable, but it's a big divergence from the current
design of the protocol.

I think given the current design of the protocol, it would be
inconsistent to allow wildcard domains to be created due to a base
domain authorization.

On Sun, Jan 31, 2016 at 08:01:19PM +0100, Richard Körber wrote:
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme