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

Wed Oct 31 04:54:09 MST 2012

On 31 October 2012 11:14, Ben Laurie <benl at google.com> wrote:
> On 31 October 2012 00:02, Rick Andrews <Rick_Andrews at symantec.com> wrote:
>> CAB Forum,
>>
>> Two questions about this ballot:
>>
>> 1) Does this clause about exponent checking apply to end-entity certificates, intermediate certificates, or both? The ballot is unclear.
>>
>> 2) I'll be honest and admit that I don't know what Ben means about coprime with phi(n). That's not in the ballot so I presume the ballot does not intend for CAs to check for that. Is that everyone else's expectation?
>
> Just FYI, your RSA modulus n = pq, where p and q are prime. phi(n) =
> (p-1)(q-1). It is a requirement of the RSA algorithm that the exponent
> is coprime with this. A consequence is that the exponent must be odd,
> but its a little strange requiring a check for oddness instead of the
> actual required property. Or, to put it another way, there are odd
> exponents that are not correct for RSA.

Yngve pointed out to me that whilst this is true, CAs don't know p and
q and hence cannot check this condition (except for their own
certificates). Apologies for the interruption.

>
>>
>> -Rick
>>
>>> -----Original Message-----
>>> From: Ben Laurie [mailto:benl at google.com]
>>> Sent: Monday, October 29, 2012 3:07 AM
>>> To: Rick Andrews
>>> Cc: Robin Alden; Yngve N. Pettersen (Developer Opera Software ASA);
>>> CABFMAN; Ben Wilson; public at cabforum.org
>>> Subject: Re: [cabfman] [cabfpub] Ballot [93] - Reasons for Revocation
>>> (BR issues 6, 8, 10, 21)
>>>
>>> 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