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;
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
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 ;
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
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
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
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
> 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.
>
>
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
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
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
11 matches
Mail list logo