Re: [cabfpub] [EXTERNAL]Re: Ballot 218: Remove validation methods #1 and #5

[Ryan Sleevi via Public]

On Wed, Jan 3, 2018 at 5:27 PM, Bruce Morton <
bruce.mor...@entrustdatacard.com> wrote:

> I disagree.
>
>
>
> Removing, changing and adding back in method #1 is not a productive
> exercise. This method has been used for probably 20 years and yet we never
> see any notifications, articles, alerts, etc. of how this method was
> defeated by an attacker.
>

I think it's exceptionally dangerous to rest on that, particularly since
CAs such as Entrust don't make available to the public their processes and
controls to inspect whether or not they're vulnerable. I am greatly
appreciative to Jeremy sharing the case of customers from a CA they
acquired not being validated to the level that DigiCert holds itself - but
that's hardly to be expected, unless we are to suggest DigiCert should buy
out every other CA.

It was this philosophical opposition that resulted in MD5 being exploited
'in the wild' - CAs ignoring the literature and research and demanding
'proof it applied'

Does Entrust (or the CAs it has acquired) use this method? Can you share
the details that are used to do this?

I stand by the assertion that while it may be possible to restrict what is
done under 3.2.2.4.1 to be 'secure', that is not what it is in the
language, and what is presently executed is demonstrably insecure. If we
are to suggest that we, as an industry, care about security of our users,
then we should make tradeoffs that favor security.


>
>
> Note, I agree that method #1 can be approved in the BRs, but please advise
> which CAs have not already improved this method in practice? If a CA finds
> a BR requirement to be weak, they should either not use it or improve the
> process in their own practices. I assume that many BR requirements were not
> intended to have loopholes, but were written to allow competitiveness in
> the way they are adopted.
>

Fundamentally, I disagree with this framing. System security works by
ensuring the minimum level of security is appropriate - not that every CA
will be smart enough, well-versed in the nuance enough, and/or financially
motivated enough to 'not be creative'.


> I think that the current ballot 218 is bypassing the working group process
> where a working group was created by ballot to improve the validation
> methods. Is this the intension?
>

This is not, nor has it never been, required by our Bylaws. There have been
suggestions from some CAs to try to do this, but this has historically
turned out to be a stalling tactic.

Does Entrust employ 3.2.2.4.1? If so, given that it's required to track the
validation methods it uses, can you share approximately how many or what
percentage of certs you use it for, and how you use it? This can go leaps
and bounds to providing meaningful data about the potential impact to the
ecosystem from disallowing it, without the deliberative delays.


>
>
> If we are going to support abrupt ballots, then I would suggest that they
> at least be split into one topic and discuss method #1 and #5 independently.
>
>
>
> Finally, what is the rush? Why can’t this change be discussed at the
> bi-weekly CAB Forum meeting or Validation Working Group meeting at least
> once before a pre-ballot is produced? And why effective March 1, 2018? Not
> only has method #1 been highly effective for 20 years, but we have also
> just updated the validation methods to support ballot 190. More time would
> allow CAs to add changes to their release cycles and allow Subscribers to
> learn new validation processes they will now have to adopt.
>

Security comes first. That sounds like a considerable stalling tactic, to
be honest. Is this because Entrust specifically uses 3.2.2.4.1, or are you
opposing it on procedural grounds? This, too, will help understand both the
substance of the objections and potential paths to addressing them.


>
>
> I am open to change BR requirements, but do not support ballot 218.
>
>
>
> Bruce.
>
>
>
> *From:* Public [mailto:public-boun...@cabforum.org] * On Behalf Of *Rich
> Smith via Public
> *Sent:* January 3, 2018 4:44 PM
> *To:* 'Ryan Sleevi' ; 'CA/Browser Forum Public
> Discussion List' ; Kirk Hall <
> kirk.h...@entrustdatacard.com>
> *Subject:* [EXTERNAL]Re: [cabfpub] Ballot 218: Remove validation methods
> #1 and #5
>
>
>
> I agree with Ryan on this and stand by my endorsement of this ballot to
> move forward.  I’m not opposed to adding 3.2.2.4.1 back in if it can be
> made much more secure and brought up to equivalent level with the other
> methods, but I also have my doubts as to whether or not that is possible in
> the broad sense across all TLDs and registrars.  That being the case I
> think the best course is to remove it for now because in it’s present form
> is extremely weak and add back later if and when it has undergone
> sufficient revisions to make it secure.
>
>
>
> Regards,
>
> Rich
>
>
>
> *From:* Public [mailto:public-boun...@cabforum.org
> ] *On Behalf Of *Ryan Sleevi via Public
> *Sent:* Wednesday, January 3, 2018 2:24 PM
> *To:* Kirk Hall ;

Re: [cabfpub] [EXTERNAL]Re: Verification of Domain Contact and Domain Authorization Document

[Ryan Sleevi via Public]

Given that CAs have competing interests - namely, to sell certificates
first and foremost, while at the same time not doing anything too egregious
to get noticed and thus distrusted - I don't think it's reasonable,
particularly given the economic incentives and industrial behaviour, to
suggest that CAs would find this as something to reject.

Most CAs, at the end of the day, mint certs for money. CAs particularly
concerned about appearances such as market share are further incentivized
to make minting certs easier. It is thus unsurprising that this sort of
incentive structure results in what we might term 'exploitative' (in a
security mindset), while the CA might call it 'innovative' or 'customer
friendly'.

On Wed, Jan 3, 2018 at 5:41 PM, Bruce Morton via Public  wrote:

> The requirement may mean a LOT of things, but it is also qualified by
> language such as “This method may only be used if: 1. The CA authenticates
> the Applicant's identity under BR Section 3.2.2.1 and the authority of the
> Applicant Representative under BR Section 3.2.5.”
>
>
>
> I assume it will be stated that the language in 3.2.2.1 and 3.2.5 also
> mean a LOT of things, but this is the job of the CA to create a policy
> which is effective. Per BR 5, the CA should also do risk assessments and
> security plans. Using this methodology will help the CA close the loopholes
> in its processes. Of course, if the CA still finds the risk too high, then
> they can stop using the method.
>
>
>
> Bruce.
>
>
>
> *From:* Public [mailto:public-boun...@cabforum.org] * On Behalf Of *Jeremy
> Rowley via Public
> *Sent:* January 3, 2018 5:25 PM
> *To:* geo...@apple.com
> *Cc:* CA/Browser Forum Public Discussion List 
> *Subject:* [EXTERNAL]Re: [cabfpub] Verification of Domain Contact and
> Domain Authorization Document
>
>
>
> The ambiguity is exactly why we need to remove method 1. I’ve seen all of
> the following:
>
> 1)  Approval based on a name match
>
> 2)  Approval based on an email match (same email as requester or the
> email is a corporate email) – note that this is a Domain Contact match
>
> 3)  Approval based on address and name match
>
> 4)  Approval based on a letter from the registrar
>
> 5)  Approval based on a call to the registrar
>
> 6)  Approval based on a validation email to the registrar
>
>
>
> All of these are equally permitted by the language, IMO, because “by
> validating the Applicant has the same name as the Domain Contact
> directly with the Domain Name Registrar” can mean a LOT of things.
>
>
>
> *From:* geo...@apple.com [mailto:geo...@apple.com ]
> *Sent:* Wednesday, January 3, 2018 2:54 PM
> *To:* Jeremy Rowley 
> *Cc:* CA/Browser Forum Public Discussion List ; Ryan
> Sleevi ; Adriano Santoni  it>
> *Subject:* 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 rest of
> the section just limits its application) is "Confirming the Applicant's
> control over the FQDN by validating the Applicant is the Domain Contact
> directly with the Domain Name Registrar.”
>
>
>
> This is not a name match.  If the BRs wanted to say “by validating the
> Applicant has the same name as the Domain Contact”, they would say so.
> This is a one-and-the-same match, it uses the word “is”.  In the example
> below, the CA must ensure that “Google Inc., the Utah corporation” is the
> same one as shown in the WHOIS information, and all the WHOIS information
> is relevant in confirming this.
>
>
>
> Another important clarification is that if you use 3.2.2.1, it doesn’t
> just verify “the name of the applicant”; it says that "the CA SHALL
> verify the identity and address of the organization”, not just the name.
>  (Um… actually, if you read it closely, you might not verify the name at
> all, if you identify the organization in another way, maybe with some kind
> of ID number.  That’s probably a bug.)
>
>
>
> On 2 Jan 2018, at 8:47 pm, Jeremy Rowley 
> wrote:
>
>
>
> 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 specified
> as the domain contact, no address matching is required.
>
>
>
> *From:* geo...@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 <
> adriano.sant...@staff.aruba.it>
> *Subject:* Re: [cabfpub] Verification of Domain Contact and Domain
> Authorization Document
>
>
>
>
>
>
>
> On Dec 22, 2017, at 12:09 PM, Jeremy Rowley via Public <
> public@cabforum.org> wrote:
>
>
>
> The attack vector is easier than that.
>
>1. I use very stringent processes to verify 

Re: [cabfpub] [EXTERNAL]Re: Ballot 218: Remove validation methods #1 and #5

[Tim Hollebeek via Public]

Jeremy’s proposal was discussed in the Validation working group.  You were 
there, and spoke up to oppose it.

 

I’m also fine with discussing it again, which we will do tomorrow.  But there 
is no requirement that ballots go through working groups.

 

If people oppose the ballot, that’s fine, but they should do so on the merits.

 

