[cabfpub] [cabfman] Ballot [93] - Reasons for Revocation (BR issues 6, 8, 10, 21)
Ben Wilson
ben at digicert.com
Wed Oct 31 09:41:03 MST 2012
Am I correct in understanding that the public exponent is disclosed in
certificates and CSRs immediately following the public key? If that is the
case, all that needs to be done is for the CA to parse the ASN1, look at it,
and confirm that it is not "1" and not divisible by "2". Even I can do that
myself in my head by visually looking at any CSR or certificate.
Otherwise, the rest are "shoulds."
-----Original Message-----
From: management-bounces at cabforum.org
[mailto:management-bounces at cabforum.org] On Behalf Of Ben Laurie
Sent: Wednesday, October 31, 2012 10:20 AM
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)
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
> ********************************************************************
_______________________________________________
Management mailing list
Management at cabforum.org
https://cabforum.org/mailman/listinfo/management
More information about the Public
mailing list