[cabfpub] August 1st Deadline for No "Good" Reponse to Non-Issued Certificate

Fri Jul 19 22:20:28 UTC 2013

As I believe I said earlier about this: That a specific mitigation can't  
fix every possible scenario should not be held against it as a complete  
show stopper. No mitigation can stop every conceivable attack vector.

The duplicate serial number means one of two things: 1) the signing system  
allow arbitrary serial numbers, or 2) the signing key itself is  
compromised.

Case 1: I have no idea how serial numbers are generated in the CA systems,  
but I think that they should not be under the control of the requesting  
agent, but generated automatically when the certificate is signed. In any  
case this require separate mitigation techniques.

Case 2: In that scenario the signing key and certificate must be revoked.

The timing factor depends upon when the customer gets access to the  
certificate. Also, the only OCSP responder that actually needs the  
information immediately is the fallback responder.

Additionally, beside making the responses from the OCSP responder more  
thrustworthy, such a mitigation step ensures that the attacker will have  
to jump through more hoops, control more of the system, and thus increases  
the chance that he will trigger alarms (and as I understand it, during the  
DigiNotar incident, the attacker tripped numerous alarms, and the people  
at DigiNotar did revoke many certificates, until the attacker disabled the  
logging mechanisms that the adminstrators used to track the attackers  
activities. As mentioned, the intent of this mitigating step is to stop  
that particular attack method, and to bring the meaning of the OCSP  
responses more in line with what we expect them to mean ("Good" should not  
mean "I know nothing bad about this certificate, in fact, I am not sure I  
know whether it exists or not") and a more secure meaning of the responses.

On Fri, 19 Jul 2013 22:04:21 +0200, Kelvin Yiu  
<kelviny at exchange.microsoft.com> wrote:

> I understand the intent of the requirement and I think the idea is  
> logically sound.
>
> As Tom said, the problem is that the requirement does not protect from  
> attackers that are able to use the same serial number as unexpired  
> certificates. When you factor in the requirement for CAs to instaneously  
> update the OCSP server, or make the CA database accessible to the OCSP  
> server, we have to make a security trade off.
>
> The lesson I learned from the Diginotar incident is that network  
> compromises is fact and I believe it is more important to reduce the  
> risk of compromising a CA server by making it as easy as possible to  
> limit the network exposure, than requiring a specific mitigation.
>
> Kelvin
>
> Sent from Windows Phone 8
> ________________________________
> From: Yngve N. Pettersen<mailto:yngve at spec-work.net>
> Sent: ‎7/‎19/‎2013 12:36 PM
> To: public at cabforum.org<mailto:public at cabforum.org>
> Subject: Re: [cabfpub] August 1st Deadline for No "Good" Reponse to  
> Non-Issued Certificate
>
>
> Kelvin, the requirement is there to prevent a CA from responding "this
> certificate is not revoked" for a certificate that the CA in question  
> have
> absolutely no idea *exists*. The worst possible reason for such a query  
> to
> be received is that the CA's issuing system have been compromised, and  
> the
> attacker removed all traces of the certificate having been issued, which
> is what happened during the DigiNotar incident.
>
> Changing this into a recommendation would mean that browsers would never
> be able to reliably determine that a certificate exists and is not
> revoked, and there would be no way to prevent a repetition of the
> DigiNotar incident.
>
> On Fri, 19 Jul 2013 21:18:14 +0200, Kelvin Yiu
> <kelviny at exchange.microsoft.com> wrote:
>
>> My preference is to change the OCSP behavior into a recommendation
>> instead of a requirement with no deadline. The problem with moving the
>> deadline to January is that CAs are still under pressure to meet the
>> requirement. We need to ensure the new deadline takes into account
>> sufficient time to obtain sufficient commercial vendor support and for
>> CAs to integrate the new software.
>>
>> We can still work towards resolving the issue according to Ben’s
>> proposed timeline, but January 2014 is just too soon to be practical.
>>
>> Kelvin
>>
>> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
>> On Behalf Of Eddy Nigg (StartCom Ltd.)
>> Sent: Friday, July 19, 2013 9:48 AM
>> To: public at cabforum.org
>> Subject: Re: [cabfpub] August 1st Deadline for No "Good" Reponse to
>> Non-Issued Certificate
>>
>>
>> On 07/19/2013 07:41 PM, From Ben Wilson:
>> Should we move the deadline from August 1 to January 1 and request that
>> any CA / OCSP software provider with a problem provide us with a
>> statement of progress, hurdles to overcome, and/or proposed milestones,
>> with a response deadline of October 15 .  Then, based on those responses
>> received, if any, we determine whether the deadline should be moved out
>> further?
>> If there is interest in this proposal, then we should create a new
>> ballot and we would need a sponsor and two endorsers.   Also, to the
>> extent that the timing of the review and voting periods would extend
>> beyond August 1, we would have to suspend the rules in order for voting
>> to be completed before August 1.
>>
>> I would agree with both - e.g. split the ballots into two and the
>> January first deadline for OCSP.
>>
>> Regards
>>
>>
>>
>> Signer:
>>
>> Eddy Nigg, COO/CTO
>>
>>
>>
>> StartCom Ltd.<http://www.startcom.org>
>>
>> XMPP:
>>
>> startcom at startcom.org<xmpp:startcom at startcom.org>
>>
>> Blog:
>>
>> Join the Revolution!<http://blog.startcom.org>
>>
>> Twitter:
>>
>> Follow Me<http://twitter.com/eddy_nigg>
>>
>>
>>
>>
>
>
> --
> Sincerely,
> Yngve N. Pettersen
>
> Using Opera's mail client: http://www.opera.com/mail/
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/