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

Yngve N. Pettersen (Developer Opera Software ASA) yngve at opera.com
Fri Oct 26 08:31:36 MST 2012



I would assume that you are already implementing what is described in item  
E, particularly the NIST recommendations, which is why I think effective  
immediately should be practical.

Most of that item are SHOULDs, not MUSTs, which gives you some leeway if  
you can defend the procedure (not that I want anyone to try).

The only MUST in that item is that the exponent MUST be an odd number >= 3.

The reason for this particular requirement is that 1) NIST provides expert  
advice about how public key encryption should be handled (and unless I am  
mistaken, most of the recommendations are already included in the BR), and  
2) regarding exponents, small exponents may make the key easier to attack  
(1 being a decidedly bad selection, and so would probably 2 be; and there  
have been a published attack[1] against 3 for buggy implementations), but  
on the other hand having a large public exponent could result in a small  
private exponent, which is equally undesirable, so therefore the  
recommendation is to have the public exponent be a 17 to 256 bit number  
(there are also performance considerations when selecting this number).  
(In fact, for 2048 bit RSA the NIST recommendation is 2^16+1 as a minimum  
for the public exponent)

For more see Adam Langeleys articles  
http://www.imperialviolet.org/2012/03/16/rsae.html and  
http://www.imperialviolet.org/2012/03/17/rsados.html

[1] http://www.imc.org/ietf-openpgp/mail-archive/msg06063.html
-----

Regarding the rationale for the rest of the changes:

  - Protection requriements for the Subordinate CA Private Key was not  
mentioned in the BR
  - Clarified that evidence for a key being compromised is a reason for  
revocation, and also that such evidence might be based on, for example,  
information about ways to break or calculate keys, and not necessarily  
that the customer reports the key stolen.
  - Clarified revocation procedures for Subordinate CAs
  - Clarified deadlines for revocation when a reason for revocation have  
been confirmed. (I wanted this because of several incidents concerning  
revocation of site and subCA certs that took or might have taken longer  
than desirable)
  - Specified that a Certificate cannot be suspended. It is either valid,  
or it is revoked, and it cannot become unrevoked after it has been revoked.


On Fri, 26 Oct 2012 16:13:55 +0200, Stephen Davidson  
<S.Davidson at quovadisglobal.com> wrote:

> I generally support this motion but have some issues with the way item E
> (Issue #10) is being handled.
>
>
> As this change may affect code, I am unhappy voting on it without having  
> an
> effective date.  Certainly the suggestion of "immediate" seems ambitious.
>
>
> Moreover, I think it behooves us to provide a clear note why we are
> specifying the change, why the problem occurs, and how users can tell
> themselves if they have a problem.  Most of the other requirements of
> Appendix A are "surface visible" - in other words, any user can see if a
> cert is 2048bit or SHA2.  This one is not so easily pinned down - and it
> looks even more peculiar that we are referring to a single line of the  
> PIV
> standard in our SSL requirement.
>
>
> If the BR are to be widely implemented by CAs, sometimes we need to  
> provide
> a little guidance both for users and implementers.  For example, Brad's
> notes on the deprecation of internal names have helped many CAs  
> communicate
> consistently to clients why that change is being made.
>
>
> Best, Stephen
>
>
>
> From: management-bounces at cabforum.org
> [mailto:management-bounces at cabforum.org] On Behalf Of Ben Wilson
> Sent: Wednesday, October 17, 2012 8:17 PM
> To: CABFMAN
> Cc: public at cabforum.org
> Subject: [cabfman] Ballot [93] - Reasons for Revocation (BR issues 6, 8,  
> 10,
> 21)
>
>
> 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
********************************************************************


More information about the Public mailing list