Re: [cabfpub] Random value reuse

2017-08-09 Thread Ben Wilson via Public
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 Cc: Ben Wilson ; geo...@apple.com;

Re: [cabfpub] Random value reuse

2017-08-09 Thread Geoff Keating via Public
You can skywrite it above their headquarters, I think, unless the method you’re using specifies otherwise! > On 9 Aug 2017, at 2:45 pm, Jeremy Rowley wrote: > > It raises a lot of questions though. Can I email the Random Value to a > reseller who forwards it on to

Re: [cabfpub] Random value reuse

2017-08-09 Thread Jeremy Rowley via Public
True - unless the CA reads it as the domain contact/role account as being the applicant. -Original Message- From: Peter Bowen [mailto:p...@amzn.com] Sent: Wednesday, August 9, 2017 3:49 PM To: Jeremy Rowley Cc: Ben Wilson ;

Re: [cabfpub] Random value reuse

2017-08-09 Thread Jeremy Rowley via Public
Here's the ways I think random value is either contemplated or being provided: 1) Email to WHOIS/Constructed emails 2) Phone call to applicant 3) Email to applicant 4) Display on website (in the user's account) 5) Through integration tools 6) Through an API 7) Through a partner/reseller 8) By

Re: [cabfpub] Random value reuse

2017-08-09 Thread Peter Bowen via Public
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

Re: [cabfpub] Random value reuse

2017-08-09 Thread Jeremy Rowley via Public
It raises a lot of questions though. Can I email the Random Value to a reseller who forwards it on to the end entity? Can I display it on a website without them logging in? Right now, no security or controls is built on delivery of Random Value. -Original Message- From: Ben Wilson

Re: [cabfpub] Random value reuse

2017-08-09 Thread Peter Bowen via Public
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 wrote: > > I suppose you're right, since the definition of "Random Value" is "A value > specified by a CA to the

Re: [cabfpub] Random value reuse

2017-08-09 Thread Geoff Keating via Public
> On 9 Aug 2017, at 2:24 pm, Ben Wilson 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. > >

Re: [cabfpub] Random value reuse

2017-08-09 Thread Ben Wilson via Public
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

Re: [cabfpub] Random value reuse

2017-08-09 Thread Geoff Keating via Public
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

Re: [cabfpub] Random value reuse

2017-08-09 Thread Ben Wilson via Public
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