[cabf_validation] DV Ballot / IETF ACME alignment

[Robin Alden]

Peter, All,

                Sadly the version of the document I sent through earlier today 
has picked up a weird behaviour (on my computer, at least) that the whole of 
the document is duplicated.  Someone with more MS-Word-fu than I may be able 
to sort it out but I haven't been able to.  The tell is that when you scroll 
to the end you are at around page 18 instead of 9.



I've stepped back to an earlier version and re-made my most recent changes to 
that version.

Peter, please would you incorporate these tracked changes into your master 
version?



The changes are:

D (3)

adding the words "obtaining a response" to clarify that the recipient of the 
telephone call must respond to confirm the applicant's request.

You may remember at the F2F someone brought up the question - 'What if the 
phone is answered but no-one speaks?'



H (7) and J (7)

In both sections, replaced the word 'Either' with 'One of the following 
sub-methods shall be used'.

In both sections, under (b), after the mention of "the maximum time specified 
in section 3.3.1", adding the words

"(noting that other guidelines which rely on these BRs may have their own 
shorter maximum time such as the EV Guidelines section 11.14.3)"



Z (Request Token) becomes:

Request Token: A value derived in a method specified by the CA which binds 
this demonstration of control to the certificate request.

The Request Token SHALL incorporate the key used in the certificate request.

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

A Request Token MAY include other information to ensure its uniqueness.

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 re-use it for a subsequent validation.

The binding SHALL use a digital signature algorithm or a cryptographic hash 
algorithm at least as strong as that to be used in signing the certificate 
request.



And I've added a new paragraph, currently after Z:

[Placeholder for examples/comments on Request Tokens]

Need a discussion whether these examples/comments go inline, as a footnote, or 
in a separate appendix.



Examples of Request Tokens include, but are not limited to:

i)             a hash of the public key.

ii)            a hash of the Subject Public Key Info [X.509]

iii)           a hash of a PKCS#10 CSR

Any of the above Request Tokens may also be concatenated with a timestamp or 
other data.

If a CA wanted to always use a hash of a PKCS#10 CSR as a Request Token and 
did not want to incorporate a timestamp and did want to allow certificate key 
re-use then the applicant might use the challenge password in the creation of 
a CSR with OpenSSL to ensure uniqueness even if the subject and key are 
identical between subsequent requests.

This simplistic shell command produces a Request Token which has a timestamp 
and a hash of a CSR.

echo `date -u +%Y%m%d%H%M` `sha256sum <r2.csr` | sed "s/[ -]//g"

The script outputs:

201602251811c9c863405fe7675a3988b97664ea6baf442019e4e52fa335f406f7c5f26cf14f

The CA should define in its CPS (or in a document referenced from the CPS) the 
format of Request Tokens it accepts.



Regards
Robin





> -----Original Message-----

> From: validation-bounces at cabforum.org [mailto:validation-

> bounces at cabforum.org] On Behalf Of J.C. Jones

> Sent: 25 February 2016 18:27

> 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> 
> https://tools.ietf.org/html/draft-ietf-acme-acme

> 2)  <https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml> 
> https://www.iana.org/assignments/well-known-uris/well-known-

 <https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml> > 
uris.xhtml

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20160225/c3285e46/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Domain Validation Draft (2-25-2016)jra.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 39567 bytes
Desc: not available
Url : https://cabforum.org/pipermail/validation/attachments/20160225/c3285e46/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Domain Validation Draft (2-25-2016)jra.pdf
Type: application/pdf
Size: 573171 bytes
Desc: not available
Url : https://cabforum.org/pipermail/validation/attachments/20160225/c3285e46/attachment-0001.pdf 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5152 bytes
Desc: not available
Url : https://cabforum.org/pipermail/validation/attachments/20160225/c3285e46/attachment-0003.bin