Agreed.  And each method should stand on its own without cross-referencing 
among methods (otherwise tracking the particular method used will be too 
complicated).  So I'm OK without cross-referencing methods.

 But are we clear enough?  For example, the currently proposed method 10 could 
probably benefit from better language on how the applicant obtains the random 
value.  Currently it only says, "Confirming the Applicant's control over the 
FQDN by confirming the presence of a Random Value within a Certificate on the 
Authorization Domain Name which is accessible by the CA via TLS over an 
Authorized Port."  The other methods seem to specify the process more 

-----Original Message-----
From: [] 
Sent: Wednesday, August 9, 2017 3:11 PM
To: Ben Wilson <>; CA/Browser Forum Public Discussion 
List <>
Cc: Gervase Markham <>; Jeremy Rowley 
<>; Rich Smith <>; Peter 
Bowen <>
Subject: Re: [cabfpub] Random value reuse

I think that’s where the ‘single communication’ rule really helps.  Then this 
is taken care of by the descriptions of the methods: if you have to send the 
random value to a particular place, then obviously that can’t be combined with 
a random value sent some other way; if you have to put it in a particular 
place, then it doesn’t matter how it was sent…

> On 9 Aug 2017, at 1:54 pm, Ben Wilson via Public <> wrote:
> Putting the  issue of "reuse" aside, do we need to clarify this issue of 
> which random value methods can be used in combination with others?  It seems 
> that a random value could be provided to the domain contact / admin under 
> methods 2, 3 (if you wanted) or 4 and then used within 30 days for methods 2, 
> 4, 6, 7 and 10,  but not vice versa.
> -----Original Message-----
> From: Public [] On Behalf Of Gervase 
> Markham via Public
> Sent: Monday, July 31, 2017 9:02 AM
> To: Jeremy Rowley <>; CA/Browser Forum Public 
> Discussion List <>; Rich Smith <>; 
> 'Peter Bowen' <>
> Subject: Re: [cabfpub] Random value reuse
> On 28/07/17 14:53, Jeremy Rowley via Public wrote:
>> I think the random value should be tied to a single communication 
>> without reuse.  For example, a single email sent to the constructed 
>> emails, a single API call, a single phone call, etc.  The random value 
>> shouldn’t be tied to a method, but should be tied to a specific 
>> communication from the CA that is tied to a request. By getting rid of 
>> the reuse language, we can simplify the process and eliminate the risk 
>> associated with reuse.
> Right. New random values are cheap :-)
> Gerv
> _______________________________________________
> Public mailing list
> _______________________________________________
> Public mailing list

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Public mailing list

Reply via email to