Subject: [Acme] Support issuing certificates to subdomains when top level domain-ownership can be verified

From: Jostein Kjønigsen <[email-masked]>
Date: Tue, 26 Jul 2016 15:31:45 +0200

Dear Ladies and gentlemen of the IETF.

I was commenting on a Github issue for the ACME-spec with regard to
issuing certificates for subdomains based on proven higher level
domain ownership. As a response I was asked to forward my request
here. And so I will.
The scenario of wanting to issue certificates for specific hosts while
at the same time having a secondary subject (a top level DNS round
robin for redundancy) is a very normal use-case. One example would be
IRC-servers.
My request for the ACME would be: If I can prove I own the top level
domain, I should also be allowed to issue certs for any subdomain
without need for verification of those.
A concrete example of this would be allowing users to connect to
"toplevel.net" (a DNS round-robin), This can resolve to a number of
hosts. Let's say this resolves to an IP which is also equivalent to "host-
a.toplevel.net". For a user to be able to *either* use the DNS round-
robin or a specific host, that host need a certificate which can cover
both these DNS names. Same applies to "host-b.toplevel.net", "hots-
c.toplevel.net" etc.
Certificates for a redundant setup like this cannot currently be setup
using letsencrypt and ACME, because both domains cannot be verified on
the one machine running the ACME client.
Without support for this, I'm forced to use StartSSL for my cert needs
(as they *will* issue certificates for any subdomains of a domain I can
prove ownership of).

 (For those curious, the full github issue and related discussion can be
 found here: https://github.com/letsencrypt/acme-spec/issues/104)

Thank you for your attention.
--
Sincere Greetings
Jostein Kjønigsen
https://jostein.kjonigsen.net

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 26 Jul 2016 15:55:28 +0000

> My request for the ACME would be: If I can prove I own the top level domain, I should also be allowed to issue certs for any subdomain without need for verification of those.

Speaking as an individual, not co-chair.

As a counter-example, if I own wordpress.net should I be able to get a cert for every single sub-domain?  Or github.io?  Or places like the government where sub-domains are probably separate organizations?  And then how do you ensure that the right sub-domain owner gets the certificate and key?

I am against this change.

---

From: Peter Bowen <[email-masked]>
Date: Tue, 26 Jul 2016 09:00:00 -0700

On Tue, Jul 26, 2016 at 6:31 AM, Jostein Kjønigsen
<[email-masked]> wrote:
> The scenario of wanting to issue certificates for specific hosts while at
> the same time having a secondary subject (a top level DNS round robin for
> redundancy) is a very normal use-case. One example would be IRC-servers.
>
> My request for the ACME would be: If I can prove I own the top level domain,
> I should also be allowed to issue certs for any subdomain without need for
> verification of those.

I don't see anything in the ACME specification that disallows this at
the protocol level.  I think a CA could request you validate a DNS
identifier of 'example.com', then accept that authorization for the
issuance of 'ship.example.com'.  Conversely, ACME does not require CAs
allow such and I hope it stays that way.  CA policy should be distinct
from ACME.

Thanks,
Peter

---

From: Patrick Figel <[email-masked]>
Date: Tue, 26 Jul 2016 18:48:36 +0200

On 26/07/16 18:00, Peter Bowen wrote:
> I don't see anything in the ACME specification that disallows this
> at the protocol level.  I think a CA could request you validate a
> DNS identifier of 'example.com', then accept that authorization for
> the issuance of 'ship.example.com'.  Conversely, ACME does not
> require CAs allow such and I hope it stays that way.  CA policy
> should be distinct from ACME.

Agreed that this should be a policy decision. It's worth pointing out,
however, that prior drafts contained language that made it clear that
it's a policy decision, which seems to have been removed in the acme-03
draft. It used to read:
"It is up to the server's local policy to decide which names are
acceptable in a	certificate, given the authorizations that the server
associates with the client's account key."

Was this removed deliberately, or did it get lost as part
of the "Application" change? I think it would make sense to add
something like that to the CA Policy Considerations section, just to
make it clear that this is indeed a policy decision (unless the WG
thinks otherwise?)

---

From: Richard Barnes <[email-masked]>
Date: Tue, 26 Jul 2016 22:13:49 +0200

On Tue, Jul 26, 2016 at 6:48 PM, Patrick Figel <[email-masked]> wrote:

> Agreed that this should be a policy decision.

+1

> It's worth pointing out,

It was a side-effect of the "application" refactor.

ISTM that the "application" approach is way more flexible with regard to
this sort of thing.  Before, the assumption was that you would do a
"new-authz" for each specific name, and there was no way for the server to
tell you that you just needed to prove control of the top-level domain.
With the "application" approach, you can send in a CSR, and the server can
tell you just to authorize the top-level name.

Could someone file an issue to re-add this text?  Or better yet, send a
PR?  :)

All that said, I don't really think this style of validation is a good
idea, for the reasons Rich points out.  But this is not really the place to
have that discussion.

--Richard

>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 26 Jul 2016 13:34:28 -0700

>> Agreed that this should be a policy decision.

So, it's more than a policy decision, unfortunately; it's a combination of
two properties of the DNS that are problematic.  The first is that control
of a specific label has no easily generalized implication about
administrative control of subsidiary labels.  The IAB controls .ARPA, for
example, but has delegated e164.arpa in a way that would make allowing the
IAB to request certificates for delegations under it to be a pretty
problem.  The same problem occurs for many gTLDs, ccTLDs, and a number of
second level domains.  The work in the DBOUND working group also notes this
in describing delegation
<https://datatracker.ietf.org/doc/draft-deccio-dbound-organizational-domain-policy/?include_text=1>
:

"However, policies governing the use of domain names do not always align
with those lines of delegation.  There are currently no generally reliable
methods to reconcile domain names with policy for their use."

