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

Yngve N. Pettersen (Developer Opera Software ASA) yngve at opera.com
Fri May 25 09:10:12 MST 2012


On Fri, 25 May 2012 02:20:22 +0200, Rick Andrews  
<Rick_Andrews at symantec.com> wrote:

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

I object to "unauthorized" because Opera, and probably many other  
browsers, do not consider it fatal, as it is (in my experience) the most  
common response code from malfunctioning OCSP responders. In 2005/2006  
(around Opera 8.5/8.6) at a time Opera treated non-good responses as  
fatal, we had at least one case where important an OCSP responder was  
sending this code for several *weeks*, and it was not the only incident  
we've seen of that kind.

Therefore, the chosen response code have to have some way of ensuring that  
the client treats the response as fatal.

And please note, my suggestion is for non-issued certificates. The most  
likely scenario for observing such requests are a fraudulently issued  
certificate (as during the DigiNotar incident) that was not inserted into  
the CA's database for issued certificate, or an DOS attack on the signer  
(not the responder itself). In the DOS scenario, the signer might be  
overloaded, but with pre-generated responses only out-of-the-ordinary  
requests (from the attacker) will be affected, not normal requests.

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

My point is to emphasize that if there are methods to discover the Private  
key, based on the public key, then that must be considered a compromise of  
the the key. The examples provided are examples of currently known methods  
of such discovery (they are not intended as an exhaustive list). The  
examples could be left out of the

The reason I want this included is that, when the Debian weak keys were  
discovered, it took months to get those certificates revoked. I want it to  
be very clear that, in such cases, the certificate must be revoked  
immediately (that is, within 24 hours of discovery).

The common factor/duplicate key problem is now known, and I expect that  
CAs will be checking for such keys. How they do that is up to them, but  
if/when they discover certificates with the problem I want the certificate  
revoked quickly, and I would like the BR to reflect that.


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


More information about the Public mailing list