[cabfpub] Updated BR errata proposal for issues 6,8,10 and 21

Yngve Nysaeter Pettersen yngve at opera.com
Wed Sep 26 22:33:11 UTC 2012


The following errata ballot motion is proposed by Yngve N. Pettersen and  
endorsed by Jeremy Rowley and ____ :


.... 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 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 #8) Replace 13.1.5(10) with:

      "The CA or a Subordinate CA that controls a Certificate in the
Certificate chain ceases operations for any reason and has not made
arrangements for another CA to provide revocation support for the
Certificate;"

E. (Issue #21) Add new section 13.2.6:

      "13.2.6 Certificate Suspension. The Repository MUST NOT include
entries that indicate that a Certificate is suspended."

F. (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>

     RSA: The value of the public exponent MUST be and odd number equal to 3
or more, it SHOULD be in the range 65537 (2^16^+1) to 2^256^-1."

Erratum ends

.... Motion ends  .....

-- 
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