-Tim

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Bruce Morton via 
Public
Sent: Wednesday, January 3, 2018 3:27 PM
To: Rich Smith ; CA/Browser Forum Public Discussion 
List ; 'Ryan Sleevi' ; Kirk Hall 

Subject: Re: [cabfpub] [EXTERNAL]Re: Ballot 218: Remove validation methods #1 
and #5

 

I disagree.

 

Removing, changing and adding back in method #1 is not a productive exercise. 
This method has been used for probably 20 years and yet we never see any 
notifications, articles, alerts, etc. of how this method was defeated by an 
attacker.

 

Note, I agree that method #1 can be approved in the BRs, but please advise 
which CAs have not already improved this method in practice? If a CA finds a BR 
requirement to be weak, they should either not use it or improve the process in 
their own practices. I assume that many BR requirements were not intended to 
have loopholes, but were written to allow competitiveness in the way they are 
adopted. 

 

I think that the current ballot 218 is bypassing the working group process 
where a working group was created by ballot to improve the validation methods. 
Is this the intension?

 

If we are going to support abrupt ballots, then I would suggest that they at 
least be split into one topic and discuss method #1 and #5 independently.

 

Finally, what is the rush? Why can’t this change be discussed at the bi-weekly 
CAB Forum meeting or Validation Working Group meeting at least once before a 
pre-ballot is produced? And why effective March 1, 2018? Not only has method #1 
been highly effective for 20 years, but we have also just updated the 
validation methods to support ballot 190. More time would allow CAs to add 
changes to their release cycles and allow Subscribers to learn new validation 
processes they will now have to adopt.

 

I am open to change BR requirements, but do not support ballot 218.

 

Bruce.   

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Rich Smith via 
Public
Sent: January 3, 2018 4:44 PM
To: 'Ryan Sleevi' mailto:sle...@google.com> >; 'CA/Browser 
Forum Public Discussion List' mailto:public@cabforum.org> 
>; Kirk Hall mailto:kirk.h...@entrustdatacard.com> >
Subject: [EXTERNAL]Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5

 

I agree with Ryan on this and stand by my endorsement of this ballot to move 
forward.  I’m not opposed to adding 3.2.2.4.1 back in if it can be made much 
more secure and brought up to equivalent level with the other methods, but I 
also have my doubts as to whether or not that is possible in the broad sense 
across all TLDs and registrars.  That being the case I think the best course is 
to remove it for now because in it’s present form is extremely weak and add 
back later if and when it has undergone sufficient revisions to make it secure.

 

Regards,

Rich

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Wednesday, January 3, 2018 2:24 PM
To: Kirk Hall mailto:kirk.h...@entrustdatacard.com> >; CA/Browser Forum Public Discussion 
List mailto:public@cabforum.org> >
Subject: Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5

 

Hi Kirk,

 

We had two endorsers for the discussion. As I mentioned, there's nothing 
inherent in needing to direct this to VWG. As DigiCert has pointed out, there 
are CAs today that are doing validations that are patently insecure.

 

While we can understand and appreciate that some members may wish to introduce 
new validation methods that are limited in scope and applicability (for 
example, Mads' example only applies to a limited subset of ccTLDs, and cannot 
be done safely generically), in order to reduce that risk, I think it's 
entirely appropriate to take the necessary steps to ensure the safety of the 
Internet at large.

 

This does not prevent or inhibit the issuance of certificates that have 
appropriate controls - that is, these methods could be argued as an 
'optimization' - and thus we should not unduly delay progress. Regarding 
passing it to the VWG, could you indicate where you saw that was suggested? The 
only mention of it I saw was from you, on a separate thread, and I'm curious if 
perhaps I've missed additional discussion. Certainly, our workmode does not 
require sending such discussions "to committee"

 

On Wed, Jan 3, 2018 at 3:10 PM, Kirk Hall via Public mailto:public@cabforum.org> > wrote:

Tim, I thought this issue was going to be discussed first by the VWG, as 
several CAs have indicated they would like to keep (but improve) Method 1.  

 

From: Public [mailto:public-boun...@cabforum.org 

Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5

[Tim Hollebeek via Public]

I agree with Rich and Ryan.

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Rich Smith via 
Public
Sent: Wednesday, January 3, 2018 2:44 PM
To: 'Ryan Sleevi' ; 'CA/Browser Forum Public Discussion 
List' ; 'Kirk Hall' 
Subject: Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5

 

I agree with Ryan on this and stand by my endorsement of this ballot to move 
forward.  I’m not opposed to adding 3.2.2.4.1 back in if it can be made much 
more secure and brought up to equivalent level with the other methods, but I 
also have my doubts as to whether or not that is possible in the broad sense 
across all TLDs and registrars.  That being the case I think the best course is 
to remove it for now because in it’s present form is extremely weak and add 
back later if and when it has undergone sufficient revisions to make it secure.

 

Regards,

Rich

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Wednesday, January 3, 2018 2:24 PM
To: Kirk Hall mailto:kirk.h...@entrustdatacard.com> >; CA/Browser Forum Public Discussion 
List mailto:public@cabforum.org> >
Subject: Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5

 

Hi Kirk,

 

We had two endorsers for the discussion. As I mentioned, there's nothing 
inherent in needing to direct this to VWG. As DigiCert has pointed out, there 
are CAs today that are doing validations that are patently insecure.

 

While we can understand and appreciate that some members may wish to introduce 
new validation methods that are limited in scope and applicability (for 
example, Mads' example only applies to a limited subset of ccTLDs, and cannot 
be done safely generically), in order to reduce that risk, I think it's 
entirely appropriate to take the necessary steps to ensure the safety of the 
Internet at large.

 

This does not prevent or inhibit the issuance of certificates that have 
appropriate controls - that is, these methods could be argued as an 
'optimization' - and thus we should not unduly delay progress. Regarding 
passing it to the VWG, could you indicate where you saw that was suggested? The 
only mention of it I saw was from you, on a separate thread, and I'm curious if 
perhaps I've missed additional discussion. Certainly, our workmode does not 
require sending such discussions "to committee"

 

On Wed, Jan 3, 2018 at 3:10 PM, Kirk Hall via Public mailto:public@cabforum.org> > wrote:

Tim, I thought this issue was going to be discussed first by the VWG, as 
several CAs have indicated they would like to keep (but improve) Method 1.  

 

From: Public [mailto:public-boun...@cabforum.org 
 ] On Behalf Of Tim Hollebeek via Public
Sent: Wednesday, January 3, 2018 11:22 AM
To: CA/Browser Forum Public Discussion List mailto:public@cabforum.org> >
Subject: [EXTERNAL][cabfpub] Ballot 218: Remove validation methods #1 and #5

 

 

Ballot 218: Remove validation methods #1 and #5

 

Purpose of Ballot: Section 3.2.2.4 says that it “defines the permitted 
processes and procedures for validating the Applicant’s ownership or control of 
the domain.”  Most of the validation methods actually do validate ownership and 
control, but two do not, and can be completed solely based on an applicant’s 
own assertions.

 

Since these two validation methods do not meet the objectives of section 
3.2.2.4, and are actively being used to avoid validating domain control or 
ownership, they should be removed, and the other methods that do validate 
domain control or ownership should be used.

 

The following motion has been proposed by Tim Hollebeek of DigiCert and 
endorsed by Ryan Sleevi of Google and Rich Smith of Comodo.

 

-- MOTION BEGINS –

 

This ballot modifies the “Baseline Requirements for the Issuance and Management 
of Publicly-Trusted Certificates” as follows, based upon Version 1.5.4:

 

In Section 3.2.2.4.1, add text at the end: “For certificates issued on or after 
March 1, 2018, this method SHALL NOT be used for validation, and completed 
validations using this method SHALL NOT be used for the issuance of 
certificates.”

 

In Section 3.2.2.4.5, add text at the end: “For certificates issued on or after 
March 1, 2018, this method SHALL NOT be used for validation, and completed 
validations using this method SHALL NOT be used for the issuance of 
certificates.”

 

In Section 4.2.1, after the paragraph that begins “After the change to any 
validation method”, add the following paragraph: “Validations completed using 
methods specified in Section 3.2.2.4.1 or Section 3.2.2.4.5 SHALL NOT be 
re-used on or after March 1, 2018.”

 

-- MOTION ENDS –

 

For the purposes of section 4.2.1, the new text added to 4.2.1 from this ballot 
is “specifically provided in a [this] ballot.”

 

The procedure for approval of this ballot is as follows:

 

Discussion (7+ days) 

  Start Time: 2017-01-03  19:30:00 UTC  

  End Time: Not Before 2017-01-10 19:30:00 UTC

Re: [cabfpub] [EXTERNAL]Re: Verification of Domain Contact and Domain Authorization Document

[Bruce Morton via Public]

The requirement may mean a LOT of things, but it is also qualified by language 
such as “This method may only be used if: 1. The CA authenticates the 
Applicant's identity under BR Section 3.2.2.1 and the authority of the 
Applicant Representative under BR Section 3.2.5.”

I assume it will be stated that the language in 3.2.2.1 and 3.2.5 also mean a 
LOT of things, but this is the job of the CA to create a policy which is 
effective. Per BR 5, the CA should also do risk assessments and security plans. 
Using this methodology will help the CA close the loopholes in its processes. 
Of course, if the CA still finds the risk too high, then they can stop using 
the method.

Bruce.

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: January 3, 2018 5:25 PM
To: geo...@apple.com
Cc: CA/Browser Forum Public Discussion List 
Subject: [EXTERNAL]Re: [cabfpub] Verification of Domain Contact and Domain 
Authorization Document

The ambiguity is exactly why we need to remove method 1. I’ve seen all of the 
following:
1)  Approval based on a name match
2)  Approval based on an email match (same email as requester or the email 
is a corporate email) – note that this is a Domain Contact match
3)  Approval based on address and name match
4)  Approval based on a letter from the registrar
5)  Approval based on a call to the registrar
6)  Approval based on a validation email to the registrar

