[cabfpub] Ballot 89 Rewrite

Rick Andrews Rick_Andrews at symantec.com
Mon Aug 26 22:47:18 UTC 2013


I have incorporated Ben's changes to the document, and to the wiki page at https://www.cabforum.org/wiki/89%20-%20Adopt%20Guidelines%20for%20the%20Processing%20of%20EV%20SSL%20Certificates%20v.2.

I believe Ben Wilson from Digicert and Kirk Hall from Trend Micro expressed interest in endorsing.

I'll wait a few days for comment before sending out a formal ballot email with dates.

-Rick

From: Ben Wilson [mailto:ben at digicert.com]
Sent: Friday, August 16, 2013 10:26 AM
To: Rick Andrews; public at cabforum.org
Subject: RE: [cabfpub] Ballot 89 Rewrite

Rick,
Before this ballot goes to review and vote, I think we will get more browsers to vote in favor of it if we make some of the changes outlined in the following comments table (which references the version I sent out the other day).
Thanks,
Ben

Pg.

Line

Sec.

Comment

Suggestion to Remedy

3

2

1

I am wondering whether Browser members of the CABF will be more inclined to vote in favor of posting this document if we removed the word "established"?  The word "established" seems to be too strong for browsers to accept.

Rephrase this to read, "This document contains recommendations by members of the CA/Browser Forum ..."











3

14-15

2

I am also wondering whether the Browsers would prefer that we replace "rely on" with the phrase "create software products that process"?  ("Rely" might carry legal/PKI interpretations.)

Rephrase the sentence to read, "This document contains recommendations for Application Software Suppliers who create software products that process Extended Validation certificates."











4

17-18

6.1

Browser members might want to remove the word "shall" here.  What if we replaced the phrase "An Application Software Supplier shall recognize a CSP that is qualified to issue EV SSL" with the phrase "An Application Software Supplier shall determine whether a CSP is qualified to issue EV SSL"?  The "shall recognize" seems to be too much of a mandate, even though the rest of the document implies that these are recommendations.

Rephrase the sentence to read, "An Application Software Supplier shall determine whether a CSP is qualified to issue EV SSL certificates by means of the CSP's audit report."











4

20

6.1

The phrase "an acceptable audit program" is too vague.  We have audit requirements in the EV Guidelines which should be referenced.

Rephrase the sentence to read, "The Application Software Supplier should check that the report was issued by an auditor certified to conduct audits in accordance with an audit program specified in [EVSSL]."











5

10-11

7.1

The sentence "The notice should include the terms upon which such CSPs will be included, as described in Sections 7.2 through 7.6 below." seems to be too prescriptive.  I am wondering whether it would be better if we made it clear that the list in section 7 is a guide and not a requirement?

Rephrase the sentence to read, "The notice should include the terms upon which such CSPs will be included, such as those described in Sections 7.2 through 7.6 below, as appropriate."











5

11-12

7.1

At first I was confused by the sentence, "It need not be performed for each new CSP or root certificate that the Application Software Supplier intends to add." I think it would benefit from a clearer statement about what it intends to say-i.e. we do not want email every time a browser adds a new root or  CA.

Rephrase the sentence to read, "This requested notice to the CA/Browser Forum is not necessary for subsequent CSPs or root certificates that the Application Software Supplier intends to add."











5

20, 28, 39

7.3, 7.4, 7.5

I do not feel too strongly about this, but since we're talking about both the notice to the CABF and the agreement in section 7, we should change the first sentence of these sections -- "The notice and/or the agreement..."

Add "notice and/or the" to the first sentence of sections 7.3, 7.4, and 7.5.











7

16

13

Browsers have been opposed to exhausting all available validation sources.  So the phrase "try all available alternative services" should be edited.  One possible solution is to say, "it should try an alternative service for certificate status information, if available."

Revise sentence to read, "If the application cannot obtain a response using one service, then it should try an alternative service for certificate status information, if available."











8

17-18

16

Finally, I think we need to replace the final sentence of the document.  It currently reads, "This document lays
out appropriate requirements on the relying application."  To the left is one suggestion.

"Because EV Certificates play an important role in securing the online ecosystem, we provide these recommendations to application developers to help them protect users when visiting EV-protected websites."



From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Rick Andrews
Sent: Tuesday, August 13, 2013 4:23 PM
To: public at cabforum.org
Subject: [cabfpub] Ballot 89 Rewrite

I am withdrawing the current Ballot 89 language and replacing it as outlined below.  A while back, I volunteered to update the Guidance to Application Developers (version 1, dated 2009, at https://www.cabforum.org/Guidelines_for_the_processing_of_EV_certificates%20v1_0.pdf). Based on comments received, edits were made to both the guideline document and the ballot.  However, more recently I began to understand that none of the browser vendors were supportive of my changes.  Of particular note, I received objections to some provisions in version 2, but then I saw that the same language currently exists in the 2009 version on the CABF website (i.e., that a browser should drop EV treatment for certificates that don't meet crypto requirements (Section 10) and that browsers should adjust their Root Embedding Programs accordingly (Section 7)).  So my conclusion is that browser vendors might not be supportive of version 1 either.  However, as a final effort, I have edited the document again and renamed it to:  "Recommendations for the Processing of EV SSL Certificates."  You can view changes from version 1 in the attached documents.

Therefore, I am proposing that Ballot 89 go forward as follows, if I can get two endorsers:

Ballot 93 - Reasons for Revocation (BR issues 6, 8, 10, 21)

Rick Andrews (Symantec) made the following motion, endorsed by ? and ?:

--- Motion begins ---

A "YES" vote on Ballot 89 means that the member votes to remove the 2009 Version 1.0 of "GUIDELINES for the PROCESSING of EXTENDED VALIDATION CERTIFICATES" from the public CA Browser Forum website and replace it with the attached "RECOMMENDATIONS for the PROCESSING of EXTENDED VALIDATION CERTIFICATES".

A "NO" vote on the ballot means that the member votes to remove the 2009 Version 1.0 of "GUIDELINES for the PROCESSING of EXTENDED VALIDATION CERTIFICATES" on the public CA Browser Forum website and not replace it.

... Motion ends ...

-Rick


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130826/f8df6a96/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Recommendations for the processing of EV SSL	certificates.pdf
Type: application/pdf
Size: 326663 bytes
Desc: Recommendations for the processing of EV SSL	certificates.pdf
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130826/f8df6a96/attachment-0003.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Recommendations for the processing of EV SSL	certificates.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 44394 bytes
Desc: Recommendations for the processing of EV SSL	certificates.docx
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130826/f8df6a96/attachment-0001.docx>


More information about the Public mailing list