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

From: Hugo Landau <[email-masked]>
Date: Thu, 25 Feb 2016 21:01:03 +0000

As was previously discussed, it would be desirable to allow
authorization to emerge from values (e.g. in DNS) which are not random,
but which unambiguously identify an account (i.e. an ACME account key
thumbprint).

It would be nice if this revision to the BRs was used as an opportunity
to secure such change. Is such a thing politically/otherwise infeasible?

Hugo Landau

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

----- End forwarded message -----

---

From: "J.C. Jones" <[email-masked]>
Date: Thu, 25 Feb 2016 14:17:39 -0700

Hugo,

There's a concept on the new DV ballot called a Request Token which could
accomplish this: a structure somehow incorporating the subject public key
that is eventually used in the certificate.

The Request Token currently is only defined using the subject public key, but
could be expanded to include the concept of an account key. That amount of
scope increase sounds difficult to pull off in the next week, but we are invited
to propose another update after this one.

It seems to me that the DVWG's preferred approach would be to have ACME
provide protocol leadership, and then for them to review and bless validation
methods for use in the web PKI.

- J.C.

---

From: Hugo Landau <[email-masked]>
Date: Fri, 26 Feb 2016 00:03:38 +0000

So the problem with this is that it requires authorizations to be issued
based on information which can only be known at issuance time, and ACME
separates these steps. You can't know the certificate public key until
after you've obtained all the necessary authorizations.

One possible solution to this would be to add 'authorization
constraints' as a mechanism, whereby a client can request constraints,
and servers can include them in completed authorizations, either in
response to such solicitations or spontaneously. One such constraint
could be a certificate public key.

I previously on this list contemplated the autocreation of
authorizations from DANE records and noted that it would require a
mechanism such as this since such records nominate particular
end certificate keys. So such a mechanism would have wider utility and
potentially open things up to alternative, but no less secure (or
possibly even more secure), validation mechanisms.

However, it is undeniable that this would be a major change to the ACME
protocol, and the DANE case remains very academic. So it seems very
unconvincing to me that this change should be made, since it complicates
the protocol for no actual increase in security as it is used today.

The problem seems to be that the BR requirements are predicated on the
idea that while, yes, an end certificate public key can be endorsed,
this does not extend to the endorsement of a key which in turn endorses
an end certificate key (in the ACME case, an account key which then, via
JOSE, endorses a CSR).

I'm inferring from your writing that subject public key endorsement does
not need to have a per-transaction random element (i.e., it can just be
an endorsement statically published in DNS). In this case a logical
thing to do would be to generalize the language so that the endorsement
can be made instead for a key which endorses a subject public key (or
another key which in turn endorses such a key, etc. etc.)

Not sure what you mean by ACME protocol leadership; is the suggestion
that ACME spec out an 'account endorsement' challenge method (let's say
to begin with a variant of dns-01 which uses deterministic values) and
then try and get it approved for production use? In this case, would me
drafting a PR to add deterministic dns-01 to the spec be useful?

(The smallest possible change which would enable this would actually to
be to reuse the dns-01 challenge, and state that a server which supports
deterministic challenges should simply always use a token of
"acme-deterministic-endorsement" or similar. The change to the spec
would be tiny; essentially an optional “serving suggestion” for dns-01,
and clients could look for the special token value if they wanted to
special-case deterministic authorization.)

Hugo Landau