All of these are equally permitted by the language, IMO, because “by validating 
the Applicant has the same name as the Domain Contact directly with the Domain 
Name Registrar” can mean a LOT of things.

From: geo...@apple.com [mailto:geo...@apple.com]
Sent: Wednesday, January 3, 2018 2:54 PM
To: Jeremy Rowley 
mailto:jeremy.row...@digicert.com>>
Cc: CA/Browser Forum Public Discussion List 
mailto:public@cabforum.org>>; Ryan Sleevi 
mailto:sle...@google.com>>; Adriano Santoni 
mailto:adriano.sant...@staff.aruba.it>>
Subject: 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 rest of the section 
just limits its application) is "Confirming the Applicant's control over the 
FQDN by validating the Applicant is the Domain Contact directly with the Domain 
Name Registrar.”

This is not a name match.  If the BRs wanted to say “by validating the 
Applicant has the same name as the Domain Contact”, they would say so.  This is 
a one-and-the-same match, it uses the word “is”.  In the example below, the CA 
must ensure that “Google Inc., the Utah corporation” is the same one as shown 
in the WHOIS information, and all the WHOIS information is relevant in 
confirming this.

Another important clarification is that if you use 3.2.2.1, it doesn’t just 
verify “the name of the applicant”; it says that "the CA SHALL verify the 
identity and address of the organization”, not just the name.  (Um… actually, 
if you read it closely, you might not verify the name at all, if you identify 
the organization in another way, maybe with some kind of ID number.  That’s 
probably a bug.)

On 2 Jan 2018, at 8:47 pm, Jeremy Rowley 
mailto:jeremy.row...@digicert.com>> wrote:

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 specified as the domain 
contact, no address matching is required.

From: geo...@apple.com [mailto:geo...@apple.com]
Sent: Tuesday, January 2, 2018 4:34 PM
To: Jeremy Rowley 
mailto:jeremy.row...@digicert.com>>; CA/Browser 
Forum Public Discussion List mailto:public@cabforum.org>>
Cc: Ryan Sleevi mailto:sle...@google.com>>; Adriano Santoni 
mailto:adriano.sant...@staff.aruba.it>>
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 easier than that.

  1.  I use very stringent processes to verify that Google, Inc. is a legit 
company in Utah.
  2.  I verify that Jeremy did indeed incorporate Google, Inc.
  3.  I call Jeremy at the phone listed for Google, Inc., the Utah corporation
  4.  The domain information shows Google, Inc. as owning 
google.com
  5.  Certificate issues.

Obviously this would be caught in every CA’s high risk checks, but the point 
remains valid. Regardless of the expertise and thoroughness of the org check, 
the specs lack any time between the verified org and the actual domain because 
orgs are not unique on a global basis.


For item 4, you have to verify that “the Applicant is the Domain Contact”.  
Obviously it’s insufficient to just c

Re: [cabfpub] [EXTERNAL]Re: Ballot 218: Remove validation methods #1 and #5

[Bruce Morton via Public]

I disagree.

Removing, changing and adding back in method #1 is not a productive exercise. 
This method has been used for probably 20 years and yet we never see any 
notifications, articles, alerts, etc. of how this method was defeated by an 
attacker.

Note, I agree that method #1 can be approved in the BRs, but please advise 
which CAs have not already improved this method in practice? If a CA finds a BR 
requirement to be weak, they should either not use it or improve the process in 
their own practices. I assume that many BR requirements were not intended to 
have loopholes, but were written to allow competitiveness in the way they are 
adopted.

I think that the current ballot 218 is bypassing the working group process 
where a working group was created by ballot to improve the validation methods. 
Is this the intension?

If we are going to support abrupt ballots, then I would suggest that they at 
least be split into one topic and discuss method #1 and #5 independently.

Finally, what is the rush? Why can’t this change be discussed at the bi-weekly 
CAB Forum meeting or Validation Working Group meeting at least once before a 
pre-ballot is produced? And why effective March 1, 2018? Not only has method #1 
been highly effective for 20 years, but we have also just updated the 
validation methods to support ballot 190. More time would allow CAs to add 
changes to their release cycles and allow Subscribers to learn new validation 
processes they will now have to adopt.

I am open to change BR requirements, but do not support ballot 218.

Bruce.

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Rich Smith via 
Public
Sent: January 3, 2018 4:44 PM
To: 'Ryan Sleevi' ; 'CA/Browser Forum Public Discussion 
List' ; Kirk Hall 
Subject: [EXTERNAL]Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5

I agree with Ryan on this and stand by my endorsement of this ballot to move 
forward.  I’m not opposed to adding 3.2.2.4.1 back in if it can be made much 
more secure and brought up to equivalent level with the other methods, but I 
also have my doubts as to whether or not that is possible in the broad sense 
across all TLDs and registrars.  That being the case I think the best course is 
to remove it for now because in it’s present form is extremely weak and add 
back later if and when it has undergone sufficient revisions to make it secure.

Regards,
Rich

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Wednesday, January 3, 2018 2:24 PM
To: Kirk Hall 
mailto:kirk.h...@entrustdatacard.com>>; 
CA/Browser Forum Public Discussion List 
mailto:public@cabforum.org>>
Subject: Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5

Hi Kirk,

We had two endorsers for the discussion. As I mentioned, there's nothing 
inherent in needing to direct this to VWG. As DigiCert has pointed out, there 
are CAs today that are doing validations that are patently insecure.

While we can understand and appreciate that some members may wish to introduce 
new validation methods that are limited in scope and applicability (for 
example, Mads' example only applies to a limited subset of ccTLDs, and cannot 
be done safely generically), in order to reduce that risk, I think it's 
entirely appropriate to take the necessary steps to ensure the safety of the 
Internet at large.

This does not prevent or inhibit the issuance of certificates that have 
appropriate controls - that is, these methods could be argued as an 
'optimization' - and thus we should not unduly delay progress. Regarding 
passing it to the VWG, could you indicate where you saw that was suggested? The 
only mention of it I saw was from you, on a separate thread, and I'm curious if 
perhaps I've missed additional discussion. Certainly, our workmode does not 
require sending such discussions "to committee"

On Wed, Jan 3, 2018 at 3:10 PM, Kirk Hall via Public 
mailto:public@cabforum.org>> wrote:
Tim, I thought this issue was going to be discussed first by the VWG, as 
several CAs have indicated they would like to keep (but improve) Method 1.

From: Public 
[mailto:public-boun...@cabforum.org] On 
Behalf Of Tim Hollebeek via Public
Sent: Wednesday, January 3, 2018 11:22 AM
To: CA/Browser Forum Public Discussion List 
mailto:public@cabforum.org>>
Subject: [EXTERNAL][cabfpub] Ballot 218: Remove validation methods #1 and #5


Ballot 218: Remove validation methods #1 and #5

Purpose of Ballot: Section 3.2.2.4 says that it “defines the permitted 
processes and procedures for validating the Applicant’s ownership or control of 
the domain.”  Most of the validation methods actually do validate ownership and 
control, but two do not, and can be completed solely based on an applicant’s 
own assertions.

Since these two validation methods do not meet the objectives of section 
3.2.2.4, and are actively being used to avoid validating domain control or 
ownership, they should be remo

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Jeremy Rowley via Public]

The ambiguity is exactly why we need to remove method 1. I’ve seen all of the 
following:

1.  Approval based on a name match
2.  Approval based on an email match (same email as requester or the email 
is a corporate email) – note that this is a Domain Contact match
3.  Approval based on address and name match
4.  Approval based on a letter from the registrar
5.  Approval based on a call to the registrar
6.  Approval based on a validation email to the registrar

 

All of these are equally permitted by the language, IMO, because “by validating 
the Applicant has the same name as the Domain Contact directly with the Domain 
Name Registrar” can mean a LOT of things.

 

From: geo...@apple.com [mailto:geo...@apple.com] 
Sent: Wednesday, January 3, 2018 2:54 PM
To: Jeremy Rowley 
Cc: CA/Browser Forum Public Discussion List ; Ryan Sleevi 
; Adriano Santoni 
Subject: 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 rest of the section 
just limits its application) is "Confirming the Applicant's control over the 
FQDN by validating the Applicant is the Domain Contact directly with the Domain 
Name Registrar.”

 

This is not a name match.  If the BRs wanted to say “by validating the 
Applicant has the same name as the Domain Contact”, they would say so.  This is 
a one-and-the-same match, it uses the word “is”.  In the example below, the CA 
must ensure that “Google Inc., the Utah corporation” is the same one as shown 
in the WHOIS information, and all the WHOIS information is relevant in 
confirming this.

 

Another important clarification is that if you use 3.2.2.1, it doesn’t just 
verify “the name of the applicant”; it says that "the CA SHALL verify the 
identity and address of the organization”, not just the name.  (Um… actually, 
if you read it closely, you might not verify the name at all, if you identify 
the organization in another way, maybe with some kind of ID number.  That’s 
probably a bug.)

 

On 2 Jan 2018, at 8:47 pm, Jeremy Rowley mailto:jeremy.row...@digicert.com> > wrote:

 

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 specified as the domain 
contact, no address matching is required.

 