They are working on the problem, of course, but it is still a problem.

The second issue is that this seriously worsens the cache poisoning attack;
if you manage to cache poison the CA's view of the hierarchical ancestor,
you would now be able to generate certificates for all its descendants.

So, while I agree that this is a policy issue, I believe that the
specification should have a statement that the default  should be
restrictive and why.  I don't think that the text should be in an appendix,
frankly, but should be pretty much front and center with appropriate
warnings.

(as an individual)

Ted

---

From: Philipp Junghannß <[email-masked]>
Date: Tue, 26 Jul 2016 22:52:36 +0200

well I brought this already up as "walk-up authorisations" or similar.

Rich Salz brought up domains like wordpress.com and github.io as examples
where the parent shouldnt get certs with another check, but I personally
think that this is junk.
this is (obviously) because the parent could take control of the subdomain
and verify it anyway that's just how the system works. not allowing a walk
up for subs just makes it more annoying.

also talking about cache-poisoning and other funny stuff, one could say
that walk up only can occur only in certain conditions, for example that
there needs a flag set as a record in DNS and secured by DNSSec and the CA
could easily check the DNSSec. also unlike the CA system DNSSec works with
a tree-like structure so it's pretty limited on who can sign for what.

for example for the domain "google.com" there are only 3 entities that can
sign for it. one is obviously Google themselves, then we have the
Management of the .com DNSSec key and finnaly (obviously enough) the ICANN
with the root key.

so one could say that if the authorisation is done via DNSSec'ed DNS
authorisation plus a record indicating walk-up it would be fine enough and
that would be pretty strict.

it may be that in some cases the subdomains are controlled by another
entity but it isnt a secret that the parent can take control anyway.

That's just my opinin.

Best regards (or for all the german readers, MFG)

Philipp Junghannß / My1

2016-07-26 22:34 GMT+02:00 Ted Hardie <[email-masked]>:

> second level domains.  The work in the DBOUND working group also notes
> this in describing delegation
> The second issue is that this seriously worsens the cache poisoning
> attack; if you manage to cache poison the CA's view of the hierarchical
> ancestor, you would now be able to generate certificates for all its
> descendants.
>

---

From: James Cloos <[email-masked]>
Date: Tue, 26 Jul 2016 16:54:14 -0400

>>>>> "TH" == Ted Hardie <[email-masked]> writes:

TH> The first is that control
TH> of a specific label has no easily generalized implication about
TH> administrative control of subsidiary labels.

Which is why we have publicsuffix.

The language should note that a public suffix does not get to do this.

But everything else should get to.  (Even the examples Rich noted,
unless any of them are in the publicsuffix db.)

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Ted Hardie <[email-masked]>
Date: Tue, 26 Jul 2016 14:44:02 -0700

> unless any of them are in the publicsuffix db.)
Hi Jim,

The DBOUND group I referenced is working on a dns-based distributed
successor to the public suffix list (see the charter here:
https://datatracker.ietf.org/wg/dbound/charter/).  The problem is the
same.

regards,

Ted

---

From: James Cloos <[email-masked]>
Date: Tue, 26 Jul 2016 18:32:25 -0400

>>>>> "TH" == Ted Hardie <[email-masked]> writes:

TH> The DBOUND group I referenced is working on a dns-based distributed
TH> successor to the public suffix list (see the charter here:
TH> https://datatracker.ietf.org/wg/dbound/charter/).  The problem is the
TH> same.

Ah, yes.  I'd forgotten about them.  (Subscribed, so that I can catch up
any time, but hadn't done so in a few weeks....)

That would be an viable way for acme issuers to confirm whether any
given name claims to have any separately owned children.

-JimC

---

From: Alan Doherty <[email-masked]>
Date: Wed, 27 Jul 2016 15:22:50 +0100

currently they can in the acme client

one method is dns auth (the client is run on the machine with access to dns records and authenticates each at same time)

another used by many is as the client follows redirections

on primary domain and each sub-domain server redirect /acme-url/ to acme.primary-domain/acme-url/
run acme client on machine that a record for acme.primary-domain points at once all san certs retrieved copy them to the relevant member servers

or what i do, i run a 3rd party bash letsencrypt.sh client and after auth key is retrieved it rsyncs the key to all other servers in the cdn/cluster then proceeds (thus which server the letsencript server connects to it irrelevant)

At 14:31 26/07/2016  Tuesday, Jostein Kjønigsen wrote:
>I was commenting on a Github issue for the ACME-spec with regard to issuing certificates for subdomains based on proven higher level domain ownership. As a response I was asked to forward my request here. And so I will.
>
>The scenario of wanting to issue certificates for specific hosts while at the same time having a secondary subject (a top level DNS round robin for redundancy) is a very normal use-case. One example would be IRC-servers.
>
>A concrete example of this would be allowing users to connect to "toplevel.net" (a DNS round-robin), This can resolve to a number of hosts. Let's say this resolves to an IP which is also equivalent to "host-a.toplevel.net". For a user to be able to either use the DNS round-robin or a specific host, that host need a certificate which can cover both these DNS names. Same applies to "host-b.toplevel.net", "hots-c.toplevel.net" etc.
>
>Certificates for a redundant setup like this cannot currently be setup using letsencrypt and ACME, because both domains cannot be verified on the one machine running the ACME client.
>
>Without support for this, I'm forced to use StartSSL for my cert needs (as they will issue certificates for any subdomains of a domain I can prove ownership of).
>(For those curious, the full github issue and related discussion can be found here:<https://github.com/letsencrypt/acme-spec/issues/104> https://github.com/letsencrypt/acme-spec/issues/104)
>
><https://jostein.kjonigsen.net>https://jostein.kjonigsen.net
>