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

[Erwann ABALEA]

2013/7/20 Yngve N. Pettersen <yngve at spec-work.net>

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

Right.


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

Or 3) the attacker has managed to perform a chosen-prefix collision attack.
If the serial number of the legitimately requested certificate isn't
predictable, that can't happen (famous last words?). That's why the BR
requests CAs to introduce at least 20 bits of entropy into serial numbers.
And that's also why we should push SHA1 out of the game (we're already
late).
In that case, the attacker would be well advised to also generate an OCSP
certificate, so the CA's OCSP servers won't hear about the bogus
certificates.

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

So in Case 2 and 3, there's nothing we can do except revoke at a higher
level. In Case 1, depending on the CA system, the attacker may also be able
to specify more than just the serial number.


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

The intention is nice.
On one hand, it still leaves some doors open, but as you said in the first
paragraph, a *perfect* solution is out of reach.
On the other, it's clear that a lot of CAs won't be ready in 11 days.

I'm against changing the OCSP behaviour into a simple recommendation, at
least for unconstrained CAs.

-- 
Erwann.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130720/77855bd5/attachment-0003.html>