From: geo...@apple.com   [mailto:geo...@apple.com] 
Sent: Tuesday, January 2, 2018 4:34 PM
To: Jeremy Rowley mailto:jeremy.row...@digicert.com> >; CA/Browser Forum Public Discussion List 
mailto:public@cabforum.org> >
Cc: Ryan Sleevi mailto:sle...@google.com> >; Adriano 
Santoni mailto:adriano.sant...@staff.aruba.it> 
>
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

 

 






On Dec 22, 2017, at 12:09 PM, Jeremy Rowley via Public < 
 public@cabforum.org> wrote:

 

The attack vector is easier than that. 

1.  I use very stringent processes to verify that Google, Inc. is a legit 
company in Utah.
2.  I verify that Jeremy did indeed incorporate Google, Inc. 
3.  I call Jeremy at the phone listed for Google, Inc., the Utah corporation
4.  The domain information shows Google, Inc. as owning  
 google.com
5.  Certificate issues.

 

Obviously this would be caught in every CA’s high risk checks, but the point 
remains valid. Regardless of the expertise and thoroughness of the org check, 
the specs lack any time between the verified org and the actual domain because 
orgs are not unique on a global basis.

 

 

For item 4, you have to verify that “the Applicant is the Domain Contact”.  
Obviously it’s insufficient to just compare names—you must verify every element 
of the WHOIS contact matches the Applicant, that’s typically name, postal 
address, phone number, and e-mail.

 



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Geoff Keating via Public]

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 rest of the section 
just limits its application) is "Confirming the Applicant's control over the 
FQDN by validating the Applicant is the Domain Contact directly with the Domain 
Name Registrar.”

This is not a name match.  If the BRs wanted to say “by validating the 
Applicant has the same name as the Domain Contact”, they would say so.  This is 
a one-and-the-same match, it uses the word “is”.  In the example below, the CA 
must ensure that “Google Inc., the Utah corporation” is the same one as shown 
in the WHOIS information, and all the WHOIS information is relevant in 
confirming this.

Another important clarification is that if you use 3.2.2.1, it doesn’t just 
verify “the name of the applicant”; it says that "the CA SHALL verify the 
identity and address of the organization”, not just the name.  (Um… actually, 
if you read it closely, you might not verify the name at all, if you identify 
the organization in another way, maybe with some kind of ID number.  That’s 
probably a bug.)

> On 2 Jan 2018, at 8:47 pm, Jeremy Rowley  wrote:
> 
> 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 specified as 
> the domain contact, no address matching is required.
>   <>
> From: geo...@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: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 listed for Google, Inc., the Utah corporation
> The domain information shows Google, Inc. as owning google.com 
> 
> Certificate issues.
>  
> Obviously this would be caught in every CA’s high risk checks, but the point 
> remains valid. Regardless of the expertise and thoroughness of the org check, 
> the specs lack any time between the verified org and the actual domain 
> because orgs are not unique on a global basis.
>  
>  
> For item 4, you have to verify that “the Applicant is the Domain Contact”.  
> Obviously it’s insufficient to just compare names—you must verify every 
> element of the WHOIS contact matches the Applicant, that’s typically name, 
> postal address, phone number, and e-mail.



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Rich Smith via Public]

Notwithstanding potential discussions to revamp this method, I stand by removal 
at this time as it is currently dreadfully insecure and nowhere near equivalent 
to the other methods.

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Doug Beattie via 
Public
Sent: Wednesday, 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 solution to the public list.  I’m actually 
surprised that Tim sent this out given this was on our agenda for tomorrow and 
he informally polled a number of us on the use of method 1.

 

I believe that with some additional checks, we can make method 1 sufficiently 
secure.

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Wednesday, January 3, 2018 3:17 PM
To: Kirk Hall mailto:kirk.h...@entrustdatacard.com> >; CA/Browser Forum Public Discussion 
List mailto:public@cabforum.org> >
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

 

Given the impact of this, while I don't suggest that the VWG shouldn't take 
this up, I also don't think that should be reason not to continue the 
discussion on the public list.

 

While I understand that Mads and Adriano have suggested they see value in 
3.2.2.4.1, I do not think there's a sufficiently compelling demonstration that 
it remotely approaches the level of assurance of the other methods, or that it 
fundamentally can. Given that, I do not think 3.2.2.4.1 should be considered - 
even in modified form - to be equivalent.

 

In considering how one might theorhetically reform 3.2.2.4.1, I would suggest 
it's incumbent upon those supporting it to demonstrate how it could achieve 
that level of assurance. Barring that, we are much better as an industry and a 
Forum from removing 3.2.2.4.1 unless and until such time as an appropriate 
demonstration can be made. This avoids introducing significant security risk to 
the ecosystem due to the Forum's (rather slow) deliberative process.

 

On Wed, Jan 3, 2018 at 11:08 AM, Kirk Hall via Public mailto:public@cabforum.org> > wrote:

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 Santoni via Public
Sent: Wednesday, January 3, 2018 5:12 AM
To: 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 by Mad, but (if I am not mistaken) there is not a 
specific Whois record field for that information (org number), and I would 
avoid inserting that information in a field that's not expressly designed for 
it.

Other solutions may also work, and would be easier to implement, like e.g. 
mandating a full Registrant address, in the Whois record, which must be one of 
the official addresses of the Registrant as found in a QIIS/QGIS (excluding, 
however, all information sources that just publish self-reported organization 
information, which cannot be regarded as "qualified" information sources and 
IMO should not be used in the vetting process), and then the "reliable method 
of communication" should be one that is found in the matching QIIS/QGIS record.

Not sure about method 3.2.2.4.5, at this time, as I have not yet seen a 
sufficient discussion on it, and I am not sure how it can effectively be used 
"as is" to obtain a fraudulent certificate.

Adriano

Il 03/01/2018 13:27, Doug Beattie via Public ha scritto:

I agree with Mads and am also supportive of a ballot that removes 3.2.2.4.5 and 
adds some more detail to 3.2.2.4.1.

 

Doug

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Mads Egil 
Henriksveen via Public
Sent: Wednesday, January 3, 2018 7:11 AM
To: Jeremy Rowley   
; CA/Browser 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 legal persons) I find these examples from Ryan and Jeremy 
to represent a very bad practice. If this really reflects the current practice 
in the industry, we need to tighten up the requirements and make them much more 
specific.

 

>From my point of view (and with my background) I find method 3.2.2.4.1 useful. 
>We must remember that the domain validation met

Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5

[Rich Smith via Public]

I agree with Ryan on this and stand by my endorsement of this ballot to move 
forward.  I’m not opposed to adding 3.2.2.4.1 back in if it can be made much 
more secure and brought up to equivalent level with the other methods, but I 
also have my doubts as to whether or not that is possible in the broad sense 
across all TLDs and registrars.  That being the case I think the best course is 
to remove it for now because in it’s present form is extremely weak and add 
back later if and when it has undergone sufficient revisions to make it secure.

 

Regards,

Rich

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Wednesday, January 3, 2018 2:24 PM
To: Kirk Hall ; CA/Browser Forum Public 
Discussion List 
Subject: Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5

 

Hi Kirk,

 

We had two endorsers for the discussion. As I mentioned, there's nothing 
inherent in needing to direct this to VWG. As DigiCert has pointed out, there 
are CAs today that are doing validations that are patently insecure.

 

While we can understand and appreciate that some members may wish to introduce 
new validation methods that are limited in scope and applicability (for 
example, Mads' example only applies to a limited subset of ccTLDs, and cannot 
be done safely generically), in order to reduce that risk, I think it's 
entirely appropriate to take the necessary steps to ensure the safety of the 
Internet at large.

 

This does not prevent or inhibit the issuance of certificates that have 
appropriate controls - that is, these methods could be argued as an 
'optimization' - and thus we should not unduly delay progress. Regarding 
passing it to the VWG, could you indicate where you saw that was suggested? The 
only mention of it I saw was from you, on a separate thread, and I'm curious if 
perhaps I've missed additional discussion. Certainly, our workmode does not 
require sending such discussions "to committee"

 

On Wed, Jan 3, 2018 at 3:10 PM, Kirk Hall via Public mailto:public@cabforum.org> > wrote:

Tim, I thought this issue was going to be discussed first by the VWG, as 
several CAs have indicated they would like to keep (but improve) Method 1.  

 

From: Public [mailto:public-boun...@cabforum.org 
 ] On Behalf Of Tim Hollebeek via Public
Sent: Wednesday, January 3, 2018 11:22 AM
To: CA/Browser Forum Public Discussion List mailto:public@cabforum.org> >
Subject: [EXTERNAL][cabfpub] Ballot 218: Remove validation methods #1 and #5

 

 

Ballot 218: Remove validation methods #1 and #5

 

Purpose of Ballot: Section 3.2.2.4 says that it “defines the permitted 
processes and procedures for validating the Applicant’s ownership or control of 
the domain.”  Most of the validation methods actually do validate ownership and 
control, but two do not, and can be completed solely based on an applicant’s 
own assertions.

 

Since these two validation methods do not meet the objectives of section 
3.2.2.4, and are actively being used to avoid validating domain control or 
ownership, they should be removed, and the other methods that do validate 
domain control or ownership should be used.

 

The following motion has been proposed by Tim Hollebeek of DigiCert and 
endorsed by Ryan Sleevi of Google and Rich Smith of Comodo.

 

-- MOTION BEGINS –

 

This ballot modifies the “Baseline Requirements for the Issuance and Management 
of Publicly-Trusted Certificates” as follows, based upon Version 1.5.4:

 

In Section 3.2.2.4.1, add text at the end: “For certificates issued on or after 
March 1, 2018, this method SHALL NOT be used for validation, and completed 
validations using this method SHALL NOT be used for the issuance of 
certificates.”

 

