[cabfpub] [cabfman] Ballot [93] - Reasons for Revocation (BR issues 6, 8, 10, 21)

Wed Oct 31 17:58:07 UTC 2012

I'll endorse the motion.  Robin is on vacation but has endorsed it as well.

Jeremy 

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Ben Wilson
Sent: Wednesday, October 31, 2012 11:51 AM
To: 'Yngve N. Pettersen (Developer Opera Software ASA)'; 'CABFMAN';
public at cabforum.org
Subject: Re: [cabfpub] [cabfman] Ballot [93] - Reasons for Revocation (BR
issues 6, 8, 10, 21)

Here is a revised PDF of page 32.  We're just awaiting for the endorsers and
prior voters to assent to this clarification.

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Yngve N. Pettersen (Developer Opera Software ASA)
Sent: Wednesday, October 31, 2012 11:32 AM
To: 'CABFMAN'; public at cabforum.org; Ben Wilson
Subject: Re: [cabfpub] [cabfman] Ballot [93] - Reasons for Revocation (BR
issues 6, 8, 10, 21)

Given the current discussion about the Appendix A part of the ballot, what
do people think about adding "Effective Jan. 1, 2013" for ballot point E
(Appending A, point 4, issue 10)?

Could endorsers please re-endorse if this OK?

(Maybe we should have had this discussion last week?)

On Tue, 30 Oct 2012 22:21:15 +0100, Ben Wilson <ben at digicert.com> wrote:

> Reminder:  Ballot 93 closes in less than 24 hours.  So far I believe 
> that DigiCert, Comodo, Izenpe, and Opera have voted yes.  Attached is 
> an updated redline and below is the current ballot text:
>
> Ballot 93 - Reasons for Revocation (BR issues 6, 8, 10, 21)
>
> Yngve N. Pettersen (Opera) made the following motion, endorsed by 
> Jeremy Rowley, Digicert and Robin Alden, Comodo:
>
> --- Motion begins ---
>
> Effective immediately
>
> Erratum begins:
>
> A. (Issue #8)
> Add the following as 10.2.5:
> "10.2.5 Subordinate CA Private Key
> 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."
>
> B. (Issue #8)
> . Replace the heading of section 13.1.5 with "Reasons for Revoking a 
> Subscriber Certificate"
> . Add the following as section 13.1.6:
> "13.1.6 Reasons for Revoking a Subordinate CA Certificate The Issuing 
> CA SHALL revoke a Subordinate CA Certificate within seven (7) days if 
> one or more of the following occurs:
> 1. The Subordinate CA requests revocation in writing; 2. The 
> Subordinate CA notifies the Issuing CA that the original certificate 
> request was not authorized and does not retroactively grant 
> authorization; 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, 4. The Issuing CA obtains evidence that the Certificate 
> was misused; 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; 6. The Issuing CA determines that 
> any of the information appearing in the Certificate is inaccurate or 
> misleading; 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; 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; 9.
> Revocation is required by the Issuing CA's Certificate Policy and/or 
> Certification Practice Statement; or 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)."
>
> C. (Issue #6)
> .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,"
> .Add the following as a new Section 13.1.5(4) and renumber the 
> remaining bullet points:
> "(4) The CA obtains evidence that the Certificate was misused;"
> .Replace the definition of Key Compromise with the following:
> "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
> http://wiki.debian.org/SSLkeys)
> or if there is clear evidence that the specific method used to 
> generate the Private Key was flawed."
>
> D. (Issue #21)
> Add new section 13.2.7: "13.2.7 Certificate Suspension.
> The Repository MUST NOT include entries that indicate that a 
> Certificate is suspended."
>
> E. (Issue #10)
> Add the following after Appendix A, table (3):
> "(4) General requirements for public keys: Public keys SHOULD follow 
> the recommendations of NIST SP 800-73-3 
> <http://csrc.nist.gov/publications/nistpubs/800-78-3/sp800-78-3.pdf>
> RSA: The value of the public exponent MUST be an odd number equal to 3 
> or more, and it SHOULD be in the range between 65,537 (= (2^16)+1) and 
> (2^256)-1."
> Erratum ends
> ... Motion ends ...
> 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.
> ... Motions ends ...
> A vote in favor of the motion must indicate a clear 'yes' in the 
> response.
> 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.
> Voting members are listed here: http://www.cabforum.org/forum.html
> 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.

--
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: yngve at opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 96 90 41 51              Fax:    +47 23 69 24 01
********************************************************************
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public