[cabfpub] [cabfman] Ballot [93] - Reasons for Revocation (BR issues 6, 8, 1public at cabforum.org0, 21)

kirk_hall at trendmicro.com kirk_hall at trendmicro.com
Sat Nov 3 23:46:40 UTC 2012


A short response.

1.  You should not count a member as "abstaining" (important for the proponents of a ballot to get to a quorum, which regrettably is only six members right now, and does not require any votes from any browsers).  If someone says "I don't plan to vote", that's not the same as formally abstaining, and you should not count such a statement as an abstention for quorum purposes.  That's not fair.  Abstentions should not count for quorum purposes anyway - only people who vote yes or no should be counted.

2.  If a simple typographical error is corrected in a ballot, it should not delay the schedule of 7 days discussion, 7 days to vote.  However, if the ballot is substantively changed by the proponents after extensive technical discussion, then the 7 day review/7 day voting period should start again.  There is no emergency here -- and no one who asks for a new 7 days to consider new text is "filibustering", as the message says below.  That's offensive, Ben.

3.  Some of us feel there is an effort by some members to push things through the Forum, without consideration of how other members feel.  A little more fairness to all members would be appreciated. 

-----Original Message-----
From: management-bounces at cabforum.org [mailto:management-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Saturday, November 03, 2012 1:49 PM
To: 'CABFMAN'; public at cabforum.org
Subject: Re: [cabfman] [cabfpub] Ballot [93] - Reasons for Revocation (BR issues 6, 8, 10, 21)

Members,

Voting does not close until Wednesday afternoon, so there is plenty of time to review, understand, and decide on this ballot.  Members should vote
"yes/yea" - "no/nay" - "abstain/abstention".   A statement such as "we will
not vote" should also count as an abstention, which is defined as "refraining from casting one's vote." 

As noted by Yngve, the minor, recent revisions were aimed to address late-made comments.  Members should refrain from making such comments unless they have been raised prior to the commencement of voting or unless the commenter provides a constructive solution to a concern that is accepted by the proponents of the ballot.  Current CAB Forum processes usually allow ample time to raise issues during telephone conference calls, face-to-face meetings, and during the review period.  It is generally inappropriate to raise complaints or concerns about a ballot on the last day of voting when no time remains to remedy any perceived or newly announced problem.  In the referenced ballot, this occurred and, if it had not been remedied as it currently stands, would have resulted in a clear and unintentional abuse of
the procedural rules, as innocent as the comments might have been.   The
ballot was amended as a favorable response to the criticism made, which I think is better than a call for censure because of last-minute criticisms.  

Just to recap the history of this ballot-- these issues were identified and reported by Yngve on 22-Sept-2011, as noted in section 7.2 of the minutes from that day.  They were recorded as issues 6, 8, 10 and 21 on the issues list.  On 2-Feb-2012 he provided draft language to address his items on the issues list.  On 17-Apr-2012 he announced that he posted additional revisions to the items on this issues list.  On 20-June-2012, he sent a draft of the ballot to the list asking for two endorsers.  At the F2F meeting in Gjøvik on 26-June-2012 he reiterated his request for endorsers.
On 12-July-2012 in connection with our regular BR issues review during or regular teleconference, he re-edited the proposed ballot, placed it on the wiki, and again solicited endorsers.  And on 26-Sept-2012 during the NYC F2F, we reviewed these BR issues during our meeting, and additional improvements to the ballot were made.  Of course, there has also been further discussion on Part E of this ballot more recently--but there has still been ample opportunity for constructive criticism--members are encouraged to provide constructive improvements to ballot language, rather than send proponents off to re-work their proposals.  

All of this being said, I think that a rule that all amended ballots should start again would be inappropriate (this ballot as a case-in-point) given that a mish-mash of piecemeal commenting strategies, criticisms without solutions, and other means of filibustering will likely delay/prevent votes and hamper the effectiveness of the Forum.  Finally, I'd like to remind members to take full advantage of the review period by reviewing the language and to be courteous to ballot proponents by providing them with constructive comments at the earliest opportunity possible.

Sincerely,

Ben

-----Original Message-----
From: management-bounces at cabforum.org
[mailto:management-bounces at cabforum.org] On Behalf Of Yngve N. Pettersen (Developer Opera Software ASA)
Sent: Saturday, November 03, 2012 4:01 AM
To: ben at digicert.com; 'Mads Egil Henriksveen'; 'Rick Andrews'; kirk_hall at trendmicro.com
Cc: 'CABFMAN'; public at cabforum.org
Subject: Re: [cabfman] [cabfpub] Ballot [93] - Reasons for Revocation (BR issues 6, 8, 10, 21)

Kirk,

Compared to the text that was originally posted, the only changes are to the new Appendix A (4) and an additional reference (original point E), replacement text below (aka redline), and clearing up that the rest of the changes take effect immediately (which was posted before the original voting period started). The rest of the ballot text is the same as before.

The fundamental problem this time, and with Ballot 92, is that the real "discussion period" started a week too late for both ballots.

In this ballot, the actual problematic part was very limited, specifically to the inclusion by reference of the entire NIST document. That could be resolved with the changes suggested below by Ben.

As the problem area was so, specific we decided to extend the ballot, allowing a couple of days discussion period past the 13 days already used, to update the text.


On Sat, 03 Nov 2012 05:54:19 +0100, kirk_hall at trendmicro.com <kirk_hall at trendmicro.com> wrote:

> Ben and Yngve -- it would have been much better if you had "withdrawn"  
> the previous Ballot 93, and started again with a reposted Ballot 93 
> showing changes from the prior ballot, allowing 7 more days to review 
> and 7 days to vote.
>
> I am so confused by what's in Ballot 93 that we will sit this one out 
> and not vote.
>
> In the future, all ballots that are amended should start again.
>
> -----Original Message-----
> From: management-bounces at cabforum.org 
> [mailto:management-bounces at cabforum.org] On Behalf Of Ben Wilson
> Sent: Thursday, November 01, 2012 11:26 PM
> To: 'Mads Egil Henriksveen'; 'Rick Andrews'; 'Yngve N. Pettersen 
> (Developer Opera Software ASA)'
> Cc: 'CABFMAN'; public at cabforum.org
> Subject: Re: [cabfman] [cabfpub] Ballot [93] - Reasons for Revocation 
> (BR issues 6, 8, 10, 21)
>
> What if Part E of Ballot 93 read,
>
> 1.  Add the following to Section 3. References
>
> "NIST SP 800-89, Recommendation for Obtaining Assurances for Digital 
> Signature Applications,
> http://csrc.nist.gov/publications/nistpubs/800-89/SP-800-89_November20
> 06.pdf
> "
>
> 2.  Add the following after Appendix A, table (3):
>
> "(4) 	General requirements for public keys (Effective 1 January 2013)
> RSA: The CA SHALL confirm that the value of the public exponent is an 
> odd number equal to 3 or more.  Additionally, the public exponent 
> SHOULD be in the range between 2^16+1 and 2^256-1.  The modulus SHOULD 
> also have the following characteristics:  an odd number, not the power 
> of a prime, and
> have no factors smaller than 752.    [Source:  Section 5.3.3, NIST SP
> 800-89]."
> ?
>
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Mads Egil Henriksveen
> Sent: Wednesday, October 31, 2012 12:33 PM
> To: Rick Andrews; Yngve N. Pettersen (Developer Opera Software ASA)
> Cc: CABFMAN; public at cabforum.org
> Subject: Re: [cabfpub] [cabfman] Ballot [93] - Reasons for Revocation 
> (BR issues 6, 8, 10, 21)
>
> Hi
>
> I do agree with Rick.
>
> And it is not clear to me which parts of the NIST document we must 
> consider.
> If it's only the public key recommendations in chapter 3.1, i.e. table
> 3.2 and the paragraph before, why not just include this in the BR 
> (isn't this already included for RSA) and remove the reference to the 
> NIST document?
>
> The rest of this twenty-page document is mostly out-of-scope.
>
> Regards
> Mads
>
> -----Original Message-----
> From: management-bounces at cabforum.org
> [mailto:management-bounces at cabforum.org] On Behalf Of Rick Andrews
> Sent: 31. oktober 2012 19:10
> To: Yngve N. Pettersen (Developer Opera Software ASA)
> Cc: CABFMAN; public at cabforum.org
> Subject: Re: [cabfman] [cabfpub] Ballot [93] - Reasons for Revocation 
> (BR issues 6, 8, 10, 21)
>
>> -----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 8:53 AM
>> To: Rick Andrews
>> Cc: CABFMAN; public at cabforum.org
>> Subject: Re: [cabfpub] [cabfman] Ballot [93] - Reasons for Revocation 
>> (BR issues 6, 8, 10, 21)
>>
>> On Wed, 31 Oct 2012 16:31:35 +0100, Rick Andrews 
>> <Rick_Andrews at symantec.com> wrote:
>>
>> > Ben and Yngve,
>> >
>> > Thanks for the clarifications. I understand then that CAs can check
>> for
>> > coprime with phi(n) only for their own roots and intermediates, not
>> for
>> > end entity certs. But this ballot will require all CAs to check 
>> > that
>> the
>> > exponent is odd and within that range for all end entity certs, 
>> > effective immediately.
>>
>> Which is essentially the current requirements in the referenced NIST 
>> document.
>
> Yngve, just for the record, that NIST document establishes 
> requirements for Personal Identity Verification (PIV) for US 
> Government
agencies.
> It's a recommendation for everyone else, and does not explicitly 
> mention SSL or TLS. I agree that its recommendations make sense for 
> SSL certs too, but let's be clear that it does not impose any 
> requirements on CAs who sell SSL certs, especially non-US CAs.
>
> -Rick
> _______________________________________________
> Management mailing list
> Management at cabforum.org
> https://cabforum.org/mailman/listinfo/management
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
> _______________________________________________
> Management mailing list
> Management at cabforum.org
> https://cabforum.org/mailman/listinfo/management
> <table class="TM_EMAIL_NOTICE"><tr><td><pre>
> TREND MICRO EMAIL NOTICE
> The information contained in this email and any attachments is 
> confidential and may be subject to copyright or other intellectual 
> property protection.
> If you are not the intended recipient, you are not authorized to use 
> or disclose this information, and we request that you notify us by 
> reply mail or telephone and delete the original message from your mail 
> system.
> </pre></td></tr></table>


--
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
********************************************************************
_______________________________________________
Management mailing list
Management at cabforum.org
https://cabforum.org/mailman/listinfo/management

_______________________________________________
Management mailing list
Management at cabforum.org
https://cabforum.org/mailman/listinfo/management
<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>




More information about the Public mailing list