Re: [cabfpub] Voting begins: Ballot 218 version 2

[Josh Aas via Public]

Let's Encrypt votes YES on ballot 218

On Mon, Feb 5, 2018 at 2:09 PM, Berge, J. van den (Jochem) - Logius
via Public <public@cabforum.org> wrote:
> PKIoverheid votes YES.
>
>
>
> We’ve been following the discussion as it has unfolded. The definition of
> current methods 3.2.2.4.1 and 3.2.2.4.5, as currently worded in the BR, we
> have to agree,  leaves much room for interpretation. However, we might be
> able to improve these methods, a process that will require time.
>
>
>
> In this discussion there are CAs and browsers on the one side who are
> (possibly) proposing a more radical solution of termination of said
> validation methods per March 1 (enforced through browser program
> requirements), there is ballot 218 which proposes abolition of 3.2.2.4.1 and
> 3.2.2.4.5 per August 1, and there are parties who want to keep current
> methods in place, at least long enough for new and improved versions to be
> developed and deployed. The last option has the danger that a working group
> effort could go on for months and months without much progress, while the
> current methods stay in place. This ballot, with a firm deadline of August
> 1, puts a fixed end date on the current methods .1 and .5. We welcome
> possible working group discussions about a new or improved domain validation
> methods (possibly included in the broader discussion, see Dimitris’ response
> below) and is, in our view, this ballot is the best approach forward. It’s a
> combination of an achievable timeline for CAs to move away from 3.2.2.4.1
> and 3.2.2.4.5 while also including a final date by which CAs must have
> changed to a different method.
>
>
>
> Kind regards,
>
>
>
> Jochem van den Berge
>
>
>
> Logius PKIoverheid
>
> Public Key Infrastructure for the Dutch government
>
> 
>
> Logius
>
> Ministry of the Interior and Kingdom Relations (BZK)
>
> Wilhelmina van Pruisenweg 52 | 2595 AN | The Hague
> PO Box 96810 | 2509 JE | The Hague
>
> 
>
> jochem.vanden.be...@logius.nl
>
> http://www.logius.nl
>
>
>
>
>
>
>
> Van: Public [mailto:public-boun...@cabforum.org] Namens Dimitris
> Zacharopoulos via Public
> Verzonden: donderdag 1 februari 2018 15:35
> Aan: public@cabforum.org
> Onderwerp: Re: [cabfpub] Voting begins: Ballot 218 version 2
>
>
>
>
> All currently approved Domain Validation methods provide some level of
> assurance which is not easily quantifiable without calculating the risks
> (vulnerabilities, threats) of each method. If we had a methodology to
> quantify the assurance level of each method, we would be able to compare
> them.
>
> The discussion around methods 3.2.2.4.1 (1 and 2)  and 3.2.2.4.5
> demonstrated that these methods have lower assurance levels than the other
> methods, without providing conclusive evidence to support ultimate failure
> of #1 and #5. If we had that, probably all validations performed with
> methods #1 and #5 would have to be invalidated and re-done using other
> methods. This means that the forum considered these methods "acceptable" so
> far which means they provided a "reasonable" assurance level. The bar has
> been raised, but not in a measurable way. Intuitively, these methods were
> proved to be the "weakest" among the other methods, even though there are
> known vulnerabilities for almost all of them (including DNS/routes
> hijacking, etc). The validation working group should discuss more about the
> threats of each method (and how to formalize the level of assurance) in case
> a similar discussion about the other methods is brought forward.
>
> HARICA votes "abstain" to ballot 218.
>
>
> Dimitris.
>
> On 29/1/2018 11:51 μμ, Tim Hollebeek via Public wrote:
>
>
>
> I’m highly skeptical that discussing this for another month will change
> anybody’s minds.  It has already been discussed for over a month, including
> at three validation working group meetings and once on the management call,
> with extensive discussion on this list as well.
>
>
>
> There have been a number of clever attempts to distract from the matter at
> hand.  Everybody seems to agree that methods #1 and #5 as currently written
> are insufficient to validate certificates, and efforts to improve method #1
> have all either been shown to be similarly weak, or have turned the
> validation method into one of the other existing validation methods.  In
> fact, this demonstrates an obvious transition path for CAs currently using
> method #1: use method #2 or method #3.
>
>
>
> Since methods 

Re: [cabfpub] Voting begins: Ballot 218 version 2

[Berge, J. van den (Jochem) - Logius via Public]

PKIoverheid votes YES.

We’ve been following the discussion as it has unfolded. The definition of 
current methods 3.2.2.4.1 and 3.2.2.4.5, as currently worded in the BR, we have 
to agree,  leaves much room for interpretation. However, we might be able to 
improve these methods, a process that will require time.

In this discussion there are CAs and browsers on the one side who are 
(possibly) proposing a more radical solution of termination of said validation 
methods per March 1 (enforced through browser program requirements), there is 
ballot 218 which proposes abolition of 3.2.2.4.1 and 3.2.2.4.5 per August 1, 
and there are parties who want to keep current methods in place, at least long 
enough for new and improved versions to be developed and deployed. The last 
option has the danger that a working group effort could go on for months and 
months without much progress, while the current methods stay in place. This 
ballot, with a firm deadline of August 1, puts a fixed end date on the current 
methods .1 and .5. We welcome possible working group discussions about a new or 
improved domain validation methods (possibly included in the broader 
discussion, see Dimitris’ response below) and is, in our view, this ballot is 
the best approach forward. It’s a combination of an achievable timeline for CAs 
to move away from 3.2.2.4.1 and 3.2.2.4.5 while also including a final date by 
which CAs must have changed to a different method.

Kind regards,

Jochem van den Berge

Logius PKIoverheid
Public Key Infrastructure for the Dutch government

Logius
Ministry of the Interior and Kingdom Relations (BZK)
Wilhelmina van Pruisenweg 52 | 2595 AN | The Hague
PO Box 96810 | 2509 JE | The Hague

jochem.vanden.be...@logius.nl<mailto:jochem.vanden.be...@logius.nl>
http://www.logius.nl



Van: Public [mailto:public-boun...@cabforum.org] Namens Dimitris Zacharopoulos 
via Public
Verzonden: donderdag 1 februari 2018 15:35
Aan: public@cabforum.org<mailto:public@cabforum.org>
Onderwerp: Re: [cabfpub] Voting begins: Ballot 218 version 2


All currently approved Domain Validation methods provide some level of 
assurance which is not easily quantifiable without calculating the risks 
(vulnerabilities, threats) of each method. If we had a methodology to quantify 
the assurance level of each method, we would be able to compare them.

The discussion around methods 3.2.2.4.1 (1 and 2)  and 3.2.2.4.5 demonstrated 
that these methods have lower assurance levels than the other methods, without 
providing conclusive evidence to support ultimate failure of #1 and #5. If we 
had that, probably all validations performed with methods #1 and #5 would have 
to be invalidated and re-done using other methods. This means that the forum 
considered these methods "acceptable" so far which means they provided a 
"reasonable" assurance level. The bar has been raised, but not in a measurable 
way. Intuitively, these methods were proved to be the "weakest" among the other 
methods, even though there are known vulnerabilities for almost all of them 
(including DNS/routes hijacking, etc). The validation working group should 
discuss more about the threats of each method (and how to formalize the level 
of assurance) in case a similar discussion about the other methods is brought 
forward.

HARICA votes "abstain" to ballot 218.


Dimitris.

On 29/1/2018 11:51 μμ, Tim Hollebeek via Public wrote:

I’m highly skeptical that discussing this for another month will change 
anybody’s minds.  It has already been discussed for over a month, including at 
three validation working group meetings and once on the management call, with 
extensive discussion on this list as well.

There have been a number of clever attempts to distract from the matter at 
hand.  Everybody seems to agree that methods #1 and #5 as currently written are 
insufficient to validate certificates, and efforts to improve method #1 have 
all either been shown to be similarly weak, or have turned the validation 
method into one of the other existing validation methods.  In fact, this 
demonstrates an obvious transition path for CAs currently using method #1: use 
method #2 or method #3.

Since methods #1 and #5 do not sufficiently validate certificates, they should 
not be used, and six months should be more than enough time to cease using them.

Here is the final version of the ballot, with voting times.  A redlined 
document is attached (I encourage other proposers to post ballot redlines, even 
if it isn’t required).

-Tim

- Ballot 218 version 2: 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 act

Re: [cabfpub] Voting begins: Ballot 218 version 2

[realsky(CHT) via Public]

Chunghwa Telecom Co., Ltd. Votes “No”  on Ballot 218. 


   Li-Chun Chen




