[cabfpub] [cabfman] Ballot [93] - Reasons for Revocation (BR issues 6, 8, 10, 21)
Ben Laurie
benl at google.com
Wed Oct 31 09:19:56 MST 2012
On 31 October 2012 15:53, Yngve N. Pettersen (Developer Opera Software
ASA) <yngve at opera.com> wrote:
> 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.
>
> The main point about this requirement is to detect some obvious mistakes
> (even number or 1) if the requester makes non-standard adjustments to their
> key generation system, and to point out that a small exponent (<2^16) is
> also a possible issue. As 2^16+1 seem to be the default in most key
> generators (my impression, I have not checked the TLS prober data) I doubt
> you will see too many that are different from 2^16+1 and 3.
We see 17, too, and somewhat surprisingly, 35.
> We can't check all possible aspects of the key generated by the customer,
> for example we cannot check if the key used good primes, but we can check if
> some rules of thumb are being followed.
>
>
>> On Oct 31, 2012, at 12:58 AM, "Yngve N. Pettersen (Developer Opera
>> Software ASA)" <yngve at opera.com> wrote:
>>
>>> On Wed, 31 Oct 2012 01:02:40 +0100, 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.
>>>
>>>
>>> It is a "general requirement for public keys", so it applies to all use
>>> of
>>> RSA keys (ECC and other methods, if specified) in certificates, including
>>> Roots.
>>>
>>> I suspect that it is much more likely that this check will raise alerts
>>> for subscriber keys, than for CA provided keys, though.
>>>
>>> It is conceivable that this section might someday include more specific
>>> requirements, if research show such requirements are needed.
>>>
>>>> 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?
>>>
>>>
>>> The public exponent is chosen (most often 3 or 2^16+1, currently) as an
>>> input to the key generation algorithm, while the private exponent is
>>> calculated based on the public exponent and the modulus.
>>>
>>> http://en.wikipedia.org/wiki/RSA_(algorithm)#Key_generation
>>>
>>>> -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
>>>
>>>
>>>
>>> --
>>> 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
>>> ********************************************************************
>
>
>
> --
> 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
> ********************************************************************
More information about the Public
mailing list