[cabfpub] Updated BR errata proposal for issues 6,8,10 and 21
Ryan Sleevi
sleevi at google.com
Wed Sep 26 18:41:44 MST 2012
One more typographic issue, in the same section
"MUST be and odd number equal to 3"
should read
"MUST be an odd number equal to 3"
On Wed, Sep 26, 2012 at 6:34 PM, Robin Alden <robin at comodo.com> wrote:
> Hi Yngve,
> Comodo will be happy to endorse if you would accept the following typographic correction:
>
> The final text in your proposed amendment reads ".. in the range 65537 (2^16^+1) to 2^256^-1.".
> Unless I have missed something there are too many ^s there. It should read..
> ".. in the range 65537 (2^16 + 1) to 2^256 - 1.
>
> Regards
> Robin Alden
> Comodo
>
>> -----Original Message-----
>> From: public-bounces at cabforum.org [mailto:public-
>> bounces at cabforum.org] On Behalf Of Yngve Nysaeter Pettersen
>> Sent: 26 September 2012 18:33
>> To: public at cabforum.org
>> Subject: [cabfpub] Updated BR errata proposal for issues 6,8,10 and 21
>>
>>
>> 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
>> **********************************************************
>> **********
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
More information about the Public
mailing list