Subject: Re: [Acme] Final thoughts on draft-ietf-acme-acme-05

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Sun, 12 Mar 2017 12:11:19 -0700

Thanks for the feedback, Hugo! And sorry I've taken so long to reply. I
think most of your comments have been addressed in merged or active PRs.

On 02/07/2017 09:15 PM, Hugo Landau wrote:
> Finally, I may as well mention wildcard domains again. I don't really
> get the aversion to standardizing this. I previously proposed that these
> be validated by n verification requests from a server to
> randomly-generated, unguessable labels substituting for a wildcard. This
> adequately proves that a wildcard is actually configured and that the
> service located by it is under account control. These would be blind;
> the hostnames used for the requests wouldn't be shown in the
> authorization or challenge objects, so the client wouldn't know what
> names would be used until the verification request comes in. Arguably,
> though, even this is overkill, and just creating authorization objects
> for unblinded, randomly generated names substituting for the wildcard
> would suffice. (In fact, as far as I can tell, nothing in the current
> spec actually prohibits doing this.)
>
> There are real applications for wildcard domains. For example, the
> ability to create unlimited numbers of secure origins has real value to
> some classes of web application.
Yep, I also think it would be nice to standardize wildcard issuance!
Richard's introduction of the "new-order" flow was intended to make
wildcard issuance at least possible, but there's still a big question
mark about what authorizations a server *should* create. To some extent
that is up to server policy, but I think it's worthwhile to recommend on
option.

Note that the CA/Browser Forum Ballot 169 validation rules indicated
that validating the base domain is sufficient to issue a wildcard
certificate, so we could just echo that. But my feeling of the group is
that folks would like to define a standard way of validating wildcards
that is better than that baseline.

Also: I think wildcards are a big enough topic that it probably doesn't
make sense to try and land any significant changes before the spec is
finalized, but they would be a good follow-on spec.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 12 Mar 2017 22:11:01 +0200

> that is better than that baseline.

Actually, AFAICT, Ballot 169 rules say something stronger for
connection-based methods: Wildcards are validated via base domain.
And all ACME methods are connection-based. So from viewpoint of ACME,
wildcards are validated by contacting the name identified by stripping
the '*.' from beginning.

And when it comes to interaction with PSL, the resulting name can be
'PRIVATE' but not 'ICANN'. 

One pretty obvious thing is strongly splitting challenge responses, so
that there is no way wildcard and non-wildcard challenge responses can
be mixed up (I think TLS-SNI is the hardest here, as DNS and HTTP are
just dumb textual fields)...

-Ilari

---

From: Alan Doherty <[email-masked]>
Date: Sun, 12 Mar 2017 22:03:05 +0000

i think to issue wildcards (with minimal issues for validation, but direct owner allow/dissalow)

some well-known-subdomain could be used

example

acme-wildcard-auth.parent.tld  must exist for *.parent.tld to be applied for 
or
acme-wildcard-CAuniquestring-auth.parent.tld

if you want to make it possible to pre allow 1 or more acme-CA(s) only

the ip it points to can then be used in http/tls-sni 
and dns-based auth obviously can use same (but requires no ip)

thus domains without this sub-domain cant (as by not creating it they do not wish to use acme to register wildcards)

as the domain would then require the admin of domain.tld to set it up in advance (but once)
for the use by an acme-client thats using http auth for example

(as this would match both real wildcards in dns, and those like myself wanting to use wildcards to cut down on oversize san certs where 90 sites are from 1 parent domain and the others are all unique (as it cuts the names in the san by 89 leaving room for more unique sites)

At 19:11 12/03/2017  Sunday, Jacob Hoffman-Andrews wrote:
>_______________________________________________
>Acme mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/acme