Right. The definition should be rewritten without the "applicant" included.
-----Original Message----- From: Peter Bowen [mailto:p...@amzn.com] Sent: Wednesday, August 9, 2017 3:49 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: Ben Wilson <ben.wil...@digicert.com>; geo...@apple.com; CA/Browser Forum Public Discussion List <public@cabforum.org>; Gervase Markham <g...@mozilla.org>; Rich Smith <richard.sm...@comodo.com> Subject: Re: [cabfpub] Random value reuse In methods 2 & 4 it goes to the domain contact or a role account at the domain. Giving it to the applicant voids the whole purpose of the exercise, as the applicant isn’t the one who needs to approve the request. Thanks, Peter > On Aug 9, 2017, at 2:46 PM, Jeremy Rowley <jeremy.row...@digicert.com> wrote: > > 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 >>> >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
