[cabf_validation] Ballot 169 Clarifications

[Steve Medin]

I also support the ballot, however I propose that we consider endorsement
from one CA and one browser.



Wayne, your auditors have indicated they would accept consensus. I’d like
to ensure that for clarity we allow this ballot to proceed to a vote even if
we see consensus.



From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Bruce
Morton via Validation
Sent: Thursday, December 15, 2016 2:35 PM
To: CA/Browser Forum Validation WG List <validation at cabforum.org>
Cc: Bruce Morton <Bruce.Morton at entrustdatacard.com>
Subject: Re: [cabf_validation] Ballot 169 Clarifications



I support this proposed ballot.



I also think this approach was intended when ballot 169 was developed.



Thanks, Bruce.



From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Wayne
Thayer via Validation
Sent: Thursday, December 15, 2016 11:54 AM
To: CA/Browser Forum Validation WG List <validation at cabforum.org
<mailto:validation at cabforum.org> >
Cc: Wayne Thayer <wthayer at godaddy.com <mailto:wthayer at godaddy.com> >
Subject: [cabf_validation] FW: Ballot 169 Clarifications



Resending.



From: Wayne Thayer
Sent: Friday, December 2, 2016 10:55 AM
To: 'CA/Browser Forum Validation WG List' <validation at cabforum.org
<mailto:validation at cabforum.org> >
Subject: Ballot 169 Clarifications



On yesterday’s call we discussed the need to clarify the effect that ballot
169 has on the reuse of domain validation data gathered from methods no
longer permitted under 169. After digging into this I also found a few other
bugs that we’ve discussed fixing. Here’s a ballot proposal:



Ballot ### - Reuse of Domain Validation Data



Ballot 169 introduced significant changes to the domain validation processes
defined in section 3.2.1 of the Baseline Requirements. The intent of the
Validation Working Group was not for these changes to be retroactive, but
the ballot failed to specify the effect these changes have on the data reuse
policy defined in section 4.2.1. Ballot ### clarifies the original intent of
the working group. It also corrects a reference in section 3.2.2.4 and
removes the “any other method” exception from the EVGLs as originally
intended.



The following motion has been proposed by XXX and endorsed by YYY and ZZZ as
a Final Maintenance Guideline:



-- MOTION BEGINS -



Effective immediately, the follow changes are made to the Baseline
Requirements:



Modify section 3.2.2.4 as follows:



This section defines the permitted processes and procedures for validating
the Applicant's ownership or

control of the domain.



The CA SHALL confirm that, as of the date the Certificate issues, either the
CA or a Delegated Third Party has

validated each Fully‐Qualified Domain Name (FQDN) listed in the Certificate
using at least one of the methods

listed below.



Completed confirmations of Applicant authority may be valid for the issuance
of multiple certificates over

time. In all cases, the confirmation must have been initiated within the
time period specified in the relevant

requirement (such as Section 4.2.1 of this document) prior to certificate
issuance. For purposes of domain

validation, the term Applicant includes the Applicant's Parent Company,
Subsidiary Company, or Affiliate.



Note: FQDNs may be listed in Subscriber Certificates using dNSNames in the
subjectAltName extension or in

Subordinate CA Certificates via dNSNames in permittedSubtrees within the
Name Constraints extension.



Note: Data collected by the CA prior to the effective date of Ballot 169 may
continue to be used for validation of domain authorization or control
subject to the limits described in section 4.2.1.



Effective immediately, the follow changes are made to the Guidelines For The
Issuance And Management Of

Extended Validation Certificates:



Modify section 11.7.1(1) as follows:



For each Fully-Qualified Domain Name listed in a Certificate, other than a
Domain Name with .onion in the right-most

label of the Domain Name, 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 3.2.2.4 of the Baseline Requirements, except that a CA MAY NOT
verify a domain using the procedure

described subsection 3.2.2.4(7). For a Certificate issued to a Domain Name
with .onion in the right-most label of the

Domain Name, the CA SHALL confirm that, as of the date the Certificate was
issued, the Applicant’s control over the

.onion Domain Name in accordance with Appendix F.



Note: Data collected by the CA prior to the effective date of Ballot 169 may
continue to be used for validation of domain authorization or control
subject to the limits described in section 11.14.



-- MOTION ENDS -

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20161216/8660c1de/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5744 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20161216/8660c1de/attachment-0001.bin>