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

[Yngve N. Pettersen (Developer Opera Software ASA)]

On Mon, 23 Jul 2012 18:55:10 +0200, Rick Andrews  
<Rick_Andrews at symantec.com> wrote:

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

As I recall, Rick, you are working on a document in the revocation work  
group that should deal with the client aspect of this. This proposal is  
about what the CA's OCSP responder should do.

In any case, I have fixing our (Opera's) current issues with "unknown" and  
"unauthorized" (which are due in part to an oversight, and in part due to  
past issues with OCSP responders) high up on my list, and I hope to get  
testcases running sometime this week, so that I can test it and fix it in  
Opera. I can't speak for the other browsers, though.

Also, this aspect was why I originally wanted to require "revoked"  
responses in this case.

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

I am not specifically out to get rid of CRL-based OCSP responders. As  
stated, my goal is to make sure that a "good" response means that the  
certificate was issued and has not been revoked. As far as I know, OCSP  
responders that are using CRLs as their only source of information cannot  
provide such a promise, and it therefore follows naturally from the  
proposed requirement is that they cannot be used. I therefore don't really  
see a need to say something like "OCSP responders MUST NOT rely solely on  
a CRL", as it would be redundant.

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