From: Public[mailto:public-boun...@cabforum.org] On Behalf Of Mads Egil 
Henriksveenvia Public
Sent: Friday, February 02, 2018 8:52 PM
To: Tim Hollebeek; CA/Browser Forum Public Discussion List
Subject: [外部郵件]Re: [cabfpub] Voting begins: Ballot 218 version 2
 
Buypass votes NO.
 
There are use cases and scenarios where animproved version of method #1 for 
proving ownership of a domain would beappropriate. Method #1 is only to be used 
for OV/EV and as such theauthorization to issue the certificate must be given 
by an authoritativerepresentative of the applicant. If we can prove that the 
applicant is equal tothe domain owner in a proper way, we consider this to be 
sufficient to issuethe certificate. The validation and issuance of OV/EV must 
be based on bothverifying the Applicant’s identity and domain ownership (with 
or without thetechnical demonstration of domain control). 
 
BR 3.2.2.4 says ‘defines the permittedprocesses and procedures for validating 
the Applicant’s ownership or control ofthe domain’. The concept of validating 
an Applicant’s ownership is mostimportant for OV/EV as this is a scenario where 
the Applicant always must beverified. Then it is possible to verify domain 
ownership based on a properlyverified identity and address of the Applicant. 
All other methods focus ondomain control and we can’t see that the concept of 
domain ownership is wellcovered by any of these methods. 
 
We understand that domain control isconsidered to be very important, but we 
would like to emphasize that weconsider the concept of ‘domain control’ and 
‘domainownership’ to be two different concepts - atleast seen in relation to 
the issuance of OV/EV. If we really mean to includeboth concepts in the domain 
validation methods, this should be made moreexplicit. 
 
We are concerned that a switch of focustowards domain control also for OV/EV 
might result in less focus on domainownership and thus giving any actor who 
controls the domain a possibility toget an OV/EV for that domain. I would hate 
to see e.g. the DNS provider ofBuypass AS being able to get an EV certificate 
with the identity of the DNSprovider and the domain buypass.no based on domain 
control only. 
 
It is difficult to evaluate the quality ofmethod #1 on itself without at the 
same time evaluate the parts of BR (and EVG)relevant for using the method - for 
OV (BR 3.2.2.1 and 3.2.5) and similar inEVG for EV.
 
We are not convinced that all the othermethods based on domain control in all 
cases necessarily provides a higherlevel of assurance than an improved method 
#1 for OV/EV certificates. We agreewith Dimitris that it is important to get a 
better understanding of thevulnerabilities and threats for each of the domain 
validation methods and thisshould be analyzed independently for DV and OV/EV.
 
Regards
Mads
 
 

From: Public <public-boun...@cabforum.org> on behalf of Tim Hollebeek via 
Public <public@cabforum.org>
Reply-To: Tim Hollebeek <tim.holleb...@digicert.com>, CA/Browser Forum Public 
Discussion List <public@cabforum.org>
Date: Monday, 29 January, 2018 at 17:07 
To: CA/Browser Forum Public Discussion List <public@cabforum.org>
Subject: [cabfpub] Voting begins: Ballot 218 version 2

 

 

I’m highly skeptical that discussing this for another month will change 
anybody’s minds.  It has already been discussed for over a month, including at 
three validation working group meetings and once on the management call, with 
extensive discussion on this list as well.

 

There have been a number of clever attempts to distract from the matter at 
hand.  Everybody seems to agree that methods #1 and #5 as currently written are 
insufficient to validate certificates, and efforts to improve method #1 have 
all either been shown to be similarly weak, or have turned the validation 
method into one of the other existing validation methods.  In fact, this 
demonstrates an obvious transition path for CAs currently using method #1: use 
method #2 or method #3.

 

Since methods #1 and #5 do not sufficiently validate certificates, they should 
not be used, and six months should be more than enough time to cease using them.

 

Here is the final version of the ballot, with voting times.  A redlined 
document is attached (I encourage other proposers to post ballot redlines, even 
if it isn’t required).

 

-Tim

 

- Ballot 218 version 2: 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 validatin

Re: [cabfpub] Voting begins: Ballot 218 version 2

[Frank Corday via Public]

Trustwave votes YES to Ballot 218 version 2

From: Public > 
on behalf of Tim Hollebeek via Public 
>
Reply-To: Tim Hollebeek 
>, CA/Browser 
Forum Public Discussion List >
Date: Monday, 29 January, 2018 at 17:07
To: CA/Browser Forum Public Discussion List 
>
Subject: [cabfpub] Voting begins: Ballot 218 version 2


I’m highly skeptical that discussing this for another month will change 
anybody’s minds.  It has already been discussed for over a month, including at 
three validation working group meetings and once on the management call, with 
extensive discussion on this list as well.

There have been a number of clever attempts to distract from the matter at 
hand.  Everybody seems to agree that methods #1 and #5 as currently written are 
insufficient to validate certificates, and efforts to improve method #1 have 
all either been shown to be similarly weak, or have turned the validation 
method into one of the other existing validation methods.  In fact, this 
demonstrates an obvious transition path for CAs currently using method #1: use 
method #2 or method #3.

Since methods #1 and #5 do not sufficiently validate certificates, they should 
not be used, and six months should be more than enough time to cease using them.

Here is the final version of the ballot, with voting times.  A redlined 
document is attached (I encourage other proposers to post ballot redlines, even 
if it isn’t required).

-Tim

- Ballot 218 version 2: 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 1.6.1, in the definition of “Domain Contact”, after “in a DNS SOA 
record”, add “, or as obtained through direct contact with the Domain Name 
Registrar”

In Section 3.2.2.4.1, add text at the end: “For certificates issued on or after 
August 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 
August 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.”

After Section 3.2.2.4.10, add following two new subsections:
“3.2.2.4.11 Any Other Method

This method has been retired and MUST NOT be used.

3.2.2.4.12 Validating Applicant as a Domain Contact

Confirming the Applicant's control over the FQDN by validating the Applicant is 
the Domain Contact. This method may only be used if the CA is also the Domain 
Name Registrar, or an Affiliate of the Registrar, of the Base Domain Name.

Note: Once the FQDN has been validated using this method, the CA MAY also issue 
Certificates for other FQDNs that end with all the labels of the validated 
FQDN. This method is suitable for validating Wildcard Domain Names.“

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 August 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-22  21:30:00 UTC
  End Time: 2017-01-29 21:50:00 UTC

Vote for approval (7 days)
  Start Time: 2017-01-29 21:50:00 UTC
  End Time: 2017-02-05 21:50 UTC

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

Re: [cabfpub] Voting begins: Ballot 218 version 2

[Adriano Santoni via Public]

Actalis "abstains".

We appreciate the intent to improve the security of domain validation 
procedures, but we would have preferred a strengthening of Method 1 - 
which seemed quite possible - rather than its abolition.


Adriano


Il 29/01/2018 22:51, Tim Hollebeek via Public ha scritto:


I’m highly skeptical that discussing this for another month will 
change anybody’s minds.  It has already been discussed for over a 
month, including at three validation working group meetings and once 
on the management call, with extensive discussion on this list as well.


There have been a number of clever attempts to distract from the 
matter at hand.  Everybody seems to agree that methods #1 and #5 as 
currently written are insufficient to validate certificates, and 
efforts to improve method #1 have all either been shown to be 
similarly weak, or have turned the validation method into one of the 
other existing validation methods.  In fact, this demonstrates an 
obvious transition path for CAs currently using method #1: use method 
#2 or method #3.


Since methods #1 and #5 do not sufficiently validate certificates, 
they should not be used, and six months should be more than enough 
time to cease using them.


Here is the final version of the ballot, with voting times.  A 
redlined document is attached (I encourage other proposers to post 
ballot redlines, even if it isn’t required).


-Tim

- Ballot 218 version 2: 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 1.6.1, in the definition of “Domain Contact”, after “in a 
DNS SOA record”, add “, or as obtained through direct contact with the 
Domain Name Registrar”


In Section 3.2.2.4.1, add text at the end: “For certificates issued on 
or after August 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 August 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.”


After Section 3.2.2.4.10, add following two new subsections:

“3.2.2.4.11 Any Other Method

This method has been retired and MUST NOT be used.

3.2.2.4.12 Validating Applicant as a Domain Contact

Confirming the Applicant's control over the FQDN by validating the 
Applicant is the Domain Contact. This method may only be used if the 
CA is also the Domain Name Registrar, or an Affiliate of the 
Registrar, of the Base Domain Name.


Note: Once the FQDN has been validated using this method, the CA MAY 
also issue Certificates for other FQDNs that end with all the labels 
of the validated FQDN. This method is suitable for validating Wildcard 
Domain Names.“


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 August 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-22  21:30:00 UTC

  End Time: 2017-01-29 21:50:00 UTC

