[cabfpub] Question 1 – Domain Validation pre-ballot

[Richard Barnes]

To be clear, I would be OK with tightening my proposed text to only allow a
Random Value (not a Request Token), so that there would explicitly be
something CA-provided in either case.

--Richard

On Fri, Nov 13, 2015 at 6:42 AM, Rick Andrews <Rick_Andrews at symantec.com>
wrote:

> 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" <
> 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
> https://cabforum.org/mailman/listinfo/public
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151117/372d1268/attachment-0001.html