In Section 3.2.2.4.5, add text at the end: “For certificates issued on or after 
March 1, 2018, this method SHALL NOT be used for validation, and completed 
validations using this method SHALL NOT be used for the issuance of 
certificates.”

 

In Section 4.2.1, after the paragraph that begins “After the change to any 
validation method”, add the following paragraph: “Validations completed using 
methods specified in Section 3.2.2.4.1 or Section 3.2.2.4.5 SHALL NOT be 
re-used on or after March 1, 2018.”

 

-- MOTION ENDS –

 

For the purposes of section 4.2.1, the new text added to 4.2.1 from this ballot 
is “specifically provided in a [this] ballot.”

 

The procedure for approval of this ballot is as follows:

 

Discussion (7+ days) 

  Start Time: 2017-01-03  19:30:00 UTC  

  End Time: Not Before 2017-01-10 19:30:00 UTC

 

Vote for approval (7 days) 

  Start Time: TBD   

  End Time: TBD

 


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

 

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

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Doug Beattie via Public]

I think this is exactly the type of change that the validation working group 
should hash out and then propose a solution to the public list.  I’m actually 
surprised that Tim sent this out given this was on our agenda for tomorrow and 
he informally polled a number of us on the use of method 1.

I believe that with some additional checks, we can make method 1 sufficiently 
secure.

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Wednesday, January 3, 2018 3: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't suggest that the VWG shouldn't take 
this up, I also don't think that should be reason not to continue the 
discussion on the public list.

While I understand that Mads and Adriano have suggested they see value in 
3.2.2.4.1, I do not think there's a sufficiently compelling demonstration that 
it remotely approaches the level of assurance of the other methods, or that it 
fundamentally can. Given that, I do not think 3.2.2.4.1 should be considered - 
even in modified form - to be equivalent.

In considering how one might theorhetically reform 3.2.2.4.1, I would suggest 
it's incumbent upon those supporting it to demonstrate how it could achieve 
that level of assurance. Barring that, we are much better as an industry and a 
Forum from removing 3.2.2.4.1 unless and until such time as an appropriate 
demonstration can be made. This avoids introducing significant security risk to 
the ecosystem due to the Forum's (rather slow) deliberative process.

On Wed, Jan 3, 2018 at 11:08 AM, Kirk Hall via Public 
mailto:public@cabforum.org>> wrote:
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 Santoni via Public
Sent: Wednesday, January 3, 2018 5:12 AM
To: 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 by Mad, but (if I am not mistaken) there is not a 
specific Whois record field for that information (org number), and I would 
avoid inserting that information in a field that's not expressly designed for 
it.

Other solutions may also work, and would be easier to implement, like e.g. 
mandating a full Registrant address, in the Whois record, which must be one of 
the official addresses of the Registrant as found in a QIIS/QGIS (excluding, 
however, all information sources that just publish self-reported organization 
information, which cannot be regarded as "qualified" information sources and 
IMO should not be used in the vetting process), and then the "reliable method 
of communication" should be one that is found in the matching QIIS/QGIS record.

Not sure about method 3.2.2.4.5, at this time, as I have not yet seen a 
sufficient discussion on it, and I am not sure how it can effectively be used 
"as is" to obtain a fraudulent certificate.
Adriano

Il 03/01/2018 13:27, Doug Beattie via Public ha scritto:
I agree with Mads and am also supportive of a ballot that removes 3.2.2.4.5 and 
adds some more detail to 3.2.2.4.1.

Doug

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Mads Egil 
Henriksveen via Public
Sent: Wednesday, January 3, 2018 7:11 AM
To: Jeremy Rowley 
; CA/Browser 
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 legal persons) I find these examples from Ryan and Jeremy 
to represent a very bad practice. If this really reflects the current practice 
in the industry, we need to tighten up the requirements and make them much more 
specific.

From my point of view (and with my background) I find method 3.2.2.4.1 useful. 
We must remember that the domain validation methods also are used for EV (and 
not only OV) and when we have a strongly validated and verified organization 
(e.g. based on the EV requirements) it makes sense to allow for the 
organization to apply for certificates including domain names owned by the 
organization itself.

I understand that there are doubts about how to ensure that the organization 
really owns the domain (like in Jeremy’s example), but it should not be too 
hard to “strengthen” the link between the applicant and the domain owner in 
terms of rewriting section 3.2.2.4.1. A match in the organization name only 
should of course no

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Tim Hollebeek via Public]

I will not oppose any effort by CAs to discuss whatever improvements they want 
to make to any of the validation methods in the validation working group.  I 
don’t think stifling discussion is helpful.

 

As chair of the group, I am going to do my best to run it in a fair and 
responsible manner, even when the expressed opinions disagree with mine or 
those of my employer.  I’d rather hear people’s best arguments for their 
preferred course of action.

 

Any member who wants to be part of the discussion, please feel free to show up 
for tomorrow’s call.

 

-Tim

 

From: Public [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't suggest that the VWG shouldn't take 
this up, I also don't think that should be reason not to continue the 
discussion on the public list.

 

While I understand that Mads and Adriano have suggested they see value in 
3.2.2.4.1, I do not think there's a sufficiently compelling demonstration that 
it remotely approaches the level of assurance of the other methods, or that it 
fundamentally can. Given that, I do not think 3.2.2.4.1 should be considered - 
even in modified form - to be equivalent.

 

In considering how one might theorhetically reform 3.2.2.4.1, I would suggest 
it's incumbent upon those supporting it to demonstrate how it could achieve 
that level of assurance. Barring that, we are much better as an industry and a 
Forum from removing 3.2.2.4.1 unless and until such time as an appropriate 
demonstration can be made. This avoids introducing significant security risk to 
the ecosystem due to the Forum's (rather slow) deliberative process.

 

On Wed, Jan 3, 2018 at 11:08 AM, Kirk Hall via Public mailto:public@cabforum.org> > wrote:

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 Santoni via Public
Sent: Wednesday, January 3, 2018 5:12 AM
To: 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 by Mad, but (if I am not mistaken) there is not a 
specific Whois record field for that information (org number), and I would 
avoid inserting that information in a field that's not expressly designed for 
it.

Other solutions may also work, and would be easier to implement, like e.g. 
mandating a full Registrant address, in the Whois record, which must be one of 
the official addresses of the Registrant as found in a QIIS/QGIS (excluding, 
however, all information sources that just publish self-reported organization 
information, which cannot be regarded as "qualified" information sources and 
IMO should not be used in the vetting process), and then the "reliable method 
of communication" should be one that is found in the matching QIIS/QGIS record.

Not sure about method 3.2.2.4.5, at this time, as I have not yet seen a 
sufficient discussion on it, and I am not sure how it can effectively be used 
"as is" to obtain a fraudulent certificate.

Adriano



Il 03/01/2018 13:27, Doug Beattie via Public ha scritto:

I agree with Mads and am also supportive of a ballot that removes 3.2.2.4.5 and 
adds some more detail to 3.2.2.4.1.

 

Doug

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Mads Egil 
Henriksveen via Public
Sent: Wednesday, January 3, 2018 7:11 AM
To: Jeremy Rowley   
; CA/Browser 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 legal persons) I find these examples from Ryan and Jeremy 
to represent a very bad practice. If this really reflects the current practice 
in the industry, we need to tighten up the requirements and make them much more 
specific.

 

>From my point of view (and with my background) I find method 3.2.2.4.1 useful. 
>We must remember that the domain validation methods also are used for EV (and 
>not only OV) and when we have a strongly validated and verified organization 
>(e.g. based on the EV requirements) it makes sense to allow for the 
>organization to apply for certificates including domain names owned by the 
>organization itself. 

 

I understand that there are doubts about how to ensure that the organization 
re

Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5

[Ryan Sleevi via Public]

Hi Kirk,

We had two endorsers for the discussion. As I mentioned, there's nothing
inherent in needing to direct this to VWG. As DigiCert has pointed out,
there are CAs today that are doing validations that are patently insecure.

While we can understand and appreciate that some members may wish to
introduce new validation methods that are limited in scope and
applicability (for example, Mads' example only applies to a limited subset
of ccTLDs, and cannot be done safely generically), in order to reduce that
risk, I think it's entirely appropriate to take the necessary steps to
ensure the safety of the Internet at large.

This does not prevent or inhibit the issuance of certificates that have
appropriate controls - that is, these methods could be argued as an
'optimization' - and thus we should not unduly delay progress. Regarding
passing it to the VWG, could you indicate where you saw that was suggested?
The only mention of it I saw was from you, on a separate thread, and I'm
curious if perhaps I've missed additional discussion. Certainly, our
workmode does not require sending such discussions "to committee"

On Wed, Jan 3, 2018 at 3:10 PM, Kirk Hall via Public 
wrote:

