Subject: [Acme] Alignment with Changes to the CABForum Domain Validation Requirements

From: "J.C. Jones" <[email-masked]>
Date: Thu, 25 Feb 2016 11:52:07 -0700

All,

The CA/Browser Forum Domain Validation Working Group (DVWG) is
revising the section of the Baseline Requirements that permit the use
of ACME's challenges in compliant CAs; the BRs are the rules that CAs
in the Web PKI are required to follow. The most recent draft [1] was
sent this morning [2] and has several changes that need to be aligned
somehow with ACME.  I wanted to check with the ACME list to see if
there are any changes that we need to propose to the DVWG document to
ensure that it is compatible with using ACME.

The ACME  "Key Authorization" concept in general appears compliant
with the draft BR concept of a "Random Value". That was the intention
of the DVWG and it appears true to me; all subsequent points are
assuming that to be true, but please check!

The DNS-XX challenge appears compliant with the draft BR Paragraph
7.b, assuming that the ballot does not change to specify any prefixes
on the DNS record name.

The HTTP-XX challenge is generally compliant with BR Paragraph 6.b,
but we will need to make sure that whatever string is used in the
challenge is allowed by the BRs. I have proposed to the DVWG that they
permit the ACME path, either explicitly, or by permitting any path
registered with IANA for the purpose of Domain Validation [3].

The TLS-SNI-XX challenges do not appear to be permitted, as there is
no provision in Paragraph 6 for TLS metadata, and the Paragraph 9
definition of a Test Certificate requires the presented certificate to
use the public key from the (eventual) CSR.

  * The TLS-SNI-XX challenges could be construed as permitted if the
challenge defined that an HTTP request should be performed for one of
the well-known paths after connection, as Paragraph 6 does permit the
Random Value to be "any other format as determined by the CA", which
could mean the SNI name. IMO, this is pretty ugly, but might be
livable. That said, the certificate in use would still require the use
of the CSR's keypair.

  * I will work on language for DVWG to propose to permit the use of
TLS connection metadata to hold a "Random Value" without the reliance
on an HTTP GET. If anyone wants to help craft text here, please let me
know off-list.

It would be good to get feedback as soon as possible.  I have until
Friday, 4 March 2016 to obtain support for updates to the draft before
it is presented to the full CAB Forum for a vote on adoption. Once
adopted, this ballot will give a 6 month period for all CAs to revise
their validation methods to be compliant.

1) https://cabforum.org/pipermail/validation/attachments/20160225/d0015505/attachment-0001.pdf
2) https://cabforum.org/pipermail/validation/2016-February/000209.html
3) https://cabforum.org/pipermail/validation/2016-February/000210.html

--
J.C. Jones

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 25 Feb 2016 21:46:05 +0200

> livable. That said, the certificate in use would still require the use

Does the domain requested have to match domain to be verified? If it
does, that would be extremely nasty, since renewal would mean downtime,
and I don't see that being popular...

And how would that modified version of TLS-SNI-XX work?

-Ilari

---

From: "J.C. Jones" <[email-masked]>
Date: Thu, 25 Feb 2016 13:50:41 -0700

The correct approach to protect the TLS-SNI series of challenges is to
adjust the BRs to permit it, rather than attempt to shoehorn it in. :)

Still, as to the shoehorning:

It's unclear to me whether the "Authorization Domain Name", as the
draft BRs define it, must be used for the SNI field. I believe that
was the intention, but the letter of the draft does not appear to
require it. The draft wording of Paragraph 9, where TLS-SNI has the
most overlap, is:

>   9. Confirming the Applicant's control over the requested FQDN by
>   confirming the presence on the FQDN of a Test Certificate (using the
>   same public key) issued by the CA for the purposes of this method
>   and which is accessible by the CA via TLS over an Authorized Port.

The workflow that /might/ satisfy could be:

1. Client creates (or loads) the keypair KP_final that will be used
for example.com

2. Client posts to the New Authorization endpoint requesting challenges

3. Client constructs a self-signed certificate, using the keypair
KP_final and the ACME-specified SAN

4. Client configures the normal “<Z[0:32]>.<Z[32:64]>.acme.invalid”
SNI value to present the self-signed certificate

5. Client completes the TLS-SNI challenge per spec via the
Authorization endpoint

6. Client creates a CSR for example.com using KP_final

7. Client downloads and installs the CA-signed certificate, using
KP_final as the key

J.C. Jones

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 25 Feb 2016 23:57:10 +0200

> 7. Client downloads and installs the CA-signed certificate, using
 
There's also question about what "issued by the CA" in context of
test certificate (which is defined term) means.

If you could pull that off in context of DV guidelines, I don't see
why one couldn't just stick the account key in critical extension and
self-sign the thing with the final key and bind that to some SNI (this
is stateless method even)...

(I actually think that might fly (modulo possible same name requirement)
if there was CA signature using key dedicated for signing (yes, totally
pointless security-wise) on that cert...)

-Ilari

---

From: Peter Eckersley <[email-masked]>
Date: Thu, 25 Feb 2016 14:19:52 -0800

Last July I believe James Kasten drafted a minor adjustment to the DVWG's
draft so that it would cover DVSNI/TLS-SNI-01, and tried to send it to
the DVWG.

He proposed slightly adjusting the language of clause 9 to allow a
Request Token to be contained within the Test Certificate instead:

# 9. Having the Applicant demonstrate practical control over the FQDN by 
the Applicant requesting and then installing a Test Certificate issued
by the CA, or installing a Test Certificate containing a Random Value or
Request Token on the FQDN which is accessed and then validated via https
by the CA either at port port 80, SMTP, 443, SFTP, …. (Addition is
highlighted in yellow) 

Making that change to the DVWG proposal is much more sensible that
changing the wire protocol, which will break any client populations that
aren't auto-updating.

On Thu, Feb 25, 2016 at 11:52:07AM -0700, J.C. Jones wrote:
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
> 

-- 
Peter Eckersley                            [email-masked]
Chief Computer Scientist          Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993