Subject: [Acme] ACME / LURK consistency

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 19 Mar 2016 11:02:16 -0400

As people here are probably aware, there is a BOF for LURK which is to
do with some form of remote keying (maybe).

Since the narrowest scope that might be decided for LURK is supporting
TLS. I think there is going to be a lot of co-development and
co-deployment. So it seems to me that LURK and ACME should look alike
as much as possible and allow as much code re-use between the two.

For me the consistency should ideally result from the same tool set to
build the code.

The proposal I have made for the LURK proposal is fairly
comprehensive. It has a full text specification, a reference section
describing the complete protocol and examples that were produced from
running code:

https://tools.ietf.org/html/draft-hallambaker-lurk-00

That draft was produced in three days, most of which was spent on the
design and writing the prose.

Developing specifications this way isn't just quicker, it is a lot
less frustrating and error prone. It also helps get to implementations
faster.

For obvious reasons, I prefer to write in a modern language (C#). But
the toolset also generates code for C. Adding a new target language
takes about a week and some knowledge of the code synthesis system I
am willing to share.

So this doesn't just make creating the specification easier, it makes
it much easier to get to production code that has to be written in
target languages that match what currently exists.

Which is why the issue of nested vs flat matters to me quite a lot.

Yes, I could rewrite the code synthesizer to support a data format
that allows the type of the data structure to appear as a field
anywhere inside it. But it would mean creating what is essentially a
whole new synthesizer just for ACME. And that would take about as long
as writing a backend for a whole new language. And that work would
then have to be repeated for every other target language.

The nested style imposes fewer development constraints and allows for
implementations that are more efficient in both time and memory
footprint.

---

From: Alan Doherty <[email-masked]>
Date: Mon, 21 Mar 2016 02:03:44 +0000

off topic and possibly inappropriate introduction

but i can see a potential issue in our (and others) future
when it comes to using acme/letsencrypt SAN certs in a CDN environment

as before we get to actual subdomains running separate sites we tend to ave a minimum of (on our current cdn/reverse proxy)

example.com                <usually a redirect to www
www.example.com            <usually the html content
static.example.com         <usually the images/videos anything where dropping cookies by using a different name improves throughput and allows us to use extended caching

this is a minimum per customer, some obviously have many differentiated subdomains support /shop etc etc

but by allowing the possibility of wildcards we could at least reduce by 2 thirds the names needed on a single cert

many many more on certs for our submission and pop3(tls) servers
where we currently use CA certs as customers connect to 
customerid.smtps.orionnetworks.com  or customerid.pop3a.orionnetworks.ie and the non-trusted by default is not a major issue
as our certs cover just *.smtps.orionnetworks.com port 587 or *.pop3a.orionnetworks.ie 

where customerid is not a wildcard in dns (but could be during verification), we use this so when a customer is gone we can also kill the dns and stop seeing the attempted logins from their gmail/hotmail/other provider where they never clean/remove dead pop3/smtp accounts

i would propose for either http or dns verification requiring at least a temporary wilcard in dns
then for the verification server to either lookup
http://random-generated.domain.tld/.well-known/acme-challenge/challenge-string

dns verification is trickyer but could require instead of
_acme-challenge.example.com. 300 IN TXT "token"

_acme-challenge.challenge-string.example.com. 300 IN TXT "token"

for example or
_acme-challenge._wildcard_.example.com. 300 IN TXT "token"

or to demon straight ability to create wildcards 
random-generated._acme-challenge.example.com. 300 IN TXT "token"

as this would require the applicant setup
*._acme-challenge.example.com.

i hope this is the right place if not please feel free to redirect me, as either way acme is a huge leap forward in cert issuance and improving reliability through automation

---

From: Niklas Keller <[email-masked]>
Date: Mon, 21 Mar 2016 09:02:30 +0100

> http://random-generated.domain.tld/.well-known/acme-challenge/challenge-string

That's not possible, because several providers allow the registration of
any subdomain, e.g. DynDNS providers.

> _acme-challenge.challenge-string.example.com. 300 IN TXT "token"

For DNS challenges, I think it's fine when _acme-challenge.example.com
authorizes *.example.com.

> i hope this is the right place if not please feel free to redirect me, as
> either way acme is a huge leap forward in cert issuance and improving
> reliability through automation
>

Regards, Niklas

---

From: Philipp Junghannß <[email-masked]>
Date: Mon, 21 Mar 2016 09:46:10 +0100

I think so too.

but I also think that while talking about wildcard validation in DNS that
it would be pretty intresting to bring this up:
https://github.com/ietf-wg-acme/acme/issues/89
in short, this would let the dns-challenge walk up meaning that if you
already have completed the challenge for a higher level domain you can
automatically also count as authorized for a subdomain.

this would also be nice because the randomness of the token makes it REALLY
annoying to create a large SAN cert in a manual environment (e.g. there's
no proper client for your use-case, machine etc.)
before the DNS Challenge was a thing I had to copy the strings for
webroot/http-01 auth from my SSH to my computer (while making sure not to
hit ctrl-c because it doesnt copy but cancel in terminal, making it even
more annoying as it already is.)

Regards.

2016-03-21 9:02 GMT+01:00 Niklas Keller <[email-masked]>:

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

---

From: Alan Doherty <[email-masked]>
Date: Mon, 21 Mar 2016 09:31:30 +0000

At 08:02 21/03/2016  Monday, Niklas Keller wrote:
><http://random-generated.domain.tld/.well-known/acme-challenge/challenge-string>http://random-generated.domain.tld/.well-known/acme-challenge/challenge-string
>
>
>That's not possible, because several providers allow the registration of any subdomain, e.g. DynDNS providers.

thats why the random part at the beginning of thr checked url was added (only known to the verifier)
as long as its long and suitably random it can only match a *.domain.tld in dns (that is added at least till verification completes)
not any pre-existing some-other-sub-domain.domain.tld

and on the server side (if using name based vhosts) it will only match the primary (default) or explicit *.domain.tld

so requiring a certain level of difficulty/unerstanding for those needing wildcards (as it really should)

im personally not a fan of the assumption that owning the http://domain.tld should authorize all wild cards above it automatically

as the admin of the server for many customer sites i feel fine issuing myself a san for the hosted with us www.theirs.tld and theirs.tld but not for *.theirs.tld unless their dns admin is happy about it also 

but i think if you can http or dns verify the ownership and desire for a wilcard it should be possible

>Â 
>_<http://acme-challenge.example.com>acme-challenge.example.com. 300 IN TXT "token"
>
>_<http://acme-challenge.challenge-string.example.com>acme-challenge.challenge-string.example.com. 300 IN TXT "token"
>
>
>For DNS challenges, I think it's fine when _<http://acme-challenge.example.com>acme-challenge.example.com authorizes *.<http://example.com>example.com.
>Â 
>for example or
>_acme-challenge._wildcard_.<http://example.com>example.com. 300 IN TXT "token"
>
>random-generated._<http://acme-challenge.example.com>acme-challenge.example.com. 300 IN TXT "token"
>
>*._<http://acme-challenge.example.com>acme-challenge.example.com.
>
>
>Regards, NiklasÂ