> Tim, I thought this issue was going to be discussed first by the VWG, as
> several CAs have indicated they would like to keep (but improve) Method 1.
>
>
>
> *From:* Public [mailto:public-boun...@cabforum.org] * On Behalf Of *Tim
> Hollebeek via Public
> *Sent:* Wednesday, January 3, 2018 11:22 AM
> *To:* CA/Browser Forum Public Discussion List 
> *Subject:* [EXTERNAL][cabfpub] Ballot 218: Remove validation methods #1
> and #5
>
>
>
>
>
> Ballot 218: Remove validation methods #1 and #5
>
>
>
> Purpose of Ballot: Section 3.2.2.4 says that it “defines the permitted
> processes and procedures for validating the Applicant’s ownership or
> control of the domain.”  Most of the validation methods actually do
> validate ownership and control, but two do not, and can be completed solely
> based on an applicant’s own assertions.
>
>
>
> Since these two validation methods do not meet the objectives of section
> 3.2.2.4, and are actively being used to avoid validating domain control or
> ownership, they should be removed, and the other methods that do validate
> domain control or ownership should be used.
>
>
>
> The following motion has been proposed by Tim Hollebeek of DigiCert and
> endorsed by Ryan Sleevi of Google and Rich Smith of Comodo.
>
>
>
> -- MOTION BEGINS –
>
>
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates” as follows, based upon Version
> 1.5.4:
>
>
>
> In Section 3.2.2.4.1, add text at the end: “For certificates issued on or
> after March 1, 2018, this method SHALL NOT be used for validation, and
> completed validations using this method SHALL NOT be used for the issuance
> of certificates.”
>
>
>
> In Section 3.2.2.4.5, add text at the end: “For certificates issued on or
> after March 1, 2018, this method SHALL NOT be used for validation, and
> completed validations using this method SHALL NOT be used for the issuance
> of certificates.”
>
>
>
> In Section 4.2.1, after the paragraph that begins “After the change to any
> validation method”, add the following paragraph: “Validations completed
> using methods specified in Section 3.2.2.4.1 or Section 3.2.2.4.5 SHALL NOT
> be re-used on or after March 1, 2018.”
>
>
>
> -- MOTION ENDS –
>
>
>
> For the purposes of section 4.2.1, the new text added to 4.2.1 from this
> ballot is “specifically provided in a [this] ballot.”
>
>
>
> The procedure for approval of this ballot is as follows:
>
>
>
> Discussion (7+ days)
>
>   Start Time: 2017-01-03  19:30:00 UTC
>
>   End Time: Not Before 2017-01-10 19:30:00 UTC
>
>
>
> Vote for approval (7 days)
>
>   Start Time: TBD
>
>   End Time: TBD
>
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Ryan Sleevi via Public]

Given the impact of this, while I don't suggest that the VWG shouldn't take
this up, I also don't think that should be reason not to continue the
discussion on the public list.

While I understand that Mads and Adriano have suggested they see value in
3.2.2.4.1, I do not think there's a sufficiently compelling demonstration
that it remotely approaches the level of assurance of the other methods, or
that it fundamentally can. Given that, I do not think 3.2.2.4.1 should be
considered - even in modified form - to be equivalent.

In considering how one might theorhetically reform 3.2.2.4.1, I would
suggest it's incumbent upon those supporting it to demonstrate how it could
achieve that level of assurance. Barring that, we are much better as an
industry and a Forum from removing 3.2.2.4.1 unless and until such time as
an appropriate demonstration can be made. This avoids introducing
significant security risk to the ecosystem due to the Forum's (rather slow)
deliberative process.

On Wed, Jan 3, 2018 at 11:08 AM, Kirk Hall via Public 
wrote:

> 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
> Santoni via Public
> *Sent:* Wednesday, January 3, 2018 5:12 AM
> *To:* 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 by Mad, but (if I am not mistaken) there is
> not a specific Whois record field for that information (org number), and I
> would avoid inserting that information in a field that's not expressly
> designed for it.
>
> Other solutions may also work, and would be easier to implement, like e.g.
> mandating a full Registrant address, in the Whois record, which must be one
> of the official addresses of the Registrant as found in a QIIS/QGIS
> (excluding, however, all information sources that just publish
> self-reported organization information, which cannot be regarded as
> "qualified" information sources and IMO should not be used in the vetting
> process), and then the "reliable method of communication" should be one
> that is found in the matching QIIS/QGIS record.
>
> Not sure about method 3.2.2.4.5, at this time, as I have not yet seen a
> sufficient discussion on it, and I am not sure how it can effectively be
> used "as is" to obtain a fraudulent certificate.
>
> Adriano
>
>
> Il 03/01/2018 13:27, Doug Beattie via Public ha scritto:
>
> I agree with Mads and am also supportive of a ballot that removes
> 3.2.2.4.5 and adds some more detail to 3.2.2.4.1.
>
>
>
> Doug
>
>
>
> *From:* Public [mailto:public-boun...@cabforum.org
> ] *On Behalf Of *Mads Egil Henriksveen via
> Public
> *Sent:* Wednesday, January 3, 2018 7:11 AM
> *To:* Jeremy Rowley 
> ; CA/Browser 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 legal persons) I find these examples from
> Ryan and Jeremy to represent a very bad practice. If this really reflects
> the current practice in the industry, we need to tighten up the
> requirements and make them much more specific.
>
>
>
> From my point of view (and with my background) I find method 3.2.2.4.1
> useful. We must remember that the domain validation methods also are used
> for EV (and not only OV) and when we have a strongly validated and verified
> organization (e.g. based on the EV requirements) it makes sense to allow
> for the organization to apply for certificates including domain names owned
> by the organization itself.
>
>
>
> I understand that there are doubts about how to ensure that the
> organization really owns the domain (like in Jeremy’s example), but it
> should not be too hard to “strengthen” the link between the applicant and
> the domain owner in terms of rewriting section 3.2.2.4.1. A match in the
> organization name only should of course not be allowed.
>
>
>
> In Norway every organization is given a unique organization number by a
> national authority and in the registry for the TLD=.no domains (see
> www.norid.no) we find this organization number as a part of the domain
> name registrant information. In such cases, we allow for issuance based on
> 3.2.2.4.1 if the domain name registrant information exactly match
> organization information (i.e. by country, organization name and
> organization number).  I think this is a reasonable use case for method
> 3.2.2.4.1.
>
>
>
> Personally I am more concerned about the possibility we give to any
> stakeholder in the ecosystem who takes a role in controlling a domain to
> get an OV (a

Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5

[Kirk Hall via Public]

Tim, I thought this issue was going to be discussed first by the VWG, as 
several CAs have indicated they would like to keep (but improve) Method 1.

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Tim Hollebeek 
via Public
Sent: Wednesday, January 3, 2018 11:22 AM
To: CA/Browser Forum Public Discussion List 
Subject: [EXTERNAL][cabfpub] Ballot 218: Remove validation methods #1 and #5


Ballot 218: Remove validation methods #1 and #5

Purpose of Ballot: Section 3.2.2.4 says that it "defines the permitted 
processes and procedures for validating the Applicant's ownership or control of 
the domain."  Most of the validation methods actually do validate ownership and 
control, but two do not, and can be completed solely based on an applicant's 
own assertions.

Since these two validation methods do not meet the objectives of section 
3.2.2.4, and are actively being used to avoid validating domain control or 
ownership, they should be removed, and the other methods that do validate 
domain control or ownership should be used.

The following motion has been proposed by Tim Hollebeek of DigiCert and 
endorsed by Ryan Sleevi of Google and Rich Smith of Comodo.

-- MOTION BEGINS -

This ballot modifies the "Baseline Requirements for the Issuance and Management 
of Publicly-Trusted Certificates" as follows, based upon Version 1.5.4:

In Section 3.2.2.4.1, add text at the end: "For certificates issued on or after 
March 1, 2018, this method SHALL NOT be used for validation, and completed 
validations using this method SHALL NOT be used for the issuance of 
certificates."

In Section 3.2.2.4.5, add text at the end: "For certificates issued on or after 
March 1, 2018, this method SHALL NOT be used for validation, and completed 
validations using this method SHALL NOT be used for the issuance of 
certificates."

In Section 4.2.1, after the paragraph that begins "After the change to any 
validation method", add the following paragraph: "Validations completed using 
methods specified in Section 3.2.2.4.1 or Section 3.2.2.4.5 SHALL NOT be 
re-used on or after March 1, 2018."

-- MOTION ENDS -

For the purposes of section 4.2.1, the new text added to 4.2.1 from this ballot 
is "specifically provided in a [this] ballot."

The procedure for approval of this ballot is as follows:

Discussion (7+ days)
  Start Time: 2017-01-03  19:30:00 UTC
  End Time: Not Before 2017-01-10 19:30:00 UTC

Vote for approval (7 days)
  Start Time: TBD
  End Time: TBD

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

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Tim Hollebeek via Public]

It’s now on the agenda.  I suspect it might end up taking up most of the call, 
so we’ll address it first …

 

-Tim

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Kirk Hall via 
Public
Sent: Wednesday, January 3, 2018 9:09 AM
To: CA/Browser Forum Public Discussion List 
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 Santoni 
via Public
Sent: Wednesday, January 3, 2018 5:12 AM
To: 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 by Mad, but (if I am not mistaken) there is not a 
specific Whois record field for that information (org number), and I would 
avoid inserting that information in a field that's not expressly designed for 
it.

Other solutions may also work, and would be easier to implement, like e.g. 
mandating a full Registrant address, in the Whois record, which must be one of 
the official addresses of the Registrant as found in a QIIS/QGIS (excluding, 
however, all information sources that just publish self-reported organization 
information, which cannot be regarded as "qualified" information sources and 
IMO should not be used in the vetting process), and then the "reliable method 
of communication" should be one that is found in the matching QIIS/QGIS record.

Not sure about method 3.2.2.4.5, at this time, as I have not yet seen a 
sufficient discussion on it, and I am not sure how it can effectively be used 
"as is" to obtain a fraudulent certificate.

Adriano



Il 03/01/2018 13:27, Doug Beattie via Public ha scritto:

I agree with Mads and am also supportive of a ballot that removes 3.2.2.4.5 and 
adds some more detail to 3.2.2.4.1.

 

