[cabf_validation] Random Value Reuse

[Kirk Hall]

Wayne, I very much like (prefer) an approach that puts the rule in each of the validation methods that uses Random Value (like you have drafted below), which is much better than creating a new definition that’s hidden away on the Definitions page (such as “Nonce”) and then using that for some of the methods instead of Random Value.  Much clearer and simpler.  So I think we support this.

From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Wayne Thayer via Validation
Sent: Thursday, October 19, 2017 1:38 PM
To: validation at cabforum.org
Subject: [EXTERNAL][cabf_validation] Random Value Reuse

On this morning’s call, I volunteered to make a proposal to clarify when reuse of Random Values across validation methods is permitted.

I believe the goals of this change are:

  1.  Forbid the use of a Random Value that is meant to be published somewhere (methods 6 (website), 7 (DNS), or 10 (TLS)) to approve a request under methods 2 (whois contact) or 4 (constructed email).
  2.  Permit the use of the same Random Value across methods 2 and 4, and across methods 6, 7, and 10

Am I missing anything?

I believe it was at the last F2F where someone pointed out that the Random Value in methods 2 and 4 is a secret, while the random value in methods 6, 7, and 10 is a nonce. I started to approach this change by adding definitions for ‘secret random value’ and ‘nonce’. I’m still willing to take that approach, but after some thought I’m not convinced what we’re talking about is strictly a nonce, and I think there’s an easier way to fix this.

My proposal is to add the following sentence to methods 2 and 4:

The Random Value MUST NOT be re-used by any other validation method.

The existing language for method 2 already forbids combining methods 2 and 4:

The CA MAY send the email, fax, SMS, or postal mail identified under this section to more than one recipient provided that every recipient is identified by the Domain Name Registrar as representing the Domain Name Registrant for every FQDN being verified using the email, fax, SMS, or postal mail.
The Random Value SHALL be unique in each email, fax, SMS, or postal mail.

The existing language allows the Random Value from methods 6, 7, or 10 to be reused for different validation methods within the same request.

Does this simple change solve the problem? If so, then I think we can roll it into a ballot containing other 3.2.2.4 fixes.

Thanks,

Wayne



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20171019/610a9ef2/attachment.html>