[cabfpub] Ballot 169 problem report

Wed Sep 21 15:16:15 UTC 2016

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.beattie at 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-bounces at cabforum.org [mailto:public-bounces at 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-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Erwann Abalea
> Sent: Monday, September 19, 2016 7:05 AM
> To: Robin Alden <robin at comodo.com>; CABFPub <public at 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 <robin at 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 at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>  
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160921/0b698852/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2241 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160921/0b698852/attachment-0001.p7s>