[cabfpub] [cabfman] Ballot [93] - Reasons for Revocation (BR issues 6, 8, 10, 21)
Ben Laurie
benl at google.com
Mon Oct 29 10:07:18 UTC 2012
On 26 October 2012 22:15, Rick Andrews <Rick_Andrews at symantec.com> wrote:
> I just realized that Robin's revision seems incorrect. Yngve intended that 3 would be treated as a valid exponent (I believe that's what he intended), but 3 is not in the range below.
You realise exponents have to be coprime with phi(n), right? So,
merely "odd" is far from sufficient.
>
> -Rick
>
>> -----Original Message-----
>> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
>> On Behalf Of Robin Alden
>> Sent: Friday, October 26, 2012 3:09 AM
>> To: 'Yngve N. Pettersen (Developer Opera Software ASA)'; 'CABFMAN';
>> 'Ben Wilson'
>> Cc: public at cabforum.org
>> Subject: Re: [cabfpub] Ballot [93] - Reasons for Revocation (BR issues
>> 6, 8, 10, 21)
>>
>> Comodo votes 'yes' based on Yngve's clarification that the effective
>> date would be "Immediate" and that for the RSA public exponent there
>> was a typo and that part of the motion should read, "The value of the
>> public exponent MUST be an odd number equal to 3 or more, it SHOULD be
>> in the range between
>> 65,537 (= (2^16)+1) and (2^256)-1."
>>
>> > -----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: 25 October 2012 16:33
>> > To: CABFMAN; Ben Wilson
>> > Cc: public at cabforum.org
>> > Subject: Re: [cabfpub] Ballot [93] - Reasons for Revocation (BR
>> issues
>> 6,
>> > 8, 10, 21)
>> >
>> >
>> > Opera Software votes Yes.
>> >
>> > On Thu, 18 Oct 2012 01:16:36 +0200, Ben Wilson <ben at digicert.com>
>> > wrote:
>> >
>> > > 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 <DTBD>
>> > >
>> > > 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
>> > > <http://csrc.nist.gov/publications/nistpubs/800-78-3/sp800-78-
>> > 3.pdf%3E
>> > > > >
>> > >
>> > > 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."
>> > >
>> > > 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
> _______________________________________________
> Management mailing list
> Management at cabforum.org
> https://cabforum.org/mailman/listinfo/management
More information about the Public
mailing list