[cabfpub] Ballot 120

Wed Jun 4 09:15:10 UTC 2014

TURKTRUST votes "YES".

Regards,

Mert


On Wed, Jun 4, 2014 at 12:08 PM, Adriano Santoni - Actalis S.p.A. <
adriano.santoni at staff.aruba.it> wrote:

>  Actalis votes "Yes"
>
>
>
>  Il 04/06/2014 10:52, Miskovic Peter ha scritto:
>
>  Disig votes „Yes“.
>
> Regards,
>
> Peter Miskovic
>
>
>
> *From:* public-bounces at cabforum.org [mailto:public-bounces at cabforum.org
> <public-bounces at cabforum.org>] *On Behalf Of *Ben Wilson
> *Sent:* Thursday, May 22, 2014 7:59 PM
> *To:* public at cabforum.org
> *Subject:* [cabfpub] Ballot 120
>
>
>
> Kirk Hall of TrendMicro made the following motion and Jeremy Rowley of
> DigiCert and Cecilia Kam of Symantec have endorsed it:
>
>
>
> *Ballot 120 - Affiliate Authority to Verify Domain*
>
>
>
> *Reasons for proposed ballot*
>
>
>
> Ballot 72 in May 2012 reorganized the EV Guidelines by moving certain
> definitions and common provisions to the Baseline Requirements and
> replacing them with cross references to the Baseline Requirements.   In
> July 2013, Ballot 104 was a similar replacement with a cross reference to
> avoid unnecessary duplication between the two sets of guidelines , but it
> inadvertently removed domain verification through a parent or subsidiary
> from  EV Guidelines Sec. 11.6.2 (now renumbered as EVGL 11.6.1), which had
> listed it as part of the allowed verification process.  Ballot 104
> essentially deleted the separately listed EVGL 11.6.2 methods for verifying
> domain ownership, and instead inserted a cross-reference to the methods of
> verifying domain ownership in BR 11.1.1 (except for subsection (7) – “any
> other method of confirmation” – which was not deemed reliable enough for
> EV).
>
>
>
> There was no discussion to indicate that the removal was intentional, and
> no one caught the mistake during the review period.   (If you want to see
> EVGL 11.6.2 before the changes deleting the former parent/subsidiary
> language, see https://cabforum.org/wp-content/uploads/EV-V1_4_2.pdf.)
>
>
>
> Because Ballot 104 inadvertently wiped out the ability to rely on
> parent-subsidiary/affiliate ownership of domains for all types of certs,
> previously only found in EVGL 11.6.2, the EV WG determined that corrections
> to both the EVGL and BR are needed.
>
>
>
> “Affiliate” was copied over to the BR definitions and removed from the
> EVGL, but other related definitions were not.   We allow use of “affiliate”
> data for EV vetting in other contexts, and many CAs have applied the
> parent-subsidiary/affiliate rule in former EVGL 11.6.2 to vetting domains
> for both DV and OV certs, on the grounds that some companies have specially
> designated affiliates for holding intellectual property, like domain names,
> and also if the domain vetting method was good enough for EV certs, it was
> good enough for DV and OV certs as well.
>
>
>
> Ballot 120 would simply restore the prior rule of former EVGL 11.6.2,
> inadvertently wiped out by Ballot 104, and fix the copying and updating of
> definitions that were not done in Ballot 72.   This will clarify that (1)
> domain ownership by a parent, subsidiary, or affiliate (under both the BRs
> and EVGL) would again be sufficient to let a customer obtain a certificate
> for its domain, and (2) ensure the corrected rule applies to all classes of
> server certs – EV, OV, and DV.  Ballot 120 is not intended to change prior
> approved practices for domain confirmation.
>
>
>
> *---MOTION BEGINS---*
>
>
>
> The Baseline Requirements would be amended as follows:
>
>
>
> *(1)  MOVE definitions *for “Control”, “Country”, “Parent Company,”
> “Sovereign State,” and “Subsidiary Company” from the EV Guidelines to the
> Baseline Requirements, and
>
>
>
> *DELETE the following definitions from the EV Guidelines  as redundant*
> (because the definitions already exist or will exist in the Baseline
> Requirements):
>
>
>
> “Control”, “Country”, “Government Entity,” “Parent Company,” “Sovereign
> State,” and “Subsidiary Company” ;
>
>
>
> *(2) Amend BR 11.1.1 to read as follows:*
>
>
>
> *BR 11.1.1 Authorization by Domain Name Registrant*
>
>
>
> For each Fully-Qualified Domain Name listed in a Certificate, the CA SHALL
> confirm that, as of the date the Certificate was issued, the Applicant *(or
> the Applicant’s Parent Company, Subsidiary Company, or Affiliate,
> collectively referred to as “Applicant” for the purposes of this section)* either
> is the Domain Name Registrant or has control over the FQDN by:
>
>
>
> 1. Confirming the Applicant as the Domain Name Registrant directly with
> the Domain Name Registrar;
>
>
>
> 2. Communicating directly with the Domain Name Registrant using an
> address, email, or telephone number provided by the Domain Name Registrar;
>
>
>
> 3. Communicating directly with the Domain Name Registrant using the
> contact information listed in the WHOIS record’s “registrant”, “technical”,
> or “administrative” field;
>
>
>
> 4. Communicating with the Domain’s administrator using an email address
> created by pre-pending ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’,
> or ‘postmaster’ in the local part, followed by the at-sign (“@”), followed
> by the Domain Name, which may be formed by pruning zero or more components
> from the requested FQDN;
>
>
>
> 5. Relying upon a Domain Authorization Document;
>
>
>
> 6. Having the Applicant demonstrate practical control over the FQDN by
> making an agreed-upon change to information found on an online Web page
> identified by a uniform resource identifier containing the FQDN; or
>
>
>
> 7. Using any other method of confirmation, provided that the CA maintains
> documented evidence that the method of confirmation establishes that the
> Applicant is the Domain Name Registrant or has control over the FQDN to at
> least the same level of assurance as those methods previously described.
> ***
>
>
>
>
>
> *(3) Amend EVGL 11.6.1(1) to read as follows:*
>
>
>
> *EVGL  11.6.1  Verification Requirements *
>
>
>
> (1) For each Fully-Qualified Domain Name listed in a Certificate, the CA
> SHALL confirm that, as of the date the Certificate was issued, the
> Applicant *(or the Applicant’s Parent Company, Subsidiary Company, or
> Affiliate, collectively referred to as “Applicant” for the purposes of this
> section)* either is the Domain Name Registrant or has control over the
> FQDN using a procedure specified in Section 11.1.1 of the Baseline
> Requirements, except that a CA MAY NOT verify a domain using the procedure
> described 11.1.1(7). ***
>
> *---MOTION ENDS---*
>
>
>
> The review period for this ballot shall commence at 2200 UTC on Thursday,
> May 22, 2014, and will close at 2200 UTC on Thursday, May 29, 2014.
>
> Unless the motion is withdrawn during the review period, the voting period
> will start immediately thereafter and will close at 2200 UTC on Thursday,
> June 5, 2014. Votes must be cast by posting an on-list reply to this
> thread.
>
> A vote in favor of the motion must indicate a clear 'yes' in the response.
>
> A vote against must indicate a clear 'no' in the response.
>
> A vote to abstain must indicate a clear 'abstain' in the response. Unclear
> responses will not be counted.
>
> The latest vote received from any representative of a voting member before
> the close of the voting period will be counted.
>
> Voting members are listed here: https://cabforum.org/members/
>
> In order for the motion to be adopted, two thirds or more of the votes
> cast by members in the CA category and more than one half of the votes cast
> by members in the browser category must be in favor. Quorum is currently
> six (6) members– at least six members must participate in the ballot,
> either by voting in favor, voting against, or by abstaining for the vote to
> be valid.
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Public mailing listPublic at cabforum.orghttps://cabforum.org/mailman/listinfo/public
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>


-- 
Mert Özarar
mert.ozarar at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140604/b7c077ef/attachment-0003.html>