Doug

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Mads Egil 
Henriksveen via Public
Sent: Wednesday, January 3, 2018 7:11 AM
To: Jeremy Rowley   
; CA/Browser 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 legal persons) I find these examples from Ryan and Jeremy 
to represent a very bad practice. If this really reflects the current practice 
in the industry, we need to tighten up the requirements and make them much more 
specific.

 

>From my point of view (and with my background) I find method 3.2.2.4.1 useful. 
>We must remember that the domain validation methods also are used for EV (and 
>not only OV) and when we have a strongly validated and verified organization 
>(e.g. based on the EV requirements) it makes sense to allow for the 
>organization to apply for certificates including domain names owned by the 
>organization itself. 

 

I understand that there are doubts about how to ensure that the organization 
really owns the domain (like in Jeremy’s example), but it should not be too 
hard to “strengthen” the link between the applicant and the domain owner in 
terms of rewriting section 3.2.2.4.1. A match in the organization name only 
should of course not be allowed. 

 

In Norway every organization is given a unique organization number by a 
national authority and in the registry for the TLD=.no domains (see 
www.norid.no) we find this organization number as a part of the domain name 
registrant information. In such cases, we allow for issuance based on 3.2.2.4.1 
if the domain name registrant information exactly match organization 
information (i.e. by country, organization name and organization number).  I 
think this is a reasonable use case for method 3.2.2.4.1. 

 

Personally I am more concerned about the possibility we give to any stakeholder 
in the ecosystem who takes a role in controlling a domain to get an OV (and EV) 
certificate based on domain control only. This was discussed also in the F2F 
meeting in Bilbao last year – see 
https://cabforum.org/2016/05/25/2016-05/#The-Role-of-Identity-in-TLS-Certificates.

 

Therefore, I am supportive for a ballot which removes 3.2.2.4.5 and keep 
3.2.2.4.1 but strengthen this up to allow for use cases like the one described 
above.

 

Regards

Mads  

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: onsdag 3. januar 2018 05:47
To: geo...@apple.com  ; CA/Browser Forum Public 
Discussion List   
Subject: Re: [cabfpub] Verification of D

[cabfpub] Ballot 218: Remove validation methods #1 and #5

[Tim Hollebeek via Public]

 

Ballot 218: Remove validation methods #1 and #5

 

Purpose of Ballot: Section 3.2.2.4 says that it "defines the permitted
processes and procedures for validating the Applicant's ownership or control
of the domain."  Most of the validation methods actually do validate
ownership and control, but two do not, and can be completed solely based on
an applicant's own assertions.

 

Since these two validation methods do not meet the objectives of section
3.2.2.4, and are actively being used to avoid validating domain control or
ownership, they should be removed, and the other methods that do validate
domain control or ownership should be used.

 

The following motion has been proposed by Tim Hollebeek of DigiCert and
endorsed by Ryan Sleevi of Google and Rich Smith of Comodo.

 

-- MOTION BEGINS -

 

This ballot modifies the "Baseline Requirements for the Issuance and
Management of Publicly-Trusted Certificates" as follows, based upon Version
1.5.4:

 

In Section 3.2.2.4.1, add text at the end: "For certificates issued on or
after March 1, 2018, this method SHALL NOT be used for validation, and
completed validations using this method SHALL NOT be used for the issuance
of certificates."

 

In Section 3.2.2.4.5, add text at the end: "For certificates issued on or
after March 1, 2018, this method SHALL NOT be used for validation, and
completed validations using this method SHALL NOT be used for the issuance
of certificates."

 

In Section 4.2.1, after the paragraph that begins "After the change to any
validation method", add the following paragraph: "Validations completed
using methods specified in Section 3.2.2.4.1 or Section 3.2.2.4.5 SHALL NOT
be re-used on or after March 1, 2018."

 

-- MOTION ENDS -

 

For the purposes of section 4.2.1, the new text added to 4.2.1 from this
ballot is "specifically provided in a [this] ballot."

 

The procedure for approval of this ballot is as follows:

 

Discussion (7+ days) 

  Start Time: 2017-01-03  19:30:00 UTC  

  End Time: Not Before 2017-01-10 19:30:00 UTC

 

Vote for approval (7 days) 

  Start Time: TBD   

  End Time: TBD

 



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Revocation as a domain owner

[Wayne Thayer via Public]

Matthias,

I think you've raised a valid point. I'm working on ballot 213 "Revocation
Timeline Extension" that makes changes to this section of the BRs, and I
will draft some language to attempt to address this. If you have any ideas
on how this requirement should be stated, please let me know.

Thanks,

Wayne

>
> I can't propose a ballot as I'm not a CAB member but adding the
> requirement of having to revoke certificates on the domain owner's request
> should probably be considered.
>
>
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Kirk Hall via Public]

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 Santoni 
via Public
Sent: Wednesday, January 3, 2018 5:12 AM
To: 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 by Mad, but (if I am not mistaken) there is not a 
specific Whois record field for that information (org number), and I would 
avoid inserting that information in a field that's not expressly designed for 
it.

Other solutions may also work, and would be easier to implement, like e.g. 
mandating a full Registrant address, in the Whois record, which must be one of 
the official addresses of the Registrant as found in a QIIS/QGIS (excluding, 
however, all information sources that just publish self-reported organization 
information, which cannot be regarded as "qualified" information sources and 
IMO should not be used in the vetting process), and then the "reliable method 
of communication" should be one that is found in the matching QIIS/QGIS record.

Not sure about method 3.2.2.4.5, at this time, as I have not yet seen a 
sufficient discussion on it, and I am not sure how it can effectively be used 
"as is" to obtain a fraudulent certificate.
Adriano


Il 03/01/2018 13:27, Doug Beattie via Public ha scritto:
I agree with Mads and am also supportive of a ballot that removes 3.2.2.4.5 and 
adds some more detail to 3.2.2.4.1.

Doug

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Mads Egil 
Henriksveen via Public
Sent: Wednesday, January 3, 2018 7:11 AM
To: Jeremy Rowley 
; CA/Browser 
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 legal persons) I find these examples from Ryan and Jeremy 
to represent a very bad practice. If this really reflects the current practice 
in the industry, we need to tighten up the requirements and make them much more 
specific.

From my point of view (and with my background) I find method 3.2.2.4.1 useful. 
We must remember that the domain validation methods also are used for EV (and 
not only OV) and when we have a strongly validated and verified organization 
(e.g. based on the EV requirements) it makes sense to allow for the 
organization to apply for certificates including domain names owned by the 
organization itself.

I understand that there are doubts about how to ensure that the organization 
really owns the domain (like in Jeremy’s example), but it should not be too 
hard to “strengthen” the link between the applicant and the domain owner in 
terms of rewriting section 3.2.2.4.1. A match in the organization name only 
should of course not be allowed.

In Norway every organization is given a unique organization number by a 
national authority and in the registry for the TLD=.no domains (see 
www.norid.no) we find this organization number as a part 
of the domain name registrant information. In such cases, we allow for issuance 
based on 3.2.2.4.1 if the domain name registrant information exactly match 
organization information (i.e. by country, organization name and organization 
number).  I think this is a reasonable use case for method 3.2.2.4.1.

Personally I am more concerned about the possibility we give to any stakeholder 
in the ecosystem who takes a role in controlling a domain to get an OV (and EV) 
certificate based on domain control only. This was discussed also in the F2F 
meeting in Bilbao last year – see 
https://cabforum.org/2016/05/25/2016-05/#The-Role-of-Identity-in-TLS-Certificates.

Therefore, I am supportive for a ballot which removes 3.2.2.4.5 and keep 
3.2.2.4.1 but strengthen this up to allow for use cases like the one described 
above.

Regards
Mads

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: onsdag 3. januar 2018 05:47
To: geo...@apple.com; CA/Browser Forum Public 
Discussion List 
Subject: 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 specified as the domain 
contact, no address matching is required.

From: geo...@apple.com [mailto:geo...@apple.com]
Sent: Tuesday, January 2, 2018 4:34 PM
To: Jeremy Ro

Re: [cabfpub] Revocation as a domain owner

[Rich Smith via Public]

Matthias,

Please send me the details privately so that I can look into this for you.  
This seems like a mistake on the part of whoever handled your request and 
probably indicates a shortcoming in training.

 

Regards,

Rich Smith

Sr. Compliance Manager

Comodo

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Matthias Merkel 
via Public
Sent: Wednesday, January 3, 2018 1:18 AM
To: public@cabforum.org
Subject: [cabfpub] Revocation as a domain owner

 

When trying to get a cPanel certificate revoked yesterday I noticed an issue 
with the baseline requirements. Basically Comodo (which manages the cPanel CA) 
told me that they would not revoke the certificate because we did not order it 
and we should contact cPanel for support.

I can't propose a ballot as I'm not a CAB member but adding the requirement of 
having to revoke certificates on the domain owner's request should probably be 
considered.

 

 

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

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Adriano Santoni via Public]

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 field for that information (org number), and 
I would avoid inserting that information in a field that's not expressly 
designed for it.


Other solutions may also work, and would be easier to implement, like 
e.g. mandating a full Registrant address, in the Whois record, which 
must be one of the official addresses of the Registrant as found in a 
QIIS/QGIS (excluding, however, all information sources that just publish 
self-reported organization information, which cannot be regarded as 
"qualified" information sources and IMO should not be used in the 
vetting process), and then the "reliable method of communication" should 
be one that is found in the matching QIIS/QGIS record.


