ed.
>
>
>
> Regards
>
> Mads
>
>
>
> *From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of *Jeremy
> Rowley via Public
> *Sent:* onsdag 3. januar 2018 23:25
> *To:* geo...@apple.com
> *Cc:* CA/Browser Forum Public Discussion List
> *Subject:*
ards
Mads
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley
via Public
Sent: onsdag 3. januar 2018 23:25
To: geo...@apple.com
Cc: CA/Browser Forum Public Discussion List
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization
Document
The ambiguity is
: Re: [cabfpub] Verification of Domain Contact and Domain Authorization
Document
It looks like we’re going to be removing 3.2.2.4.1, so this will be moot, but
just to explain the interpretation, 3.2.2.4.1 says that what you are doing
(this sentence is the entire description of the method, the
Ryan Sleevi ; Adriano Santoni
>
> Subject: Re: [cabfpub] Verification of Domain Contact and Domain
> Authorization Document
>
>
>
>
> On Dec 22, 2017, at 12:09 PM, Jeremy Rowley via Public <mailto:public@cabforum.org>> wrote:
>
> The attack vector is ea
, January 3, 2018 2:30 PM
To: Ryan Sleevi ; CA/Browser Forum Public Discussion List
; Kirk Hall
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization
Document
I think this is exactly the type of change that the validation working group
should hash out and then propose a
2 AM
To: public@cabforum.org<mailto:public@cabforum.org>
Subject: [EXTERNAL]Re: [cabfpub] Verification of Domain Contact and Domain
Authorization Document
I also concur with Mads, and would support the addition of more requirements to
method 3.2.2.4.1.
I like the solution proposed b
[mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via
Public
Sent: Wednesday, January 3, 2018 1:17 PM
To: Kirk Hall ; CA/Browser Forum Public
Discussion List
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization
Document
Given the impact of this, while I don&#
ns to BR 3.2.2.4.1 as an agenda item?
>
>
>
> *From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of *Adriano
> Santoni via Public
> *Sent:* Wednesday, January 3, 2018 5:12 AM
> *To:* public@cabforum.org
> *Subject:* [EXTERNAL]Re: [cabfpub] Verification of Domain Contact an
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization
Document
Tim H, you are chairing the Validation Working Group now – can the VWG take up
possible revisions to BR 3.2.2.4.1 as an agenda item?
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Adriano
: [EXTERNAL]Re: [cabfpub] Verification of Domain Contact and Domain
Authorization Document
I also concur with Mads, and would support the addition of more requirements to
method 3.2.2.4.1.
I like the solution proposed by Mad, but (if I am not mistaken) there is not a
specific Whois record
owser Forum
Public Discussion List ; geo...@apple.com
*Subject:* Re: [cabfpub] Verification of Domain Contact and Domain
Authorization Document
Then I think we should change the requirements.
As a representative for a CA with a background in strong identity
validation (both for natural and l
Forum Public
Discussion List ; geo...@apple.com
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization
Document
Then I think we should change the requirements.
As a representative for a CA with a background in strong identity validation
(both for natural and
ct: Re: [cabfpub] Verification of Domain Contact and Domain Authorization
Document
I disagree. The requirements do not specify that. All that is required is the
name of the applicant was verified under 3.2.2.1 and that the register specify
the domain contact is the applicant. If Google, Inc. is specif
...@apple.com [mailto:geo...@apple.com]
Sent: Tuesday, January 2, 2018 4:34 PM
To: Jeremy Rowley ; CA/Browser Forum Public
Discussion List
Cc: Ryan Sleevi ; Adriano Santoni
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization
Document
On Dec 22, 2017, at 12
> On Dec 22, 2017, at 12:09 PM, Jeremy Rowley via Public
> wrote:
>
> The attack vector is easier than that.
> I use very stringent processes to verify that Google, Inc. is a legit company
> in Utah.
> I verify that Jeremy did indeed incorporate Google, Inc.
> I call Jeremy at the phone lis
] Verification of Domain Contact and Domain Authorization
Document
Adriano,
Do you have an example of how you believe 3.2.2.4.1 can be used correctly?
Specifically, it does not describe the process for validating that the
Applicant is the Domain Contact with the Registrar - this isn&#
I don't think we could support such a ballot, without having an explanation
of why you believe method #1 is valuable and equivalent - even if tightened
up - to the other methods of validation.
On Fri, Dec 22, 2017 at 2:22 AM, Adriano Santoni via Public <
public@cabforum.org> wrote:
> Ryan,
>
> I
Ryan,
I think I see what you mean, but I also believe that the problem is not
in method #1 per se, but rather in the "degrees of freedom" with which
it may be implemented, as allowed by the BRs.
In particular, I believe that establishing the authenticity of the
request directly with the Appl
Adriano,
Do you have an example of how you believe 3.2.2.4.1 can be used correctly?
Specifically, it does not describe the process for validating that the
Applicant is the Domain Contact with the Registrar - this isn't equivalent
to using WHOIS.
Here's just one scenario:
- I ("Ryan Sleevi") appl
Jeremy, I am not sure I fully understand the problems you describe.
Would it be possible for you to provide some concrete example related to
method #1, with some details, without of course mentioning specific
certificates and/or organizations?
Il 19/12/2017 22:30, Jeremy Rowley via Public h
: [cabfpub] Verification of Domain Contact and Domain Authorization
Document
On Tue, Dec 19, 2017 at 4:30 PM, Jeremy Rowley via Public mailto:public@cabforum.org> > wrote:
I’m looking to remove/fix both of these methods as both these methods lack the
necessary controls to ensure th
On Tue, Dec 19, 2017 at 4:30 PM, Jeremy Rowley via Public <
public@cabforum.org> wrote:
>
> I’m looking to remove/fix both of these methods as both these methods lack
> the necessary controls to ensure that the verification ties to the domain
> holder. These methods probably should have been remove
Hi all,
When reviewing the Symantec validation methods and the customers using each
method, I found an alarming number of customers verified under 3.2.2.4.1
(Verification of a Domain Contact) or 3.2.2.4.5 (Domain Authorization
Document) where the domain is not technically associated with the e
23 matches
Mail list logo