Vote for approval (7 days)

  Start Time: 2017-01-29 21:50:00 UTC

  End Time: 2017-02-05 21:50 UTC



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




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

Re: [cabfpub] Voting begins: Ballot 218 version 2

[cornelia.enke--- via Public]

 

 

SwissSign  votes No on ballot 218

 

 

 

 

Best Regards Conny

 

 





 

From: Public <  
public-boun...@cabforum.org> on behalf of Tim Hollebeek via Public < 
 public@cabforum.org>
Reply-To: Tim Hollebeek <  
tim.holleb...@digicert.com>, CA/Browser Forum Public Discussion List < 
 public@cabforum.org>
Date: Monday, 29 January, 2018 at 17:07 
To: CA/Browser Forum Public Discussion List <  
public@cabforum.org>
Subject: [cabfpub] Voting begins: Ballot 218 version 2

 

 

I’m highly skeptical that discussing this for another month will change 
anybody’s minds.  It has already been discussed for over a month, including at 
three validation working group meetings and once on the management call, with 
extensive discussion on this list as well.

 

There have been a number of clever attempts to distract from the matter at 
hand.  Everybody seems to agree that methods #1 and #5 as currently written are 
insufficient to validate certificates, and efforts to improve method #1 have 
all either been shown to be similarly weak, or have turned the validation 
method into one of the other existing validation methods.  In fact, this 
demonstrates an obvious transition path for CAs currently using method #1: use 
method #2 or method #3.

 

Since methods #1 and #5 do not sufficiently validate certificates, they should 
not be used, and six months should be more than enough time to cease using them.

 

Here is the final version of the ballot, with voting times.  A redlined 
document is attached (I encourage other proposers to post ballot redlines, even 
if it isn’t required).

 

-Tim

 

- Ballot 218 version 2: 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 1.6.1, in the definition of “Domain Contact”, after “in a DNS SOA 
record”, add “, or as obtained through direct contact with the Domain Name 
Registrar”

 

In Section 3.2.2.4.1, add text at the end: “For certificates issued on or after 
August 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 
August 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.”

 

After Section 3.2.2.4.10, add following two new subsections:

“3.2.2.4.11 Any Other Method

 

This method has been retired and MUST NOT be used.

 

3.2.2.4.12 Validating Applicant as a Domain Contact

 

Confirming the Applicant's control over the FQDN by validating the Applicant is 
the Domain Contact. This method may only be used if the CA is also the Domain 
Name Registrar, or an Affiliate of the Registrar, of the Base Domain Name.

 

Note: Once the FQDN has been validated using this method, the CA MAY also issue 
Certificates for other FQDNs that end with all the labels of the validated 
FQDN. This method is suitable for validating Wildcard Domain Names.“

 

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 August 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-22  21:30:00 UTC  

  End Time: 2017-01-29 21:50:00 UTC

 

Vote for approval (7 days) 

  Start Time: 2017-01-29 21:50:00 UTC

  End Time: 2017-02-05 21:50 UTC

 

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

 



smime.p7s
Description: S/MIME 

Re: [cabfpub] Voting begins: Ballot 218 version 2

[Peter Miškovič via Public]

Disig abstains.

Regards,
Peter

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Tim Hollebeek 
via Public
Sent: Monday, January 29, 2018 10:52 PM
To: CA/Browser Forum Public Discussion List 
Subject: [cabfpub] Voting begins: Ballot 218 version 2


I'm highly skeptical that discussing this for another month will change 
anybody's minds.  It has already been discussed for over a month, including at 
three validation working group meetings and once on the management call, with 
extensive discussion on this list as well.

There have been a number of clever attempts to distract from the matter at 
hand.  Everybody seems to agree that methods #1 and #5 as currently written are 
insufficient to validate certificates, and efforts to improve method #1 have 
all either been shown to be similarly weak, or have turned the validation 
method into one of the other existing validation methods.  In fact, this 
demonstrates an obvious transition path for CAs currently using method #1: use 
method #2 or method #3.

Since methods #1 and #5 do not sufficiently validate certificates, they should 
not be used, and six months should be more than enough time to cease using them.