Not sure about method 3.2.2.4.5, at this time, as I have not yet seen a 
sufficient discussion on it, and I am not sure how it can effectively be 
used "as is" to obtain a fraudulent certificate.


Adriano



Il 03/01/2018 13:27, Doug Beattie via Public ha scritto:


I agree with Mads and am also supportive of a ballot that removes 
3.2.2.4.5 and adds some more detail to 3.2.2.4.1.


Doug

*From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of 
*Mads Egil Henriksveen via Public

*Sent:* Wednesday, January 3, 2018 7:11 AM
*To:* Jeremy Rowley ; CA/Browser 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 legal persons) I find these examples 
from Ryan and Jeremy to represent a very bad practice. If this really 
reflects the current practice in the industry, we need to tighten up 
the requirements and make them much more specific.


From my point of view (and with my background) I find method 3.2.2.4.1 
useful. We must remember that the domain validation methods also are 
used for EV (and not only OV) and when we have a strongly validated 
and verified organization (e.g. based on the EV requirements) it makes 
sense to allow for the organization to apply for certificates 
including domain names owned by the organization itself.


I understand that there are doubts about how to ensure that the 
organization really owns the domain (like in Jeremy’s example), but it 
should not be too hard to “strengthen” the link between the applicant 
and the domain owner in terms of rewriting section 3.2.2.4.1. A match 
in the organization name only should of course not be allowed.


In Norway every organization is given a unique organization number by 
a national authority and in the registry for the TLD=.no domains (see 
www.norid.no ) we find this organization number 
as a part of the domain name registrant information. In such cases, we 
allow for issuance based on 3.2.2.4.1 if the domain name registrant 
information exactly match organization information (i.e. by country, 
organization name and organization number).  I think this is a 
reasonable use case for method 3.2.2.4.1.


Personally I am more concerned about the possibility we give to any 
stakeholder in the ecosystem who takes a role in controlling a domain 
to get an OV (and EV) certificate based on domain control only. This 
was discussed also in the F2F meeting in Bilbao last year – see 
https://cabforum.org/2016/05/25/2016-05/#The-Role-of-Identity-in-TLS-Certificates.


Therefore, I am supportive for a ballot which removes 3.2.2.4.5 and 
keep 3.2.2.4.1 but strengthen this up to allow for use cases like the 
one described above.


Regards

Mads

*From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of 
*Jeremy Rowley via Public

*Sent:* onsdag 3. januar 2018 05:47
*To:* geo...@apple.com; CA/Browser Forum Public Discussion List 

*Subject:* 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 specified as the domain contact, no address matching 
is required.


*From:* geo...@apple.com  
[mailto:geo...@apple.com]

*Sent:* Tuesday, January 2, 2018 4:34 PM
*To:* Jeremy Rowley >; CA/Browser Forum Public 
Discussion List mailto:public@cabforum.org>>
*Cc:* Ryan Sleevi mailto:sle...@google.com>>; 
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 easier than that.

 1. I use very stringent

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Doug Beattie via Public]

I agree with Mads and am also supportive of a ballot that removes 3.2.2.4.5 and 
adds some more detail to 3.2.2.4.1.

 

Doug

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Mads Egil 
Henriksveen via Public
Sent: Wednesday, January 3, 2018 7:11 AM
To: Jeremy Rowley ; CA/Browser 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 legal persons) I find these examples from Ryan and Jeremy 
to represent a very bad practice. If this really reflects the current practice 
in the industry, we need to tighten up the requirements and make them much more 
specific.

 

>From my point of view (and with my background) I find method 3.2.2.4.1 useful. 
>We must remember that the domain validation methods also are used for EV (and 
>not only OV) and when we have a strongly validated and verified organization 
>(e.g. based on the EV requirements) it makes sense to allow for the 
>organization to apply for certificates including domain names owned by the 
>organization itself. 

 

I understand that there are doubts about how to ensure that the organization 
really owns the domain (like in Jeremy’s example), but it should not be too 
hard to “strengthen” the link between the applicant and the domain owner in 
terms of rewriting section 3.2.2.4.1. A match in the organization name only 
should of course not be allowed. 

 

In Norway every organization is given a unique organization number by a 
national authority and in the registry for the TLD=.no domains (see 
www.norid.no  ) we find this organization number as a part 
of the domain name registrant information. In such cases, we allow for issuance 
based on 3.2.2.4.1 if the domain name registrant information exactly match 
organization information (i.e. by country, organization name and organization 
number).  I think this is a reasonable use case for method 3.2.2.4.1. 

 

Personally I am more concerned about the possibility we give to any stakeholder 
in the ecosystem who takes a role in controlling a domain to get an OV (and EV) 
certificate based on domain control only. This was discussed also in the F2F 
meeting in Bilbao last year – see 
https://cabforum.org/2016/05/25/2016-05/#The-Role-of-Identity-in-TLS-Certificates.

 

Therefore, I am supportive for a ballot which removes 3.2.2.4.5 and keep 
3.2.2.4.1 but strengthen this up to allow for use cases like the one described 
above.

 

Regards

Mads  

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: onsdag 3. januar 2018 05:47
To: geo...@apple.com; CA/Browser Forum Public Discussion List 

Subject: 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 specified as the domain 
contact, no address matching is required.

 

From: geo...@apple.com   [mailto:geo...@apple.com] 
Sent: Tuesday, January 2, 2018 4:34 PM
To: Jeremy Rowley mailto:jeremy.row...@digicert.com> >; CA/Browser Forum Public Discussion List 
mailto:public@cabforum.org> >
Cc: Ryan Sleevi mailto:sle...@google.com> >; Adriano 
Santoni mailto:adriano.sant...@staff.aruba.it> 
>
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 easier than that. 

1.  I use very stringent processes to verify that Google, Inc. is a legit 
company in Utah.
2.  I verify that Jeremy did indeed incorporate Google, Inc. 
3.  I call Jeremy at the phone listed for Google, Inc., the Utah corporation
4.  The domain information shows Google, Inc. as owning  
 google.com
5.  Certificate issues.

 

Obviously this would be caught in every CA’s high risk checks, but the point 
remains valid. Regardless of the expertise and thoroughness of the org check, 
the specs lack any time between the verified org and the actual domain because 
orgs are not unique on a global basis.

 

 

For item 4, you have to verify that “the Applicant is the Domain Contact”.  
Obviously it’s insufficient to just compare names—you must verify every element 
of the WHOIS contact matches the Applicant, that’s typically name, postal 
address, phone number, and e-mail.

 



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Mads Egil Henriksveen via Public]

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 legal persons) I find these examples from Ryan and Jeremy 
to represent a very bad practice. If this really reflects the current practice 
in the industry, we need to tighten up the requirements and make them much more 
specific.

From my point of view (and with my background) I find method 3.2.2.4.1 useful. 
We must remember that the domain validation methods also are used for EV (and 
not only OV) and when we have a strongly validated and verified organization 
(e.g. based on the EV requirements) it makes sense to allow for the 
organization to apply for certificates including domain names owned by the 
organization itself.

I understand that there are doubts about how to ensure that the organization 
really owns the domain (like in Jeremy’s example), but it should not be too 
hard to “strengthen” the link between the applicant and the domain owner in 
terms of rewriting section 3.2.2.4.1. A match in the organization name only 
should of course not be allowed.

In Norway every organization is given a unique organization number by a 
national authority and in the registry for the TLD=.no domains (see 
www.norid.no) we find this organization number as a part 
of the domain name registrant information. In such cases, we allow for issuance 
based on 3.2.2.4.1 if the domain name registrant information exactly match 
organization information (i.e. by country, organization name and organization 
number).  I think this is a reasonable use case for method 3.2.2.4.1.

Personally I am more concerned about the possibility we give to any stakeholder 
in the ecosystem who takes a role in controlling a domain to get an OV (and EV) 
certificate based on domain control only. This was discussed also in the F2F 
meeting in Bilbao last year – see 
https://cabforum.org/2016/05/25/2016-05/#The-Role-of-Identity-in-TLS-Certificates.

Therefore, I am supportive for a ballot which removes 3.2.2.4.5 and keep 
3.2.2.4.1 but strengthen this up to allow for use cases like the one described 
above.

Regards
Mads

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: onsdag 3. januar 2018 05:47
To: geo...@apple.com; CA/Browser Forum Public Discussion List 

Subject: 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 specified as the domain 
contact, no address matching is required.

From: geo...@apple.com [mailto:geo...@apple.com]
Sent: Tuesday, January 2, 2018 4:34 PM
To: Jeremy Rowley 
mailto:jeremy.row...@digicert.com>>; CA/Browser 
Forum Public Discussion List mailto:public@cabforum.org>>
Cc: Ryan Sleevi mailto:sle...@google.com>>; Adriano Santoni 
mailto:adriano.sant...@staff.aruba.it>>
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 easier than that.

  1.  I use very stringent processes to verify that Google, Inc. is a legit 
company in Utah.
  2.  I verify that Jeremy did indeed incorporate Google, Inc.
  3.  I call Jeremy at the phone listed for Google, Inc., the Utah corporation
  4.  The domain information shows Google, Inc. as owning 
google.com
  5.  Certificate issues.

Obviously this would be caught in every CA’s high risk checks, but the point 
remains valid. Regardless of the expertise and thoroughness of the org check, 
the specs lack any time between the verified org and the actual domain because 
orgs are not unique on a global basis.


For item 4, you have to verify that “the Applicant is the Domain Contact”.  
Obviously it’s insufficient to just compare names—you must verify every element 
of the WHOIS contact matches the Applicant, that’s typically name, postal 
address, phone number, and e-mail.

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