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

Kelvin Yiu kelviny at exchange.microsoft.com
Mon Jul 22 17:05:56 UTC 2013


I wanted to review the Fox It report on DigiNotar again before I respond.

http://www.rijksoverheid.nl/bestanden/documenten-en-publicaties/rapporten/2012/08/13/black-tulip-update/black-tulip-update.pdf

On page 45, the authors of the report stated “It is possible that the CA software that was used was able to produce certificates that have identical certificate attributes as previously issued certificates. This includes the serial number and the validity dates, … The intruder could have issued certificates that would be seemingly identical to formally issued and trusted ones.”

The attacks seemed to have access to the CA servers in a way that can modify CA server logs and databases. The attackers would also have access to the private key whenever the netHSM hosting the CA keys was activated which means the attacker could have bypassed the CA software and signed arbitrary certificates.

If the forum is not ready to accept changing the OCSP unknown behavior to recommended, then we need to delay the date by a realistic margin (IMO at least 1 year) while we reexamine the issue and gather support from OCSP vendors. I am all for tightening security when possible, but this must be done in a way that all CAs can comply by the deadline.

Kelvin


From: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org] On Behalf Of Erwann ABALEA
Sent: Friday, July 19, 2013 5:31 PM
To: Yngve N. Pettersen
Cc: public at cabforum.org<mailto:public at cabforum.org>
Subject: Re: [cabfpub] August 1st Deadline for No "Good" Reponse to Non-Issued Certificate


2013/7/20 Yngve N. Pettersen <yngve at spec-work.net<mailto: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/20130722/05b7663f/attachment-0003.html>


More information about the Public mailing list