<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.line867, li.line867, div.line867
{mso-style-name:line867;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.line874, li.line874, div.line874
{mso-style-name:line874;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.line862, li.line862, div.line862
{mso-style-name:line862;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='color:#1F497D'>I generally support this motion but have some issues with the way item E (Issue #10) is being handled.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>As this change may affect code, I am unhappy voting on it without having an effective date. Certainly the suggestion of “immediate” seems ambitious.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Moreover, I think it behooves us to provide a clear note why we are specifying the change, why the problem occurs, and how users can tell themselves if they have a problem. Most of the other requirements of Appendix A are “surface visible” – in other words, any user can see if a cert is 2048bit or SHA2. This one is not so easily pinned down – and it looks even more peculiar that we are referring to a single line of the PIV standard in our SSL requirement. <o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'> If the BR are to be widely implemented by CAs, sometimes we need to provide a little guidance both for users and implementers. For example, Brad’s notes on the deprecation of internal names have helped many CAs communicate consistently to clients why that change is being made.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Best, Stephen<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> management-bounces@cabforum.org [mailto:management-bounces@cabforum.org] <b>On Behalf Of </b>Ben Wilson<br><b>Sent:</b> Wednesday, October 17, 2012 8:17 PM<br><b>To:</b> CABFMAN<br><b>Cc:</b> public@cabforum.org<br><b>Subject:</b> [cabfman] Ballot [93] - Reasons for Revocation (BR issues 6, 8, 10, 21)<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=line867><strong>Ballot 93 - Reasons for Revocation (BR issues 6, 8, 10, 21)</strong> <o:p></o:p></p><p class=line874>Yngve N. Pettersen (Opera) made the following motion, endorsed by Jeremy Rowley, Digicert and Robin Alden, Comodo: <o:p></o:p></p><p class=line874>--- Motion begins --- <o:p></o:p></p><p class=line862>Effective <DTBD> <o:p></o:p></p><p class=line874>Erratum begins: <o:p></o:p></p><p class=line867><strong>A. (Issue #8)</strong> <o:p></o:p></p><p class=line874>Add the following as 10.2.5: <o:p></o:p></p><p class=line874>"10.2.5 Subordinate CA Private Key <o:p></o:p></p><p class=line874>Parties other than the Subordinate CA SHALL NOT archive the Subordinate CA Private Keys. If the Issuing CA generated the Private Key on behalf of the Subordinate CA, then the Issuing CA SHALL encrypt the Private Key for transport to the Subordinate CA. If the Issuing CA becomes aware that a Subordinate CA’s Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subordinate CA, then the Issuing CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key." <o:p></o:p></p><p class=line867><strong>B. (Issue #8)</strong> <o:p></o:p></p><p class=line874>• Replace the heading of section 13.1.5 with "Reasons for Revoking a Subscriber Certificate" <o:p></o:p></p><p class=line874>• Add the following as section 13.1.6: <o:p></o:p></p><p class=line874>"13.1.6 Reasons for Revoking a Subordinate CA Certificate <o:p></o:p></p><p class=line874>The Issuing CA SHALL revoke a Subordinate CA Certificate within seven (7) days if one or more of the following occurs: <o:p></o:p></p><p class=line874>1. The Subordinate CA requests revocation in writing; <o:p></o:p></p><p class=line874>2. The Subordinate CA notifies the Issuing CA that the original certificate request was not authorized and does not retroactively grant authorization; <o:p></o:p></p><p class=line874>3. The Issuing CA obtains evidence that the Subordinate CA’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise or no longer complies with the requirements of Appendix A, <o:p></o:p></p><p class=line874>4. The Issuing CA obtains evidence that the Certificate was misused; <o:p></o:p></p><p class=line874>5. The Issuing CA is made aware that the Certificate was not issued in accordance with or that Subordinate CA has not complied with these Baseline Requirements or the applicable Certificate Policy or Certification Practice Statement; <o:p></o:p></p><p class=line874>6. The Issuing CA determines that any of the information appearing in the Certificate is inaccurate or misleading; <o:p></o:p></p><p class=line874>7. The Issuing CA or Subordinate CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the Certificate; <o:p></o:p></p><p class=line874>8. The Issuing CA’s or Subordinate CA's right to issue Certificates under these Requirements expires or is revoked or terminated, unless the Issuing CA has made arrangements to continue maintaining the CRL/OCSP Repository; <o:p></o:p></p><p class=line874>9. Revocation is required by the Issuing CA’s Certificate Policy and/or Certification Practice Statement; or <o:p></o:p></p><p class=line874>10. The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time)." <o:p></o:p></p><p class=line867><strong>C. (Issue #6)</strong> <o:p></o:p></p><p class=line874>•Replace Section 13.1.5(3) with: "(3) The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise (also see Section 10.2.4) or no longer complies with the requirements of Appendix A," <o:p></o:p></p><p class=line874>•Add the following as a new Section 13.1.5(4) and renumber the remaining bullet points: <o:p></o:p></p><p class=line874>"(4) The CA obtains evidence that the Certificate was misused;" <o:p></o:p></p><p class=line874>•Replace the definition of Key Compromise with the following: <o:p></o:p></p><p class=line862>“Key Compromise: A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, an unauthorized person has had access to it, or there exists a practical technique by which an unauthorized person may discover its value. A Private Key is also considered compromised if methods have been developed that can easily calculate it based on the Public Key (such as a Debian weak key, see <a href="http://wiki.debian.org/SSLkeys">http://wiki.debian.org/SSLkeys</a>) or if there is clear evidence that the specific method used to generate the Private Key was flawed.” <o:p></o:p></p><p class=line867><strong>D. (Issue #21)</strong> <o:p></o:p></p><p class=line874>Add new section 13.2.7: "13.2.7 Certificate Suspension. <o:p></o:p></p><p class=line874>The Repository MUST NOT include entries that indicate that a Certificate is suspended." <o:p></o:p></p><p class=line867><strong>E. (Issue #10)</strong> <o:p></o:p></p><p class=line874>Add the following after Appendix A, table (3): <o:p></o:p></p><p class=line862>"(4) General requirements for public keys: Public keys SHOULD follow the recommendations of NIST SP 800-73-3 <<a href="http://csrc.nist.gov/publications/nistpubs/800-78-3/sp800-78-3.pdf%3E">http://csrc.nist.gov/publications/nistpubs/800-78-3/sp800-78-3.pdf></a> <o:p></o:p></p><p class=line874>RSA: The value of the public exponent MUST be an odd number equal to 3 or more, it SHOULD be in the range 65537 (216+1) to 2256-1." <o:p></o:p></p><p class=line874>Erratum ends <o:p></o:p></p><p class=line874>... Motion ends ... <o:p></o:p></p><p class=line874>The review period for this ballot shall commence at 21:00 UTC on 17 October 2012 and will close at 21:00 UTC on 24 October 2012. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 21:00 UTC on 31 October 2012. Votes must be cast by posting an on-list reply to this thread. <o:p></o:p></p><p class=line874>... Motions ends ... <o:p></o:p></p><p class=line874>A vote in favor of the motion must indicate a clear 'yes' in the response. <o:p></o:p></p><p class=line874>A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. <o:p></o:p></p><p class=line862>Voting members are listed here: <a href="http://www.cabforum.org/forum.html">http://www.cabforum.org/forum.html</a> <o:p></o:p></p><p class=line874>In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and one half or more of the votes cast by members in the browser category must be in favor. Also, at least six members must participate in the ballot, either by voting in favor, voting against or abstaining. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>