[cabfpub] Question 1 – Domain Validation pre-ballot

Rick Andrews Rick_Andrews at symantec.com
Fri Nov 13 14:42:34 UTC 2015


It seems clear to me that the Applicant doesn't receive a request token from the CA, but the CA specifies a derivation method, and both Applicant and CA independently use the same method on the same public key to derive the same Request Token.

But the definition of Request Token says the method is irreversible, so it must be a cryptographic hash. Kirk has pointed out several places where the language isn't so clear. A careful reader should be able to understand what needs to be done, but I think we would be better served by making the language more explicit. Remember, many people working with this document are not native English speakers.

-Rick

On Nov 12, 2015, at 8:07 PM, "kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>" <kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>> wrote:

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?


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.




<New Domain Validation Draft 9-10-2015 (for CABF consideration).pdf>
_______________________________________________
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151113/d7cc31a8/attachment-0003.html>


More information about the Public mailing list