Here is the final version of the ballot, with voting times.  A redlined 
document is attached (I encourage other proposers to post ballot redlines, even 
if it isn't required).

-Tim

- Ballot 218 version 2: 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 1.6.1, in the definition of "Domain Contact", after "in a DNS SOA 
record", add ", or as obtained through direct contact with the Domain Name 
Registrar"

In Section 3.2.2.4.1, add text at the end: "For certificates issued on or after 
August 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 
August 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."

After Section 3.2.2.4.10, add following two new subsections:
"3.2.2.4.11 Any Other Method

This method has been retired and MUST NOT be used.

3.2.2.4.12 Validating Applicant as a Domain Contact

Confirming the Applicant's control over the FQDN by validating the Applicant is 
the Domain Contact. This method may only be used if the CA is also the Domain 
Name Registrar, or an Affiliate of the Registrar, of the Base Domain Name.

Note: Once the FQDN has been validated using this method, the CA MAY also issue 
Certificates for other FQDNs that end with all the labels of the validated 
FQDN. This method is suitable for validating Wildcard Domain Names."

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 August 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-22  21:30:00 UTC
  End Time: 2017-01-29 21:50:00 UTC

Vote for approval (7 days)
  Start Time: 2017-01-29 21:50:00 UTC
  End Time: 2017-02-05 21:50 UTC

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

Re: [cabfpub] Voting begins: Ballot 218 version 2

[Entschew, Enrico via Public]

D-TRUST votes Yes on ballot 2018, version 2
As documented in our CP/CPS we currently use both methods in our current 
validation practice. The underlying processes are audited by an independent 
conformity assessment body (TÜV IT) against the specifications of the BR as 
well as the European regulation eIDAS.
As D-TRUST issues no DV certificates, however our applied validation processes 
are always significantly more extensive than the sole application of validation 
method 2.3.3.4.1 or 2.3.3.4.5.

We will adapt our testing processes and introduce further validation methods. 
The conversion of the processes includes changes to  manual and automated 
processes as implemented by us especially in our managed service platform.
Of course, we aim to carry out the adjustments and to put them into operation 
as quickly as possible.
However, we certainly need sufficient time to:
-  re-validate domains within our managed service that used this method 
well before the August 1st date, and
-  Implement system updates in order to enable all our managed service 
customers to use the newly implemented methods.

We thus agree with GlobalSign that the August date is tight, but achievable.

Finally we agree with the view expressed that we do need a more formal and 
rigorous evaluation of the risks and vulnerabilities inherent in the use of 
each validation method and would be happy to contribute to this.

Enrico



Von: Public [mailto:public-boun...@cabforum.org] Im Auftrag von Tim Hollebeek 
via Public
Gesendet: Montag, 29. Januar 2018 22:52
An: CA/Browser Forum Public Discussion List
Betreff: [cabfpub] Voting begins: Ballot 218 version 2


I'm highly skeptical that discussing this for another month will change 
anybody's minds.  It has already been discussed for over a month, including at 
three validation working group meetings and once on the management call, with 
extensive discussion on this list as well.

There have been a number of clever attempts to distract from the matter at 
hand.  Everybody seems to agree that methods #1 and #5 as currently written are 
insufficient to validate certificates, and efforts to improve method #1 have 
all either been shown to be similarly weak, or have turned the validation 
method into one of the other existing validation methods.  In fact, this 
demonstrates an obvious transition path for CAs currently using method #1: use 
method #2 or method #3.

Since methods #1 and #5 do not sufficiently validate certificates, they should 
not be used, and six months should be more than enough time to cease using them.

Here is the final version of the ballot, with voting times.  A redlined 
document is attached (I encourage other proposers to post ballot redlines, even 
if it isn't required).

-Tim

- Ballot 218 version 2: 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 1.6.1, in the definition of "Domain Contact", after "in a DNS SOA 
record", add ", or as obtained through direct contact with the Domain Name 
Registrar"

In Section 3.2.2.4.1, add text at the end: "For certificates issued on or after 
August 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 
August 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."

After Section 3.2.2.4.10, add following two new subsections:
"3.2.2.4.11 Any Other Method

This method has been retired and MUST NOT be used.

3.2.2.4.12 Validating Applicant as a Domain Contact

Confirming the Applicant's control over the FQDN by validating the Applicant is 
the Domain Contact. This method may only be used if the CA is also the Domain 
Name Registrar, or an Affiliate of the Registrar, of the Base Domain Name.

Note: Once the FQDN has been validated using this method, the CA MAY also issue 
Certificates for other FQDNs that end with all the labels of the validated 

Re: [cabfpub] Voting begins: Ballot 218 version 2

[Mads Egil Henriksveen via Public]

Buypass votes NO.

There are use cases and scenarios where an improved version of method #1 for 
proving ownership of a domain would be appropriate. Method #1 is only to be 
used for OV/EV and as such the authorization to issue the certificate must be 
given by an authoritative representative of the applicant. If we can prove that 
the applicant is equal to the domain owner in a proper way, we consider this to 
be sufficient to issue the certificate. The validation and issuance of OV/EV 
must be based on both verifying the Applicant's identity and domain ownership 
(with or without the technical demonstration of domain control).

BR 3.2.2.4 says 'defines the permitted processes and procedures for validating 
the Applicant's ownership or control of the domain'. The concept of validating 
an Applicant's ownership is most important for OV/EV as this is a scenario 
where the Applicant always must be verified. Then it is possible to verify 
domain ownership based on a properly verified identity and address of the 
Applicant. All other methods focus on domain control and we can't see that the 
concept of domain ownership is well covered by any of these methods.

We understand that domain control is considered to be very important, but we 
would like to emphasize that we consider the concept of 'domain control' and 
'domain ownership' to be two different concepts - at least seen in relation to 
the issuance of OV/EV. If we really mean to include both concepts in the domain 
validation methods, this should be made more explicit.

We are concerned that a switch of focus towards domain control also for OV/EV 
might result in less focus on domain ownership and thus giving any actor who 
controls the domain a possibility to get an OV/EV for that domain. I would hate 
to see e.g. the DNS provider of Buypass AS being able to get an EV certificate 
with the identity of the DNS provider and the domain buypass.no based on domain 
control only.

It is difficult to evaluate the quality of method #1 on itself without at the 
same time evaluate the parts of BR (and EVG) relevant for using the method - 
for OV (BR 3.2.2.1 and 3.2.5) and similar in EVG for EV.

We are not convinced that all the other methods based on domain control in all 
cases necessarily provides a higher level of assurance than an improved method 
#1 for OV/EV certificates. We agree with Dimitris that it is important to get a 
better understanding of the vulnerabilities and threats for each of the domain 
validation methods and this should be analyzed independently for DV and OV/EV.

Regards
Mads


From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Tim Hollebeek 
via Public
Sent: mandag 29. januar 2018 22:52
To: CA/Browser Forum Public Discussion List 
Subject: [cabfpub] Voting begins: Ballot 218 version 2


I'm highly skeptical that discussing this for another month will change 
anybody's minds.  It has already been discussed for over a month, including at 
three validation working group meetings and once on the management call, with 
extensive discussion on this list as well.

There have been a number of clever attempts to distract from the matter at 
hand.  Everybody seems to agree that methods #1 and #5 as currently written are 
insufficient to validate certificates, and efforts to improve method #1 have 
all either been shown to be similarly weak, or have turned the validation 
method into one of the other existing validation methods.  In fact, this 
demonstrates an obvious transition path for CAs currently using method #1: use 
method #2 or method #3.

Since methods #1 and #5 do not sufficiently validate certificates, they should 
not be used, and six months should be more than enough time to cease using them.

Here is the final version of the ballot, with voting times.  A redlined 
document is attached (I encourage other proposers to post ballot redlines, even 
if it isn't required).

-Tim

- Ballot 218 version 2: 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 1.6.1, in the definition of "Domain Contact", after "in a 

Re: [cabfpub] Voting begins: Ballot 218 version 2

[Patrick Tronnier via Public]

OATI Abstains  on Ballot 218 version 2.


Thanks

With kind regards,

Patrick Tronnier
Principal Security Architect &
Sr. Director of Quality Assurance & Customer Support
Phone: 763.201.2000
Direct Line: 763.201.2052
Open Access Technology International, Inc.
3660 Technology Drive NE, Minneapolis, MN

CONFIDENTIAL INFORMATION: This email and any attachment(s) contain confidential 
and/or proprietary information of Open Access Technology International, Inc. Do 
not copy or distribute without the prior written consent of OATI. If you are 
not a named recipient to the message, please notify the sender immediately and 
do not retain the message in any form, printed or electronic.


From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Tim Hollebeek 
via Public
Sent: Monday, January 29, 2018 4:52 PM
To: CA/Browser Forum Public Discussion List 
>
Subject: [cabfpub] Voting begins: Ballot 218 version 2


I'm highly skeptical that discussing this for another month will change 
anybody's minds.  It has already been discussed for over a month, including at 
three validation working group meetings and once on the management call, with 
extensive discussion on this list as well.

There have been a number of clever attempts to distract from the matter at 
hand.  Everybody seems to agree that methods #1 and #5 as currently written are 
insufficient to validate certificates, and efforts to improve method #1 have 
all either been shown to be similarly weak, or have turned the validation 
method into one of the other existing validation methods.  In fact, this 
demonstrates an obvious transition path for CAs currently using method #1: use 
method #2 or method #3.

Since methods #1 and #5 do not sufficiently validate certificates, they should 
not be used, and six months should be more than enough time to cease using them.

Here is the final version of the ballot, with voting times.  A redlined 
document is attached (I encourage other proposers to post ballot redlines, even 
if it isn't required).

-Tim

- Ballot 218 version 2: 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 1.6.1, in the definition of "Domain Contact", after "in a DNS SOA 
record", add ", or as obtained through direct contact with the Domain Name 
Registrar"

In Section 3.2.2.4.1, add text at the end: "For certificates issued on or after 
August 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 
August 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."

After Section 3.2.2.4.10, add following two new subsections:
"3.2.2.4.11 Any Other Method

This method has been retired and MUST NOT be used.

3.2.2.4.12 Validating Applicant as a Domain Contact

Confirming the Applicant's control over the FQDN by validating the Applicant is 
the Domain Contact. This method may only be used if the CA is also the Domain 
Name Registrar, or an Affiliate of the Registrar, of the Base Domain Name.

Note: Once the FQDN has been validated using this method, the CA MAY also issue 
Certificates for other FQDNs that end with all the labels of the validated 
FQDN. This method is suitable for validating Wildcard Domain Names."

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 August 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-22  21:30:00 UTC
  End Time: 2017-01-29 21:50:00 UTC

Vote for approval (7 days)
  Start Time: 2017-01-29 21:50:00 

Re: [cabfpub] Voting begins: Ballot 218 version 2

[Fotis Loukos via Public]

SSL.com votes Yes on Ballot 218 version 2.

Regards,
Fotis

On 29/01/2018 11:51 μμ, Tim Hollebeek via Public wrote:
>  
> 
> I’m highly skeptical that discussing this for another month will change
> anybody’s minds.  It has already been discussed for over a month,
> including at three validation working group meetings and once on the
> management call, with extensive discussion on this list as well.
> 
>  
> 
> There have been a number of clever attempts to distract from the matter
> at hand.  Everybody seems to agree that methods #1 and #5 as currently
> written are insufficient to validate certificates, and efforts to
> improve method #1 have all either been shown to be similarly weak, or
> have turned the validation method into one of the other existing
> validation methods.  In fact, this demonstrates an obvious transition
> path for CAs currently using method #1: use method #2 or method #3.
> 
>  
> 
> Since methods #1 and #5 do not sufficiently validate certificates, they
> should not be used, and six months should be more than enough time to
> cease using them.
> 
>  
> 
> Here is the final version of the ballot, with voting times.  A redlined
> document is attached (I encourage other proposers to post ballot
> redlines, even if it isn’t required).
> 
>  
> 
> -Tim
> 
>  
> 
> - Ballot 218 version 2: 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 1.6.1, in the definition of “Domain Contact”, after “in a DNS
> SOA record”, add “, or as obtained through direct contact with the
> Domain Name Registrar”
> 
>  
> 
> In Section 3.2.2.4.1, add text at the end: “For certificates issued on
> or after August 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 August 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.”
> 
>  
> 
> After Section 3.2.2.4.10, add following two new subsections:
> 
> “3.2.2.4.11 Any Other Method
> 
>  
> 
> This method has been retired and MUST NOT be used.
> 
>  
> 
> 3.2.2.4.12 Validating Applicant as a Domain Contact
> 
>  
> 
> Confirming the Applicant's control over the FQDN by validating the
> Applicant is the Domain Contact. This method may only be used if the CA
> is also the Domain Name Registrar, or an Affiliate of the Registrar, of
> the Base Domain Name.
> 
>  
> 
> Note: Once the FQDN has been validated using this method, the CA MAY
> also issue Certificates for other FQDNs that end with all the labels of
> the validated FQDN. This method is suitable for validating Wildcard
> Domain Names.“
> 
>  
> 
> 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 August 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-22  21:30:00 UTC 
> 
>   End Time: 2017-01-29 21:50:00 UTC
> 
>  
> 
> Vote for approval (7 days)
> 
>   Start Time: 2017-01-29 21:50:00 UTC
> 
>   End Time: 2017-02-05 21:50 UTC
> 
>  
> 
> 
> 
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
> 


-- 
Fotis Loukos, PhD
Director of Security Architecture
SSL Corp
e: fot...@ssl.com
w: https://www.ssl.com
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Voting begins: Ballot 218 version 2

[Tim Hollebeek via Public]

You’re right and there is a proposal to do exactly that.  It will be discussed 
on the VWG today if you want to join.  We do need a more formal and rigorous 
evaluation of the risks and vulnerabilities inherent in the use of each 
validation method.

 

-Tim

 

Intuitively, these methods were proved to be the "weakest" among the other 
methods, even though there are known vulnerabilities for almost all of them 
(including DNS/routes hijacking, etc). The validation working group should 
discuss more about the threats of each method (and how to formalize the level 
of assurance) in case a similar discussion about the other methods is brought 
forward.





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

Re: [cabfpub] Voting begins: Ballot 218 version 2

[Dimitris Zacharopoulos via Public]

All currently approved Domain Validation methods provide some level of
assurance which is not easily quantifiable without calculating the risks
(vulnerabilities, threats) of each method. If we had a methodology to
quantify the assurance level of each method, we would be able to compare
them.

The discussion around methods 3.2.2.4.1 (1 and 2)  and 3.2.2.4.5
demonstrated that these methods have lower assurance levels than the
other methods, without providing conclusive evidence to support ultimate
failure of #1 and #5. If we had that, probably all validations performed
with methods #1 and #5 would have to be invalidated and re-done using
other methods. This means that the forum considered these methods
"acceptable" so far which means they provided a "reasonable" assurance
level. The bar has been raised, but not in a measurable way.
Intuitively, these methods were proved to be the "weakest" among the
other methods, even though there are known vulnerabilities for almost
all of them (including DNS/routes hijacking, etc). The validation
working group should discuss more about the threats of each method (and
how to formalize the level of assurance) in case a similar discussion
about the other methods is brought forward.

HARICA votes "abstain" to ballot 218.


Dimitris.


On 29/1/2018 11:51 μμ, Tim Hollebeek via Public wrote:
>
>  
>
> I’m highly skeptical that discussing this for another month will
> change anybody’s minds.  It has already been discussed for over a
> month, including at three validation working group meetings and once
> on the management call, with extensive discussion on this list as well.
>
>  
>
> There have been a number of clever attempts to distract from the
> matter at hand.  Everybody seems to agree that methods #1 and #5 as
> currently written are insufficient to validate certificates, and
> efforts to improve method #1 have all either been shown to be
> similarly weak, or have turned the validation method into one of the
> other existing validation methods.  In fact, this demonstrates an
> obvious transition path for CAs currently using method #1: use method
> #2 or method #3.
>
>  
>
> Since methods #1 and #5 do not sufficiently validate certificates,
> they should not be used, and six months should be more than enough
> time to cease using them.
>
>  
>
> Here is the final version of the ballot, with voting times.  A
> redlined document is attached (I encourage other proposers to post
> ballot redlines, even if it isn’t required).
>
>  
>
> -Tim
>
>  
>
> - Ballot 218 version 2: 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 1.6.1, in the definition of “Domain Contact”, after “in a
> DNS SOA record”, add “, or as obtained through direct contact with the
> Domain Name Registrar”
>
>  
>
> In Section 3.2.2.4.1, add text at the end: “For certificates issued on
> or after August 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 August 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.”
>
>  
>
> After Section 3.2.2.4.10, add following two new subsections:
>
> “3.2.2.4.11 Any Other Method
>
>  
>
> This method has been retired and MUST NOT be used.
>
>  
>
> 3.2.2.4.12 Validating Applicant as a Domain Contact
>
>  
>
> Confirming the Applicant's control over the FQDN by validating the
> Applicant is the Domain Contact. This method may only be used if the
> CA is also the Domain Name Registrar, or an Affiliate of the
> Registrar, of the Base Domain Name.
>
>  
>
> Note: Once the FQDN has been validated using this method, the CA MAY
> also issue Certificates for other FQDNs that end with all the labels
> of the validated FQDN. This method is suitable for validating Wildcard
> Domain Names.“
>
>  
>
> In Section 4.2.1, after the 

Re: [cabfpub] Voting begins: Ballot 218 version 2

[zhangyq via Public]

GDCA votes YES on Ballot 218.


Yongqiang ZHANG


原始邮件
发件人:Curt Spann via publicpub...@cabforum.org
收件人:Tim hollebeektim.holleb...@digicert.com; CA/Browser Forum Public Discussion 
listpub...@cabforum.org
发送时间:2018年1月30日(周二) 09:26
主题:Re: [cabfpub] Voting begins: Ballot 218 version 2


Apple votes YES on Ballot 218.


Curt



On Jan 29, 2018, at 1:51 PM, Tim Hollebeek via Public public@cabforum.org wrote:



I’m highly skeptical that discussing this for another month will change 
anybody’s minds. It has already been discussed for over a month, including at 
three validation working group meetings and once on the management call, with 
extensive discussion on this list as well.

There have been a number of clever attempts to distract from the matter at 
hand. Everybody seems to agree that methods #1 and #5 as currently written are 
insufficient to validate certificates, and efforts to improve method #1 have 
all either been shown to be similarly weak, or have turned the validation 
method into one of the other existing validation methods. In fact, this 
demonstrates an obvious transition path for CAs currently using method #1: use 
method #2 or method #3.

Since methods #1 and #5 do not sufficiently validate certificates, they should 
not be used, and six months should be more than enough time to cease using them.

Here is the final version of the ballot, with voting times. A redlined document 
is attached (I encourage other proposers to post ballot redlines, even if it 
isn’t required).

-Tim

- Ballot 218 version 2: 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 1.6.1, in the definition of “Domain Contact”, after “in a DNS SOA 
record”, add “, or as obtained through direct contact with the Domain Name 
Registrar”

In Section 3.2.2.4.1, add text at the end: “For certificates issued on or after 
August 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 
August 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.”

After Section 3.2.2.4.10, add following two new subsections:
“3.2.2.4.11 Any Other Method

This method has been retired and MUST NOT be used.

3.2.2.4.12 Validating Applicant as a Domain Contact

Confirming the Applicant's control over the FQDN by validating the Applicant is 
the Domain Contact. This method may only be used if the CA is also the Domain 
Name Registrar, or an Affiliate of the Registrar, of the Base Domain Name.

Note: Once the FQDN has been validated using this method, the CA MAY also issue 
Certificates for other FQDNs that end with all the labels of the validated 
FQDN. This method is suitable for validating Wildcard Domain Names.“

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 August 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-22 21:30:00 UTC
End Time: 2017-01-29 21:50:00 UTC

Vote for approval (7 days)
Start Time: 2017-01-29 21:50:00 UTC
End Time: 2017-02-05 21:50 UTC

CA-Browser Forum BR 1.5.4 - Ballot 218 
redline.doc___
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] Voting begins: Ballot 218 version 2

[philliph--- via Public]

Comodo Security Services votes Yes on ballot 218



>  
> From: Public  > on behalf of Tim Hollebeek via Public 
> >
> Reply-To: Tim Hollebeek  >, CA/Browser Forum Public Discussion List 
> >
> Date: Monday, 29 January, 2018 at 17:07 
> To: CA/Browser Forum Public Discussion List  >
> Subject: [cabfpub] Voting begins: Ballot 218 version 2
>  
>   <>
> I’m highly skeptical that discussing this for another month will change 
> anybody’s minds.  It has already been discussed for over a month, including 
> at three validation working group meetings and once on the management call, 
> with extensive discussion on this list as well.
>  
> There have been a number of clever attempts to distract from the matter at 
> hand.  Everybody seems to agree that methods #1 and #5 as currently written 
> are insufficient to validate certificates, and efforts to improve method #1 
> have all either been shown to be similarly weak, or have turned the 
> validation method into one of the other existing validation methods.  In 
> fact, this demonstrates an obvious transition path for CAs currently using 
> method #1: use method #2 or method #3.
>  
> Since methods #1 and #5 do not sufficiently validate certificates, they 
> should not be used, and six months should be more than enough time to cease 
> using them.
>  
> Here is the final version of the ballot, with voting times.  A redlined 
> document is attached (I encourage other proposers to post ballot redlines, 
> even if it isn’t required).
>  
> -Tim
>  
> - Ballot 218 version 2: 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 1.6.1, in the definition of “Domain Contact”, after “in a DNS SOA 
> record”, add “, or as obtained through direct contact with the Domain Name 
> Registrar”
>  
> In Section 3.2.2.4.1, add text at the end: “For certificates issued on or 
> after August 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 August 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.”
>  
> After Section 3.2.2.4.10, add following two new subsections:
> “3.2.2.4.11 Any Other Method
>  
> This method has been retired and MUST NOT be used.
>  
> 3.2.2.4.12 Validating Applicant as a Domain Contact
>  
> Confirming the Applicant's control over the FQDN by validating the Applicant 
> is the Domain Contact. This method may only be used if the CA is also the 
> Domain Name Registrar, or an Affiliate of the Registrar, of the Base Domain 
> Name.
>  
> Note: Once the FQDN has been validated using this method, the CA MAY also 
> issue Certificates for other FQDNs that end with all the labels of the 
> validated FQDN. This method is suitable for validating Wildcard Domain Names.“
>  
> 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 August 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-22  21:30:00 UTC  
>   End Time: 2017-01-29 21:50:00 UTC
>  
> Vote for approval (7 days) 
>   Start Time: 2017-01-29 21:50:00 UTC
>   End Time: 2017-02-05 21:50 UTC
>  
> ___
> Public mailing list
> 

Re: [cabfpub] Voting begins: Ballot 218 version 2

[Daymion T. Reynolds via Public]

GoDaddy votes YES on Ballot 218

From: Public > 
on behalf of Tim Hollebeek via Public 
>
Reply-To: Tim Hollebeek 
>, CA/Browser 
Forum Public Discussion List >
Date: Monday, 29 January, 2018 at 17:07
To: CA/Browser Forum Public Discussion List 
>
Subject: [cabfpub] Voting begins: Ballot 218 version 2


I’m highly skeptical that discussing this for another month will change 
anybody’s minds.  It has already been discussed for over a month, including at 
three validation working group meetings and once on the management call, with 
extensive discussion on this list as well.

There have been a number of clever attempts to distract from the matter at 
hand.  Everybody seems to agree that methods #1 and #5 as currently written are 
insufficient to validate certificates, and efforts to improve method #1 have 
all either been shown to be similarly weak, or have turned the validation 
method into one of the other existing validation methods.  In fact, this 
demonstrates an obvious transition path for CAs currently using method #1: use 
method #2 or method #3.

Since methods #1 and #5 do not sufficiently validate certificates, they should 
not be used, and six months should be more than enough time to cease using them.

Here is the final version of the ballot, with voting times.  A redlined 
document is attached (I encourage other proposers to post ballot redlines, even 
if it isn’t required).

-Tim

- Ballot 218 version 2: 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 1.6.1, in the definition of “Domain Contact”, after “in a DNS SOA 
record”, add “, or as obtained through direct contact with the Domain Name 
Registrar”

In Section 3.2.2.4.1, add text at the end: “For certificates issued on or after 
August 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 
August 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.”

After Section 3.2.2.4.10, add following two new subsections:
“3.2.2.4.11 Any Other Method

This method has been retired and MUST NOT be used.

3.2.2.4.12 Validating Applicant as a Domain Contact

Confirming the Applicant's control over the FQDN by validating the Applicant is 
the Domain Contact. This method may only be used if the CA is also the Domain 
Name Registrar, or an Affiliate of the Registrar, of the Base Domain Name.

Note: Once the FQDN has been validated using this method, the CA MAY also issue 
Certificates for other FQDNs that end with all the labels of the validated 
FQDN. This method is suitable for validating Wildcard Domain Names.“

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 August 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-22  21:30:00 UTC
  End Time: 2017-01-29 21:50:00 UTC

Vote for approval (7 days)
  Start Time: 2017-01-29 21:50:00 UTC
  End Time: 2017-02-05 21:50 UTC

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

Re: [cabfpub] Voting begins: Ballot 218 version 2

[Tim Hollebeek via Public]

Yup, the ballot text is what matters, the redline is for convenience.  I'll
fix the redline.  Thanks for the feedback.

 

-Tim

 

From: Doug Beattie [mailto:doug.beat...@globalsign.com] 
Sent: Wednesday, January 31, 2018 10:50 AM
To: Tim Hollebeek ; CA/Browser Forum Public
Discussion List 
Subject: RE: Voting begins: Ballot 218 version 2

 

GlobalSign votes Yes on ballot 218, version 2.

 

Note that the redlined ballot that Tim attached incorrectly lists the new
method, "Validating Applicant as a Domain Contact" as method 10.
Sequentially it follows section 2.3.3.4.11 so I'm sure that is a typo, but
it's something that needs to be fixed.

 

We use method 1 quite often and feel our approach is solid; however, given
the documented lack of direct communication to the domain registrant or
technical validation techniques at the time of validation, we will change
our practices to use alternate methods.  While it's not that hard to modify
manual methods, we want to have suffice time to:

*   complete the process of re-validating domains within our managed
service that used this method well before the August 1st date, and
*   Implement system updates to drive all OV/EV customers to use one of
the automated methods (2, 4, 6 or 7).  

 

We believe the August date is tight, but achievable to accomplish both of
these.

 

Doug

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Tim Hollebeek
via Public
Sent: Monday, January 29, 2018 4:52 PM
To: CA/Browser Forum Public Discussion List  >
Subject: [cabfpub] Voting begins: Ballot 218 version 2

 

 

I'm highly skeptical that discussing this for another month will change
anybody's minds.  It has already been discussed for over a month, including
at three validation working group meetings and once on the management call,
with extensive discussion on this list as well.

 

There have been a number of clever attempts to distract from the matter at
hand.  Everybody seems to agree that methods #1 and #5 as currently written
are insufficient to validate certificates, and efforts to improve method #1
have all either been shown to be similarly weak, or have turned the
validation method into one of the other existing validation methods.  In
fact, this demonstrates an obvious transition path for CAs currently using
method #1: use method #2 or method #3.

 

Since methods #1 and #5 do not sufficiently validate certificates, they
should not be used, and six months should be more than enough time to cease
using them.

 

Here is the final version of the ballot, with voting times.  A redlined
document is attached (I encourage other proposers to post ballot redlines,
even if it isn't required).

 

-Tim

 

- Ballot 218 version 2: 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 1.6.1, in the definition of "Domain Contact", after "in a DNS SOA
record", add ", or as obtained through direct contact with the Domain Name
Registrar"

 

In Section 3.2.2.4.1, add text at the end: "For certificates issued on or
after August 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 August 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."

 

After Section 3.2.2.4.10, add following two new subsections:

"3.2.2.4.11 Any Other Method

 

This method has been retired and MUST NOT be used.

 

3.2.2.4.12 Validating Applicant as a Domain Contact

 

Confirming the Applicant's control over the FQDN by validating the Applicant
is the Domain Contact. This method may only be used if the CA is also the
Domain Name Registrar, or an Affiliate of the Registrar, of the Base Domain
Name.

 

Note: Once the FQDN has been validated using this method, the CA MAY also
issue Certificates for other FQDNs 

Re: [cabfpub] Voting begins: Ballot 218 version 2

[Doug Beattie via Public]

GlobalSign votes Yes on ballot 218, version 2.

Note that the redlined ballot that Tim attached incorrectly lists the new 
method, "Validating Applicant as a Domain Contact" as method 10.  Sequentially 
it follows section 2.3.3.4.11 so I'm sure that is a typo, but it's something 
that needs to be fixed.

We use method 1 quite often and feel our approach is solid; however, given the 
documented lack of direct communication to the domain registrant or technical 
validation techniques at the time of validation, we will change our practices 
to use alternate methods.  While it's not that hard to modify manual methods, 
we want to have suffice time to:

-  complete the process of re-validating domains within our managed 
service that used this method well before the August 1st date, and

-  Implement system updates to drive all OV/EV customers to use one of 
the automated methods (2, 4, 6 or 7).

We believe the August date is tight, but achievable to accomplish both of these.

Doug

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Tim Hollebeek 
via Public
Sent: Monday, January 29, 2018 4:52 PM
To: CA/Browser Forum Public Discussion List 
Subject: [cabfpub] Voting begins: Ballot 218 version 2


I'm highly skeptical that discussing this for another month will change 
anybody's minds.  It has already been discussed for over a month, including at 
three validation working group meetings and once on the management call, with 
extensive discussion on this list as well.

There have been a number of clever attempts to distract from the matter at 
hand.  Everybody seems to agree that methods #1 and #5 as currently written are 
insufficient to validate certificates, and efforts to improve method #1 have 
all either been shown to be similarly weak, or have turned the validation 
method into one of the other existing validation methods.  In fact, this 
demonstrates an obvious transition path for CAs currently using method #1: use 
method #2 or method #3.

Since methods #1 and #5 do not sufficiently validate certificates, they should 
not be used, and six months should be more than enough time to cease using them.

Here is the final version of the ballot, with voting times.  A redlined 
document is attached (I encourage other proposers to post ballot redlines, even 
if it isn't required).

-Tim

- Ballot 218 version 2: 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 1.6.1, in the definition of "Domain Contact", after "in a DNS SOA 
record", add ", or as obtained through direct contact with the Domain Name 
Registrar"

In Section 3.2.2.4.1, add text at the end: "For certificates issued on or after 
August 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 
August 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."

After Section 3.2.2.4.10, add following two new subsections:
"3.2.2.4.11 Any Other Method

This method has been retired and MUST NOT be used.

3.2.2.4.12 Validating Applicant as a Domain Contact

Confirming the Applicant's control over the FQDN by validating the Applicant is 
the Domain Contact. This method may only be used if the CA is also the Domain 
Name Registrar, or an Affiliate of the Registrar, of the Base Domain Name.

Note: Once the FQDN has been validated using this method, the CA MAY also issue 
Certificates for other FQDNs that end with all the labels of the validated 
FQDN. This method is suitable for validating Wildcard Domain Names."

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 August 1, 2018."

-- MOTION ENDS -

For the purposes of section 4.2.1, the new text added 

Re: [cabfpub] Voting begins: Ballot 218 version 2

[Wayne Thayer via Public]

Mozilla votes Yes on Ballot 218.

Wayne


On Mon, Jan 29, 2018 at 2:51 PM, Tim Hollebeek via Public <
public@cabforum.org> wrote:

>
>
> I’m highly skeptical that discussing this for another month will change
> anybody’s minds.  It has already been discussed for over a month, including
> at three validation working group meetings and once on the management call,
> with extensive discussion on this list as well.
>
>
>
> There have been a number of clever attempts to distract from the matter at
> hand.  Everybody seems to agree that methods #1 and #5 as currently written
> are insufficient to validate certificates, and efforts to improve method #1
> have all either been shown to be similarly weak, or have turned the
> validation method into one of the other existing validation methods.  In
> fact, this demonstrates an obvious transition path for CAs currently using
> method #1: use method #2 or method #3.
>
>
>
> Since methods #1 and #5 do not sufficiently validate certificates, they
> should not be used, and six months should be more than enough time to cease
> using them.
>
>
>
> Here is the final version of the ballot, with voting times.  A redlined
> document is attached (I encourage other proposers to post ballot redlines,
> even if it isn’t required).
>
>
>
> -Tim
>
>
>
> - Ballot 218 version 2: 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 1.6.1, in the definition of “Domain Contact”, after “in a DNS
> SOA record”, add “, or as obtained through direct contact with the Domain
> Name Registrar”
>
>
>
> In Section 3.2.2.4.1, add text at the end: “For certificates issued on or
> after August 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 August 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.”
>
>
>
> After Section 3.2.2.4.10, add following two new subsections:
>
> “3.2.2.4.11 Any Other Method
>
>
>
> This method has been retired and MUST NOT be used.
>
>
>
> 3.2.2.4.12 Validating Applicant as a Domain Contact
>
>
>
> Confirming the Applicant's control over the FQDN by validating the
> Applicant is the Domain Contact. This method may only be used if the CA is
> also the Domain Name Registrar, or an Affiliate of the Registrar, of the
> Base Domain Name.
>
>
>
> Note: Once the FQDN has been validated using this method, the CA MAY also
> issue Certificates for other FQDNs that end with all the labels of the
> validated FQDN. This method is suitable for validating Wildcard Domain
> Names.“
>
>
>
> 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 August 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-22  21:30:00 UTC
>
>   End Time: 2017-01-29 21:50:00 UTC
>
>
>
> Vote for approval (7 days)
>
>   Start Time: 2017-01-29 21:50:00 UTC
>
>   End Time: 2017-02-05 21:50 UTC
>
>
>
> ___
> 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] Voting begins: Ballot 218 version 2

[García Jimeno , Oscar via Public]

Izenpe votes YES on ballot 218 version 2

.eus gara !
horregatik orain nire helbide elektronikoa da:
por eso mi dirección de correo electrónico ahora es:  
o-gar...@izenpe.eus

Oscar García
CISSP, CISM

[Descripción: Descripción: firma_email_Izenpe_eus]



ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. 
Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki 
idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. 
KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la 
que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error 
le agradeceriamos que no hiciera uso de la informacion y que se pusiese en 
contacto con el remitente.


[Descripción: cid:image001.png@01D2DDEC.B8FB6830]

De: Public [mailto:public-boun...@cabforum.org] En nombre de Tim Hollebeek via 
Public
Enviado el: lunes, 29 de enero de 2018 22:52
Para: CA/Browser Forum Public Discussion List
Asunto: [cabfpub] Voting begins: Ballot 218 version 2


I’m highly skeptical that discussing this for another month will change 
anybody’s minds.  It has already been discussed for over a month, including at 
three validation working group meetings and once on the management call, with 
extensive discussion on this list as well.

There have been a number of clever attempts to distract from the matter at 
hand.  Everybody seems to agree that methods #1 and #5 as currently written are 
insufficient to validate certificates, and efforts to improve method #1 have 
all either been shown to be similarly weak, or have turned the validation 
method into one of the other existing validation methods.  In fact, this 
demonstrates an obvious transition path for CAs currently using method #1: use 
method #2 or method #3.

Since methods #1 and #5 do not sufficiently validate certificates, they should 
not be used, and six months should be more than enough time to cease using them.

Here is the final version of the ballot, with voting times.  A redlined 
document is attached (I encourage other proposers to post ballot redlines, even 
if it isn’t required).

-Tim

- Ballot 218 version 2: 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 1.6.1, in the definition of “Domain Contact”, after “in a DNS SOA 
record”, add “, or as obtained through direct contact with the Domain Name 
Registrar”

In Section 3.2.2.4.1, add text at the end: “For certificates issued on or after 
August 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 
August 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.”

After Section 3.2.2.4.10, add following two new subsections:
“3.2.2.4.11 Any Other Method

This method has been retired and MUST NOT be used.

3.2.2.4.12 Validating Applicant as a Domain Contact

Confirming the Applicant's control over the FQDN by validating the Applicant is 
the Domain Contact. This method may only be used if the CA is also the Domain 
Name Registrar, or an Affiliate of the Registrar, of the Base Domain Name.

Note: Once the FQDN has been validated using this method, the CA MAY also issue 
Certificates for other FQDNs that end with all the labels of the validated 
FQDN. This method is suitable for validating Wildcard Domain Names.“

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 August 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-22  

Re: [cabfpub] Voting begins: Ballot 218 version 2

[Mike Reilly (WDG) via Public]

Microsoft votes YES

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Tim Hollebeek 
via Public
Sent: Monday, January 29, 2018 1:52 PM
To: CA/Browser Forum Public Discussion List 
Subject: [cabfpub] Voting begins: Ballot 218 version 2


I'm highly skeptical that discussing this for another month will change 
anybody's minds.  It has already been discussed for over a month, including at 
three validation working group meetings and once on the management call, with 
extensive discussion on this list as well.

There have been a number of clever attempts to distract from the matter at 
hand.  Everybody seems to agree that methods #1 and #5 as currently written are 
insufficient to validate certificates, and efforts to improve method #1 have 
all either been shown to be similarly weak, or have turned the validation 
method into one of the other existing validation methods.  In fact, this 
demonstrates an obvious transition path for CAs currently using method #1: use 
method #2 or method #3.

Since methods #1 and #5 do not sufficiently validate certificates, they should 
not be used, and six months should be more than enough time to cease using them.

Here is the final version of the ballot, with voting times.  A redlined 
document is attached (I encourage other proposers to post ballot redlines, even 
if it isn't required).

-Tim

- Ballot 218 version 2: 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 1.6.1, in the definition of "Domain Contact", after "in a DNS SOA 
record", add ", or as obtained through direct contact with the Domain Name 
Registrar"

In Section 3.2.2.4.1, add text at the end: "For certificates issued on or after 
August 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 
August 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."

After Section 3.2.2.4.10, add following two new subsections:
"3.2.2.4.11 Any Other Method

This method has been retired and MUST NOT be used.

3.2.2.4.12 Validating Applicant as a Domain Contact

Confirming the Applicant's control over the FQDN by validating the Applicant is 
the Domain Contact. This method may only be used if the CA is also the Domain 
Name Registrar, or an Affiliate of the Registrar, of the Base Domain Name.

Note: Once the FQDN has been validated using this method, the CA MAY also issue 
Certificates for other FQDNs that end with all the labels of the validated 
FQDN. This method is suitable for validating Wildcard Domain Names."

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 August 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-22  21:30:00 UTC
  End Time: 2017-01-29 21:50:00 UTC

Vote for approval (7 days)
  Start Time: 2017-01-29 21:50:00 UTC
  End Time: 2017-02-05 21:50 UTC

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

Re: [cabfpub] Voting begins: Ballot 218 version 2

[Neil Dunbar via Public]

TrustCor votes YES on Ballot 218.

Neil

> On 30 Jan 2018, at 17:03, Rich Smith via Public  wrote:
> 
> Comodo CA votes YES on Ballot 218.

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

Re: [cabfpub] Voting begins: Ballot 218 version 2

[Rich Smith via Public]

Comodo CA votes YES on Ballot 218.

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Tim Hollebeek
via Public
Sent: Monday, January 29, 2018 3:52 PM
To: CA/Browser Forum Public Discussion List 
Subject: [cabfpub] Voting begins: Ballot 218 version 2

 

 

I'm highly skeptical that discussing this for another month will change
anybody's minds.  It has already been discussed for over a month, including
at three validation working group meetings and once on the management call,
with extensive discussion on this list as well.

 

There have been a number of clever attempts to distract from the matter at
hand.  Everybody seems to agree that methods #1 and #5 as currently written
are insufficient to validate certificates, and efforts to improve method #1
have all either been shown to be similarly weak, or have turned the
validation method into one of the other existing validation methods.  In
fact, this demonstrates an obvious transition path for CAs currently using
method #1: use method #2 or method #3.

 

Since methods #1 and #5 do not sufficiently validate certificates, they
should not be used, and six months should be more than enough time to cease
using them.

 

Here is the final version of the ballot, with voting times.  A redlined
document is attached (I encourage other proposers to post ballot redlines,
even if it isn't required).

 

-Tim

 

- Ballot 218 version 2: 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 1.6.1, in the definition of "Domain Contact", after "in a DNS SOA
record", add ", or as obtained through direct contact with the Domain Name
Registrar"

 

In Section 3.2.2.4.1, add text at the end: "For certificates issued on or
after August 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 August 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."

 

After Section 3.2.2.4.10, add following two new subsections:

"3.2.2.4.11 Any Other Method

 

This method has been retired and MUST NOT be used.

 

3.2.2.4.12 Validating Applicant as a Domain Contact

 

Confirming the Applicant's control over the FQDN by validating the Applicant
is the Domain Contact. This method may only be used if the CA is also the
Domain Name Registrar, or an Affiliate of the Registrar, of the Base Domain
Name.

 

Note: Once the FQDN has been validated using this method, the CA MAY also
issue Certificates for other FQDNs that end with all the labels of the
validated FQDN. This method is suitable for validating Wildcard Domain
Names."

 

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 August 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-22  21:30:00 UTC  

  End Time: 2017-01-29 21:50:00 UTC

 

Vote for approval (7 days) 

  Start Time: 2017-01-29 21:50:00 UTC

  End Time: 2017-02-05 21:50 UTC

 

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

Re: [cabfpub] Voting begins: Ballot 218 version 2

[Devon O'Brien via Public]

Google votes YES on Ballot 218.

On Mon, Jan 29, 2018 at 1:53 PM, Tim Hollebeek via Public <
public@cabforum.org> wrote:

> DigiCert votes YES on Ballot 218.
>
>
>
> *From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of *Tim
> Hollebeek via Public
> *Sent:* Monday, January 29, 2018 2:52 PM
> *To:* CA/Browser Forum Public Discussion List 
> *Subject:* [cabfpub] Voting begins: Ballot 218 version 2
>
>
>
>
>
> I’m highly skeptical that discussing this for another month will change
> anybody’s minds.  It has already been discussed for over a month, including
> at three validation working group meetings and once on the management call,
> with extensive discussion on this list as well.
>
>
>
> There have been a number of clever attempts to distract from the matter at
> hand.  Everybody seems to agree that methods #1 and #5 as currently written
> are insufficient to validate certificates, and efforts to improve method #1
> have all either been shown to be similarly weak, or have turned the
> validation method into one of the other existing validation methods.  In
> fact, this demonstrates an obvious transition path for CAs currently using
> method #1: use method #2 or method #3.
>
>
>
> Since methods #1 and #5 do not sufficiently validate certificates, they
> should not be used, and six months should be more than enough time to cease
> using them.
>
>
>
> Here is the final version of the ballot, with voting times.  A redlined
> document is attached (I encourage other proposers to post ballot redlines,
> even if it isn’t required).
>
>
>
> -Tim
>
>
>
> - Ballot 218 version 2: 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 1.6.1, in the definition of “Domain Contact”, after “in a DNS
> SOA record”, add “, or as obtained through direct contact with the Domain
> Name Registrar”
>
>
>
> In Section 3.2.2.4.1, add text at the end: “For certificates issued on or
> after August 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 August 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.”
>
>
>
> After Section 3.2.2.4.10, add following two new subsections:
>
> “3.2.2.4.11 Any Other Method
>
>
>
> This method has been retired and MUST NOT be used.
>
>
>
> 3.2.2.4.12 Validating Applicant as a Domain Contact
>
>
>
> Confirming the Applicant's control over the FQDN by validating the
> Applicant is the Domain Contact. This method may only be used if the CA is
> also the Domain Name Registrar, or an Affiliate of the Registrar, of the
> Base Domain Name.
>
>
>
> Note: Once the FQDN has been validated using this method, the CA MAY also
> issue Certificates for other FQDNs that end with all the labels of the
> validated FQDN. This method is suitable for validating Wildcard Domain
> Names.“
>
>
>
> 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 August 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-22  21:30:00 UTC
>
>   End Time: 2017-01-29 21:50:00 UTC
>
>
>
> Vote for approval (7 days)
>
>   Start Time: 2017-01-29 21:50:00 UTC
>
>   End Time: 2017-02-05 21:50 UTC
>
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
___
Public mailing list
Public@cabforum.org

Re: [cabfpub] Voting begins: Ballot 218 version 2

[Tim Hollebeek via Public]

DigiCert votes YES on Ballot 218.

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Tim Hollebeek
via Public
Sent: Monday, January 29, 2018 2:52 PM
To: CA/Browser Forum Public Discussion List 
Subject: [cabfpub] Voting begins: Ballot 218 version 2

 

 

I'm highly skeptical that discussing this for another month will change
anybody's minds.  It has already been discussed for over a month, including
at three validation working group meetings and once on the management call,
with extensive discussion on this list as well.

 

There have been a number of clever attempts to distract from the matter at
hand.  Everybody seems to agree that methods #1 and #5 as currently written
are insufficient to validate certificates, and efforts to improve method #1
have all either been shown to be similarly weak, or have turned the
validation method into one of the other existing validation methods.  In
fact, this demonstrates an obvious transition path for CAs currently using
method #1: use method #2 or method #3.

 

Since methods #1 and #5 do not sufficiently validate certificates, they
should not be used, and six months should be more than enough time to cease
using them.

 

Here is the final version of the ballot, with voting times.  A redlined
document is attached (I encourage other proposers to post ballot redlines,
even if it isn't required).

 

-Tim

 

- Ballot 218 version 2: 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 1.6.1, in the definition of "Domain Contact", after "in a DNS SOA
record", add ", or as obtained through direct contact with the Domain Name
Registrar"

 

In Section 3.2.2.4.1, add text at the end: "For certificates issued on or
after August 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 August 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."

 

After Section 3.2.2.4.10, add following two new subsections:

"3.2.2.4.11 Any Other Method

 

This method has been retired and MUST NOT be used.

 

3.2.2.4.12 Validating Applicant as a Domain Contact

 

Confirming the Applicant's control over the FQDN by validating the Applicant
is the Domain Contact. This method may only be used if the CA is also the
Domain Name Registrar, or an Affiliate of the Registrar, of the Base Domain
Name.

 

Note: Once the FQDN has been validated using this method, the CA MAY also
issue Certificates for other FQDNs that end with all the labels of the
validated FQDN. This method is suitable for validating Wildcard Domain
Names."

 

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 August 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-22  21:30:00 UTC  

  End Time: 2017-01-29 21:50:00 UTC

 

Vote for approval (7 days) 

  Start Time: 2017-01-29 21:50:00 UTC

  End Time: 2017-02-05 21:50 UTC

 



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