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

[Rick Andrews]

> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
> Behalf Of Yngve N. Pettersen (Developer Opera Software ASA)
> Sent: Friday, July 20, 2012 5:23 PM
> To: public at cabforum.org
> Subject: Re: [cabfpub] Ballot[80] - BR Response for non-issued certificates
> 
> 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.

Yngve, I agree with this 100%. But why doesn't your proposal include a requirement for browsers and other clients? Unless we make changes in browsers and other clients, the attacker has a great chance at remaining undiscovered.

<snip>

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

This gives me another reason to vote against this proposal - it doesn't include that statement. If that is your intent (eliminate the use of CRL-based OCSP responders) or if that is the practical effect of your proposal, I believe it should be spelled out clearly in the proposal for all to see and understand.

-Rick