[cabfpub] [cabfman] Update of Yngve's BR 1.1 issues + #10

Rick Andrews Rick_Andrews at symantec.com
Fri May 25 00:20:22 UTC 2012


Yngve,

(Moving to public list)

Where can I find the list of BR 1.1 issues? I see this on the wiki (https://www.cabforum.org/wiki/Baseline%20Requirements%20for%20the%20Issuance%20and%20Management%20of%20SSL%20Certificates%20Version%201.1?action=AttachFile&do=view&target=Draft+01.doc) but it's just a subset of the BR document, not a list of issues.

I don't agree with one of your rationales: "Make sure an unknown certificate cannot get OK revocation status". I agree that RFC2560 says that "OK" is an acceptable response in this case, but RFC5019 says that a status of "unauthorized" should be returned in this case. Do you object to "unauthorized" because it's an unsigned response?

Finally, you suggest adding this:
   (3) The CA obtains evidence that the Subscriber’s Private Key (corresponding
   to the Public Key in the Certificate) has suffered a Key Compromise, or that
   the Certificate has otherwise been misused (also see Section 10.2.4); or the
   public key no longer complies with requirements of Appendix A. A Private Key
   is presumed to be 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 evidence that the method
   used to generate the Private Key was flawed (such as presented in
   https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-panic-over-factorable-keys-just-mind-your-ps-and-qs/).
I don't see the value in adding this language. CAs now know how to check for duplicate keys or keys with common factors, but such checks are only as good as the size of the data set it's checking against. Can a small CA just check against other keys in its db? Or must it get the EFF data and compare against that? This seems unenforceable to me.

-Rick

-----Original Message-----
From: management-bounces at cabforum.org [mailto:management-bounces at cabforum.org] On Behalf Of Yngve Nysaeter Pettersen
Sent: Thursday, May 24, 2012 6:43 AM
To: management at cabforum.org
Subject: Re: [cabfman] Update of Yngve's BR 1.1 issues + #10

Hello all,

Below is the suggested errata motion that should resolve BR 1.1 issues #5,  
#6, #7, #8, #10, and #21 (#16 was superseded by #15)

I am seeking two endorsers.

To recap, the rationale for these changes (discussed in greater detail in  
my emails of Feb 5 and April 17) is to:

   - make requirements for revocation (info and actions) stronger or clearer
   - Make sure an unknown certificate cannot get OK revocation status
   - Document good practice regarding public keys.
   - Make it clear that methods that can easily calculate a key or group of  
keys constitute key compromise and must lead to immediate revocation upon  
discovery.
   - Make sure that Subordinate CA certificates are held to the same  
standard as normal certificates.



.... Motion begins ....

Effective July 1, 2012

Erratum begins:


A. At start of section 13.1.5 (Reasons for Revocation) delete current text

   The CA SHALL revoke a Certificate within 24 hours if one or more of the
   following occurs:

and insert:

   The CA SHALL revoke a Subscriber Certificate or Subordinate CA  
Certificate
   within 24 hours of obtaining confirmation if one or more of the
   following occurs:"

B. In section 13.1.5 delete point (3) and insert:

   (3) The CA obtains evidence that the Subscriber’s Private Key  
(corresponding
   to the Public Key in the Certificate) has suffered a Key Compromise, or  
that
   the Certificate has otherwise been misused (also see Section 10.2.4);   
or the
   public key no longer complies with requirements of Appendix A. A Private  
Key
   is presumed to be 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 evidence that the method
   used to generate the Private Key was flawed (such as presented in
   https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-panic-over-factorable-keys-just-mind-your-ps-and-qs/  
).

C. In section 13.1.5  (Reasons for Revocation) insert before current point
10 new points 10 and 11, incrementing current point 10 and succeeding  
points by 2:

    10.  The Subordinate CA ceases operations for any reason and has not  
made
    arrangements for another CA to provide revocation support for the  
Certificate;

    11.  The Subordinate CA’s right to issue Certificates under these
    Requirements expires or is revoked or terminated, unless the  
Subordinate CA
    has made arrangements to continue maintaining the CRL/OCSP Repository;

D. In section 13.2 insert new section 13.2.6:

   13.2.6 Suspension of certificates

   The Repository MUST NOT include entries that indicate that the
   certificate is suspended.

E. In section 13.2 insert new section 13.2.7 with text:

    13.2.7 Response for non-issued certificates

    If the OCSP responder receives a request for status of a certificate  
that
    has not yet been issued, then the responder MUST respond with a  
"REVOKED"
    status. The CA MUST monitor the responder for such requests as part of
    its security response procedures.

F. In Appendix A add after table (3):

   (4) General requirements for public keys:

   RSA: The value of the public exponent MUST be 3 or larger, 65537 is  
RECOMMENDED


G. In Appendix B "Subordinate CA" remove point C  
(authorityInformationAccess) and insert

   C. authorityInformationAccess

   This extension MUST be present.  It MUST NOT be marked critical,
   and it MUST contain:

     * the HTTP URL of the Issuing CA’s OCSP responder (accessMethod =
     1.3.6.1.5.5.7.48.1). See Section 13.2.1 for details about OCSP  
revocation
     requirements.

     * the HTTP URL where a copy of the Issuing (non-Root) CA’s
     certificate (accessMethod = 1.3.6.1.5.5.7.48.2) can be downloaded
     from a 24x7 online repository.

H. In Appendix B "Subscriber Certificate" remove point C  
(authorityInformationAccess) and insert

   C. authorityInformationAccess

   This extension MUST be present.  It MUST NOT be marked critical,
   and it MUST contain:

     * the HTTP URL of the Issuing CA’s OCSP responder (accessMethod =
     1.3.6.1.5.5.7.48.1). See Section 13.2.1 for details about OCSP  
revocation
     requirements.

     * the HTTP URL where a copy of the Issuing CA’s certificate
     (accessMethod = 1.3.6.1.5.5.7.48.2) can be downloaded
     from a 24x7 online repository.


Erratum ends

.... Motion ends  .....



-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: yngve at opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************
_______________________________________________
Management mailing list
Management at cabforum.org
http://cabforum.org/mailman/listinfo/management


More information about the Public mailing list