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 <doug.beat...@globalsign.com> 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: public-boun...@cabforum.org [mailto:public-boun...@cabforum.org] 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: public-boun...@cabforum.org [mailto:public-boun...@cabforum.org] On 
> Behalf Of Erwann Abalea
> Sent: Monday, September 19, 2016 7:05 AM
> To: Robin Alden <ro...@comodo.com>; CABFPub <public@cabforum.org>
> 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 <ro...@comodo.com> 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
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>  
> _______________________________________________
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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

Reply via email to