[cabfpub] Ballot[80] - BR Response for non-issued certificates

Sat Jul 21 00:23:07 UTC 2012

On Sat, 21 Jul 2012 01:09:11 +0200, Rick Andrews  
<Rick_Andrews at symantec.com> wrote:

> While we agree with the "spirit" of this ballot, Symantec will probably  
> vote against this, for these reasons:
>
>
> -          In our opinion, this will have little practical effect  
> because if an attacker subverts a CA and uses the CA's infrastructure to  
> issue a fraudulent cert, that cert will have a valid serial number and  
> will therefore have a "good" status (until the fraud is discovered). If

True.

However, *without* this proposed requirement, he can hide his certificate,  
including which sites are being attacked, and not risk being blocked at  
the outset.

With this proposed requirement, he will have to obtain greater control of  
the CA, leaving more tracks, thus increasing the chance of early  
discovery. With good and secure record-keeping and auditing it should be  
possible to detect such certificates.

Based on current information, DigiNotar was able to revoke the  
fraudulently issued certificates shortly after their issuance was  
triggered by the attacker, *until* the attacker started corrupting the  
logs and records of issued certificates. As a result the OCSP responses  
were "good" for those hidden certificates.

If we had had a situation where this proposed requirement, in combination  
with updates at the browsers and other clients, had been implemented, that  
option would not have worked for the attacker, particularly if the clients  
also refused to show sites where revocation lookup failed as secure  
(disclosure: Opera require success for revocation checking to show a site  
as secure). In such a scenario the attacker would have had to leave behind  
information about his activities, leaving himself open to discovery.

This proposal should prevent another incident of the kind that happened  
with DigiNotar, and it increases the likelihood of discovery in case of an  
attack, because the attacker can no longer just hide his loot, he have to  
leave behind much more information about what he's done.

> the attacker does not subvert the CA's infrastructure (instead mounts a  
> hash collision attack, for example), s/he could easily choose to use an  
> existing serial number and therefore get a "good" status (until the

Given current requirements, I suspect that if a collision attack is  
practical (as it was for MD5 with linear serial numbers), then we actually  
have a situation where the hashmethod, at least, need to be discarded for  
a more secure method. Worst case, the CA certificates and all issued  
certificates using the method will have to be revoked, because they can no  
longer be trusted.

> fraud is discovered and the legitimate certificate is revoked). The  
> motion will only help in the very limited case in which the attacker  
> does not subvert the CA's infrastructure, and uses a non-existent serial  
> number.
>
>
> -          Any CA that uses a CRL-based OCSP responder product (and  
> Symantec does, for a subset of our CAs) will be unable to comply until  
> the vendor builds in that functionality (we think it's non-trivial) and  
> the CA deploys it, or the CA replaces the CRL-based OCSP responder with  
> one not based on CRLs. Neither option can be accomplished in 6 months;  
> both options will probably take a year or more.

Given the new threat environment, I think that the CRL-based OCSP  
responders are no longer suitable for providing secure status information.

>
> -          The BRs currently treat CRLs almost the same as OCSP (Section  
> 13.2.2 "Repository" essentially says that the CA must support OCSP and  
> may support CRLs), and if a relying party uses CRLs instead of OCSP,  
> they will interpret anything not on the CRL as "good". So this ballot  
> will do nothing at all to help those relying parties.

At present most browser clients use OCSP (although admittedly Google  
Chrome is moving away from online revocation checks) for end entity  
certificates, while clients vary on what they use for intermediate CAs,  
some use OCSP, others (e.g. Opera) currently use CRLs. And if multiple  
stapling is implemented, then CRLs will become mostly a fallback options,  
not the main source of revocation information for the client.

The main reason I never added OCSP for intermediate CAs in Opera was to  
not add to the CAs' traffic load. If we can rely on not getting "good"  
status for non-issued certificates, then perhaps it is time reconsider  
that decision, and use OCSP for those certificates, too?

Relying parties that only rely on CRLs, particularly for end entity  
certificates, should move to OCSP, particularly if they can rely on "good"  
meaning "yes, it was issued by us, and we know what the certificate says".

> -Rick
>
>
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]  
> On Behalf Of Tim Moses
> Sent: Friday, July 20, 2012 11:41 AM
> To: CABFPub
> Subject: [cabfpub] Ballot[80] - BR Response for non-issued certificates
>
>
> Yngve Pettersen made the following motion and Ben Wilson and Carsten  
> Dahlenkamp endorsed it:
>
> ... Motion begins....
>
> Effective 1 Feb 2013
>
> ... Erratum begins ...
>
> Insert a new section at the end of section 13.2 of the Baseline  
> Requirements with the following heading and text:
>
> "13.2.6 Response for non-issued certificates
>
> If the OCSP responder receives a request for status of a certificate  
> that has not been issued, then the responder MUST NOT respond with a  
> "good" status. The CA SHOULD monitor the responder for such requests as  
> part of its security response procedures."
>
> ... Erratum ends ...
>
> The ballot review period comes into effect at 21:00 UTC on 19 July 2012  
> and will close at 21:00 UTC on 26 July 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 2 August 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
>
> with the addition of  
> TrendMicro<https://www.cabforum.org/wiki/TrendMicro>.
>
> 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 favour. Also, at  
> least seven members must participate in the ballot, either by voting in  
> favour, voting against or abstaining.
>
> T: +1 613 270 3183
>

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