How do you figure? They can provide it by email to the applicant.  

-----Original Message-----
From: Peter Bowen [mailto:p...@amzn.com] 
Sent: Wednesday, August 9, 2017 3:46 PM
To: Ben Wilson <ben.wil...@digicert.com>
Cc: geo...@apple.com; CA/Browser Forum Public Discussion List 
<public@cabforum.org>; Gervase Markham <g...@mozilla.org>; Jeremy Rowley 
<jeremy.row...@digicert.com>; Rich Smith <richard.sm...@comodo.com>
Subject: Re: [cabfpub] Random value reuse

That definition is problematic.  In methods 2 & 4, the CA doesn’t provide the 
random value to the applicant.

> On Aug 9, 2017, at 2:33 PM, Ben Wilson <ben.wil...@digicert.com> wrote:
> 
> I suppose you're right, since the definition of "Random Value" is "A value 
> specified by a CA to the Applicant that exhibits at least 112 bits of 
> entropy."
> 
> 
> -----Original Message-----
> From: geo...@apple.com [mailto:geo...@apple.com]
> Sent: Wednesday, August 9, 2017 3:30 PM
> To: Ben Wilson <ben.wil...@digicert.com>
> Cc: CA/Browser Forum Public Discussion List <public@cabforum.org>; 
> Gervase Markham <g...@mozilla.org>; Jeremy Rowley 
> <jeremy.row...@digicert.com>; Rich Smith <richard.sm...@comodo.com>; 
> Peter Bowen <p...@amzn.com>
> Subject: Re: [cabfpub] Random value reuse
> 
> 
>> On 9 Aug 2017, at 2:24 pm, Ben Wilson <ben.wil...@digicert.com> wrote:
>> 
>> 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 thoroughly.
> 
> I think it doesn’t matter, in this case, how the Random Value gets to the 
> Applicant—we don’t want to overspecify things like this, because that limits 
> the ability of CAs to innovate.
> 
>> 
>> -----Original Message-----
>> From: geo...@apple.com [mailto:geo...@apple.com]
>> Sent: Wednesday, August 9, 2017 3:11 PM
>> To: Ben Wilson <ben.wil...@digicert.com>; CA/Browser Forum Public 
>> Discussion List <public@cabforum.org>
>> Cc: Gervase Markham <g...@mozilla.org>; Jeremy Rowley 
>> <jeremy.row...@digicert.com>; Rich Smith <richard.sm...@comodo.com>; 
>> Peter Bowen <p...@amzn.com>
>> 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 <public@cabforum.org> 
>>> 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 [mailto:public-boun...@cabforum.org] On Behalf Of 
>>> Gervase Markham via Public
>>> Sent: Monday, July 31, 2017 9:02 AM
>>> To: Jeremy Rowley <jeremy.row...@digicert.com>; CA/Browser Forum 
>>> Public Discussion List <public@cabforum.org>; Rich Smith 
>>> <richard.sm...@comodo.com>; 'Peter Bowen' <p...@amzn.com>
>>> 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@cabforum.org
>>> https://cabforum.org/mailman/listinfo/public
>>> _______________________________________________
>>> Public mailing list
>>> Public@cabforum.org
>>> https://cabforum.org/mailman/listinfo/public
>> 
> 

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

_______________________________________________
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Reply via email to