Subject: [Acme] One suggestion for ACME, and also one question about CAA

From: "Sebastian Nielsen" <[email-masked]>
Date: Mon, 13 Nov 2017 11:31:49 +0100

First, I want to make a suggestion, and that is possibility for a permanent
domain authorization.

The CABF says that it is permitted to use SPKI hash or CSR hash as
authentication token, without any nonce.

Since SPKI hash is static for the same public key, and the CSR hash is
static if you use the same CSR all the time, it would be permitted as a
pre-authorization.

Thus avoiding a unnecessary restart of the name server each renew.

This could be combined with that the CAA record must specify that permanent
authorization is permitted for that host.

An question about CAA:

Why was it decided to use a new record type of CAA instead of using TXT?

Using TXT to convey policies has been something that have been in use for a
long time, for example "v=spf1 +mx -all".
Same with SMTP-STS.

The main problem of introducing new record types is that DNS providers & web
hosts need to implement support for these, both in their DNS servers and/or
their web interfaces.

Using TXT for this, example: "v=caa1; f=128; t=issue; d=letsencrypt.org
<http://d=letsencrypt.org/> ;", gives the same advantages, but also the
advantage that any DNS operator supporting TXT, will also support the new
policy.

the record type 99 (SPF) was depreciated for this very reason.

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 13 Nov 2017 13:22:34 +0200

> authentication token, without any nonce.

Such token would be valid for one use only unless timestamped. And
even if timestamped, it would be limited to 30 days at most.

> static if you use the same CSR all the time, it would be permitted as a

The token would still change, see above.

> Thus avoiding a unnecessary restart of the name server each renew.

Use DNS dynamic updates. There is 20 year old RFC(!) describing one
way of doing that. And then there are many DNS-server specific ways.
And automating DNS-01 requires such API anyway.

If talking about HTTP-01, it does not require server restart/reload
in anything I know of. And TLS-SNI-02 is insane without special server
support (which presumably eliminates restarts/reloads too).

-Ilari

---

From: "Sebastian Nielsen" <[email-masked]>
Date: Mon, 13 Nov 2017 12:32:44 +0100

What I have understand with the 30 day limit, is that the authorization granted must be granted for a maximum of 30 days.
Eg, one token, regardless of if its random or static, may either be single-use or allow a maximum of 30 days where the system considers domain as "validated".

And a token must either be a random value, the hash of certificate CSR, or the hash of certificate SPKI.
In the CAB forum guidelines version 1.4.5, I don't see something that require a timestamp, however, they recommend a timestamp in the hash.

The idea is that you should be able to automate set up DNS-01 once, and then is set once for all.

-----Ursprungligt meddelande-----
Från: [email-masked] [mailto:[email-masked]] 
Skickat: den 13 november 2017 12:23
Till: Sebastian Nielsen <[email-masked]>
Kopia: [email-masked]
Ämne: Re: [Acme] One suggestion for ACME, and also one question about CAA

On Mon, Nov 13, 2017 at 11:31:49AM +0100, Sebastian Nielsen wrote:
> First, I want to make a suggestion, and that is possibility for a 
> permanent domain authorization.
> 

Such token would be valid for one use only unless timestamped. And even if timestamped, it would be limited to 30 days at most.

> static if you use the same CSR all the time, it would be permitted as 
> a pre-authorization.

> Thus avoiding a unnecessary restart of the name server each renew.

Use DNS dynamic updates. There is 20 year old RFC(!) describing one way of doing that. And then there are many DNS-server specific ways.
And automating DNS-01 requires such API anyway.

If talking about HTTP-01, it does not require server restart/reload in anything I know of. And TLS-SNI-02 is insane without special server support (which presumably eliminates restarts/reloads too).

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 13 Nov 2017 13:51:41 +0200

> Eg, one token, regardless of if its random or static, may either be single-use or allow a maximum of 30 days where the system considers domain as "validated".

The technical term used by BR is "Request Token"

"
Request Token:  [...]

A Request Token MAY include a timestamp to indicate when it was created.

[...]

A Request Token that includes a timestamp SHALL remain valid for no more
than 30 days from the time of creation.

A Request Token that includes a timestamp SHALL be treated as invalid if
its timestamp is in the future. 

A Request Token that does not include a timestamp is valid for a single
use and the CA SHALL NOT reuse it for a subsequent validation.

[...]
"

Source: CA/Browser Forum: Baseline Requirements for the Issuance and
Management of Publicly-Trusted Certificates. Version 1.5.4, Section
1.6.1: Definitions.

And SHALL/SHALL NOT are absolute requirements.

I.e. tokens themselves may live for at most 30 days.

How long the validations granted can live is actually unclear even
to CABForum partipicants. One could interpret that such grants can be
at most 30 days for tokens, or one could interpret that such grants can
be valid for at most 825 days (the maximum grant lifetime for any
method). 

> and then is set once for all.

There have been proposals in that direction. However, it would take
BR changes.

-Ilari