Subject: [Acme] Potential future incompatiblity between HTTP-01 and CABForum BRs

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 10 Apr 2017 19:13:01 +0300

I read a draft for ballot[1] about changes to CABForum BR domain
validation rules, and noticed that it drops the "required website
content" bit, only retaining the Random Value and Request Token
bits. Now, request token parts are irrelevant: HTTP-01 clearly does
not qualify as request token.

This leaves Random Value. There there is also a requirement that the
Random Value does not appear in the request. Now, obviously HTTP-01
does put the Random Value into request. So it seemingly would not
comply.

Having to drop HTTP validation without replacement would be very
bad to say the least. Estimated number of domains using it is in
millions, and for vast majority, there is no viable replacement
(besides disabling HTTPS, perhaps using commercial cert to ride
HSTS timeout)..

Maybe the WG could define HTTP-02 that doesn't send the same
random value back? It would also solve the known issue that one
can mint responses without knowing about the challenge
(TLS-SNI-01 had a similar issue).

As to why they want to drop the "required website content" bit,
historically, many CAs have invented many quite bad validation
methods, some based on methods from Baseline Requirements.

[1] AFAIK, not yet in pre-voting discussion, but has the two
endorsers needed to start official pre-voting discussion.

-Ilari

---

From: Roland Bracewell Shoemaker <[email-masked]>
Date: Mon, 10 Apr 2017 10:55:25 -0700

I'm not sure why the contents of the http-01 challenge could not be
considered a 'request token'? A favorable interpretation that would
require no changes would be that the random token (in ACME speak) is
only half of the 'request token' (CABF speak) that is required for
validation and therefore the full 'request token' _is not_ present in
the request (since the required key authorization contains both the
random token and the thumbprint of the JWK public key).

On 04/10/2017 09:13 AM, Ilari Liusvaara wrote:
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 10 Apr 2017 22:14:39 +0300

> random token and the thumbprint of the JWK public key).

The problem here is two SHALL (i.e. RFC2119 MUST) -level requirements
on Request Tokens:

- They incorporate the "key used in the certificate request"
- Non-timestamped Request Tokens are single-use (timestamped ones are
  valid for maximum of 30 days).

(Section 1.6.1 of CABForum baseline requirements version 1.4.4)

My reading of "key used in the certificate request" is the CSR public
key, which can't match the account key anyway (and in the case of
Let's Encrypt as of today, isn't even known). There is no definition
of "certifiate request" as far as I can see.

As for the second requirement, there is actually a twisted reading
that might be met: There is no requirement to bind the timestamp or
the use-once diversification to the rest of the token in any way.
Let's throw the random value as use-once diversification (LOL),
it certainly renders the response unique...

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 11 Apr 2017 21:34:19 +0300

> of "certifiate request" as far as I can see.

Well, thinking about it, ACME-01 as used by LE seems to imply that
challenges are in response to "certificate requests" (regardless of
what ACME calls it). And those requests _are_ keyed by the account key.

Things get more screwy when one moves to ACME-06 (which is presumably
close to ACME-final) without preauthorization. Now the requests have
two keys, and BRs assume there is only one...

(One also seemingly has to take somewhat wide interpretations of
things to get TLS-SNI-01/TLS-SNI-02 to fit into "10 methods").

-Ilari

---

From: Jeremy Rowley <[email-masked]>
Date: Wed, 12 Apr 2017 21:47:49 +0000

The proposal drops "Required Website Content" because the requirement was
redundant with the other option in the same section.  Required Website
Content is defined as a "Random Value or Request Token" plus extra
information. If you replaced the phrase with the definition, Section
3.2.2.4.6 would state that a CA can either validate domain control using 1)
a request token or random value OR 2) a request token or random value plus
additional info. There's no point in including the additional info in a
requirement if the methods overlap so much.

Jeremy

-----Original Message-----
From: Acme [mailto:[email-masked]] On Behalf Of Ilari Liusvaara
Sent: Monday, April 10, 2017 10:13 AM
To: [email-masked]
Subject: [Acme] Potential future incompatiblity between HTTP-01 and CABForum
BRs

I read a draft for ballot[1] about changes to CABForum BR domain validation
rules, and noticed that it drops the "required website content" bit, only
retaining the Random Value and Request Token bits. Now, request token parts
are irrelevant: HTTP-01 clearly does not qualify as request token.

This leaves Random Value. There there is also a requirement that the Random
Value does not appear in the request. Now, obviously HTTP-01 does put the
Random Value into request. So it seemingly would not comply.

Having to drop HTTP validation without replacement would be very bad to say
the least. Estimated number of domains using it is in millions, and for vast
majority, there is no viable replacement (besides disabling HTTPS, perhaps
using commercial cert to ride HSTS timeout)..

Maybe the WG could define HTTP-02 that doesn't send the same random value
back? It would also solve the known issue that one can mint responses
without knowing about the challenge
(TLS-SNI-01 had a similar issue).

As to why they want to drop the "required website content" bit,
historically, many CAs have invented many quite bad validation methods, some
based on methods from Baseline Requirements.

[1] AFAIK, not yet in pre-voting discussion, but has the two endorsers
needed to start official pre-voting discussion.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 13 Apr 2017 07:34:21 +0300

> requirement if the methods overlap so much.

Oh yeah, this is into lawyering, and I'm not good at that. I'm much
more an engineer than a laywer and the languages are pretty much polar
opposites. :-)

I can see a valid interpretation of HTTP-01 in terms of BRs now.
Thanks.

-Ilari