[cabfpub] VWG: Question 1 – Domain Validation pre-ballot

[kirk_hall at trendmicro.com]

I’m going to try to summarize comments posted this week to help with the Validation Working Group call tomorrow morning.  I apologize if I mis-state anyone’s comments.

·        Rick Andrews said the Request Token method is not clear – it probably implies a hash of the public key, but the language for the Request Token method is not clear.  It should be clarified, especially as the BRs are used by CAs and others who are not native English speakers.

·        Richard Barnes “would be OK with tightening [his] proposed text to only allow a Random Value (not a Request Token), so that there would explicitly be something CA-provided in either case.”
So it appears Richard’s remaining proposal is to amend new Method 9 to read as follows:

9. Having the Applicant demonstrate control over the FQDN by the Applicant requesting and then installing a Test Certificate issued by the CA on the FQDN or installing a Test Certificate containing a Random Value which is accessed and then validated via https by the CA over an Authorized Port.

From: Kirk Hall (RD-US)
Sent: Thursday, November 12, 2015 5:08 PM
To: CABFPub (public at cabforum.org)
Subject: Question 1 – Domain Validation pre-ballot

Question 1 – Domain Validation pre-ballot

On the CA-Browser Forum teleconference today, we discussed the five remaining open questions for the pending Domain Validation method pre-ballot (current draft is attached).  I will summarize the open question and discussion in five emails.

We invite further discussion on this list so the Validation Working Group can make progress on its call next Thursday, November 19 – others are welcome to join the call.

Question 1 - Richard Barnes Comments

Richard Barnes of Mozilla suggested we make the following change to new validation method No. 9:


Proposal 1: In line L of draft



CURRENT DRAFT:



"9. Having the Applicant demonstrate control over the FQDN by the Applicant requesting and then installing a Test Certificate issued by the CA on the FQDN which is accessed and then validated via https by the CA over an Authorized Port.”



Richard proposes to add: "*** or installing a Test Certificate containing a Random Value or Request Token" as shown:



9. Having the Applicant demonstrate control over the FQDN by the Applicant requesting and then installing a Test Certificate issued by the CA on the FQDN or installing a Test Certificate containing a Random Value or Request Token which is accessed and then validated via https by the CA over an Authorized Port.



Richard’s reasoning: “This liberalization would cover the DVSNI proposal being considered in ACME, and seems to offer equivalent protection to the other option. (Either way the cert contains something specified by the CA.)“

Richard’s added language does not specifically say who issues the Test Certificate – the CA or the Applicant – but it implies the Applicant generates the Test Certificate.

As a separate question, we discussed whether the Random Value or Request Token must come from the CA – Richard’s language does not specify that.

The defined term Random Value says the value must come from the CA.  The defined term Request Token says only that the Request Token is a “value derived in a method specified by the CA from the public key to be certified” – here is the current definition:

Request Token: A value derived in a method specified by the CA from the public key to be certified. The uniqueness of the Request Token and the irreversibility of the derivation to be at least as strong as those of the cryptographic signature algorithm to be used to sign the certificate.

It is unclear exactly how an Applicant receives a Request Token from a CA – does the CA calculate the value and transmit it to the Applicant to be used in a practical demonstration?  Or does the CA send the Applicant the “method” to be used to calculate the Random Value?  There is general agreement that all “practical demonstration” methods like this one should be unpredictable and not able to be copied or used by a hacker.

Questions:  (1) Should Richard Barnes’ suggested edit be accepted?  (2) Do we need to edit or clarify either Richard’s language or the definition of Request Token?


<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151118/a474eaeb/attachment-0002.html>