[cabf_validation] DV Ballot / IETF ACME alignment

[J.C. Jones]

Doug,

Yes. The random value as defined for the HTTP-01 [1] and DNS-01 [2]
challenges is a random value,
generated by the CA, with at least 128 bits of entropy, encoded as
URL-safe Base64.

If a client wants to fulfill the ACME HTTP-01 challenge, the server
might supply back a JSON response:

{
  "type": "http-01",
  "token": "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA",
}

... which would require the client to provision a file at
"/.well-known/acme-challenge/evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA"
containing the appropriate metadata for ACME.

1) https://ietf-wg-acme.github.io/acme/#rfc.section.7.2
2) https://ietf-wg-acme.github.io/acme/#rfc.section.7.5

- J.C.




On Thu, Feb 25, 2016 at 1:22 PM, Doug Beattie
<doug.beattie at globalsign.com> wrote:
> JC, is the random value for "Key Authorization" generated by the CA?
>
>
>> -----Original Message-----
>> From: validation-bounces at cabforum.org [mailto:validation-
>> bounces at cabforum.org] On Behalf Of J.C. Jones
>> Sent: Thursday, February 25, 2016 1:27 PM
>> To: Validation at cabforum.org
>> Subject: [cabf_validation] DV Ballot / IETF ACME alignment
>>
>> All,
>>
>> Thank you for letting me join the WG at this late date, and thank you for
>> making the obvious effort you have in permitting use cases like the proposed
>> ACME protocol [1]. I believe that the proposed language is already quite
>> aligned with the techniques used in ACME. Let me run through a few points:
>>
>> The ACME  "Key Authorization" concept in general appears compliant with
>> the draft BR concept of a "Random Value". Last week I was informed that
>> was intentional; thank you! I'm reaching out to the ACME WG mailing list
>> later today to double-check my understanding.
>>
>> The ACME DNS-01 challenge appears compliant with the draft BR Paragraph
>> 7.b, assuming that the ballot does not change to specify the DNS record
>> name. For reference, currently ACME uses the record "_acme-
>> challenge.<FQDN>".
>>
>> The ACME HTTP-01 challenge is generally compliant with draft BR Paragraph
>> 6.b, except that ACME uses a path "/.well-known/acme-challenge/<Random
>> Value>". The ACME WG intends to register that path with the IANA list of
>> well-known URIs for the purposes of domain validation [2]. I would like to
>> propose that the language for Paragraph 6.b permit either IANA-registered
>> URIs, or ACME's path explicitly. One example is attached, affecting only row
>> H (Paragraph 6).
>>
>> The ACME TLS-SNI-01 challenge is not compliant at this time, and I will work
>> on some draft language for consideration before Friday of next week.
>>
>> Cheers!
>>
>>  - J.C.
>>
>> 1) https://tools.ietf.org/html/draft-ietf-acme-acme
>> 2) https://www.iana.org/assignments/well-known-uris/well-known-
>> uris.xhtml