I agree with this approach. Option 7 was the "any other method". Now that the validation methods are a finite list, we need to amend the ev guidelines to remove the old restriction as no longer relevant.
> On Sep 21, 2016, at 4:59 PM, Doug Beattie <[email protected]> wrote: > > > As discussed below, the list of support domain validation methods for EV > issuance is confused, and actually wrong. It says any method in section > 3.2.2.4 can be used except 3.2.2.4(7), which means methods 8, 9, and 10 ARE > currently valid options (well, not 8 because EV does not support IP > addresses). In summary, the way the BRs and EVGLs are written: > - Options 1-6, 8-10 are allowed for EV issuance > - Option 7 (DNS) is NOT permitted > > This was not the intent – the intent was all methods in 3.2.2.4 should be > supported for EV, but this was not discussed nor was any security analysis > performed to determine if these posed any risks for EV issuance. > > I agree with Kirk’s recommendation on the change: > > EVGL 11.7.1(1) For each Fully-Qualified Domain Name listed in a Certificate, > other than a Domain Name with .onion in the rightmost 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. > > I’m being asked for guidance within the company and I’m sure other CAs are in > the same situation. > > Does anyone have a concern with this approach as a pre-pre ballot? If not, > the Validation working group can put forth a ballot. > > Doug > > > From: [email protected] [mailto:[email protected]] On > Behalf Of Kirk Hall > Sent: Monday, September 19, 2016 8:18 PM > To: CABFPub > Subject: Re: [cabfpub] Ballot 169 problem report > > Erwann, you are correct that we need to change EVGL 11.7.1, and at different > times the Validation Working Group discussed that. But it never made it into > Ballot 169. > > The intention was that after we removed the “any other method” of old BR > 3.2.2.4 (which we did by Ballot 169), then all of the domain validation > methods could be used for EV certificates, including methods (7) through > (10). So I think the better correction of EVGL 11.7.1(1) would be simply to > remove the words “***, except that a CA MAY NOT verify a domain using the > procedure described subsection 3.2.2.4(7)”. We may need to make other > modifications as well. I think this issue should go back to the (revived) > Validation Working Group. > > Here is how the amended EVGL 11.7.1(1) would read: > > EVGL 11.7.1(1) For each Fully-Qualified Domain Name listed in a Certificate, > other than a Domain Name with .onion in the rightmost 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. > > From: [email protected] [mailto:[email protected]] On > Behalf Of Erwann Abalea > Sent: Monday, September 19, 2016 7:05 AM > To: Robin Alden <[email protected]>; CABFPub <[email protected]> > Subject: Re: [cabfpub] Ballot 169 problem report > > Bonjour, > > The modification of section 3.2.2.4 has consequences on EVG section 11.7.1. > EVG section 11.7.1 says: > (1) […] 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). […] > > Due to this rewriting of BR 3.2.2.4, I guess this Section 11.7.1 of EVG > should be changed to: > « […] a CA MAY NOT verify a domain using the procedures described subsection > 3.2.2.4.7, 3.2.2.4.8, 3.2.2.4.9, and 3.2.2.4.10. » > > Cordialement, > Erwann Abalea > > Le 7 sept. 2016 à 15:37, Robin Alden <[email protected]> a écrit : > > Ballot 169 – “Revised Validation Requirements” introduced text into section > 3.2.2.4 which refers to section 3.3.1. > > “3.2.2.4 > … > 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 3.3.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. > …“ > > Section 3.3.1 of the BRs now consists only of the section heading, with no > body text. > “3.3.1. Identification and Authentication for Routine Re‐key” > > The text which was at 3.3.1 in the guidelines when we started working on what > became ballot 169 read: > Section 6.3.2 limits the validity period of Subscriber Certificates. The CA > MAY use the documents and data > provided in Section 3.2 to verify certificate information, provided that the > CA obtained the data or document > from a source specified under Section 3.2 no more than thirty‐nine (39) > months prior to issuing the > Certificate. > (taken from version 1.3.0 of the BRs) > > That text now appears as the third paragraph of 4.2.1 (Performing > Identification and Authentication Functions) > > Should we move that text back into 3.3.1, or should we change 3.2.2.4 so that > the reference points to 4.2.1 instead of pointing to 3.3.1? > > Regards > Robin Alden > Comodo > > _______________________________________________ > Public mailing list > [email protected] > https://cabforum.org/mailman/listinfo/public > > _______________________________________________ > Public mailing list > [email protected] > https://cabforum.org/mailman/listinfo/public
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
