[cabfpub] Ballot 106 DRAFT - Extended deadline to prohibit OCSP good response for non-issued certificates

Sigbjørn Vik sigbjorn at opera.com
Tue Jul 23 09:07:44 UTC 2013


On 23-Jul-13 01:14, Kelvin Yiu wrote:
> I am looking for 2 endorsers of ballot 106 to extend the deadline to
> prohibit OCSP good response for non-issued certificates by 1 year. I am
> somewhat flexible on the date, but I do think it should be extended by
> at least 6-12 months to give CAs enough time to comply. Here is the
> draft motion.

I am quite surprised that we are still discussing this, as well as by
the arguments in the discussion. OSCP has a major flaw without this,
making OCSP responses untrustworthy. Personally I consider CAs which
respond good to non-issued certificates, to have a security hole. In
other areas of life, it is not even necessary to specify that good=good,
and not something else. I was pleasantly surprised when I learned that
the CABForum had agreed to specify good=good, although I was already
then taken aback by the extremely long time frame it had given itself to
fix the problem, I couldn't, and still can't, see what would take so long.

I understand that software change can take time, but in this case there
has been plenty of time already. If someone is not able to comply, that
indicates unwillingness, not inability, and I don't see that changing
over the next year. The web changes at an incredible speed, and when a
security incident happens, we rely on all actors involved being able to
respond quickly. Browser vendors frequently measure response times in
hours, not years. If CAs want to be part of this game, they also need to
be willing to play.

As far as I understand it, the majority of CAs, of all types, have been
able to comply with the new requirement. These CAs have invested in
secure solutions for the progress of the web. Other CAs have necessarily
had their priorities elsewhere, it seems some have not even started
looking at fixing this. Extending the deadline now would be throwing
away the investments of the secure CAs, and rewarding those with other
priorities, the opposite of what we want. It also risks creating an
investment-hostile environment, where future deadlines will be
overlooked, as they will be thought unrealistic anyway, to the overall
detriment of the web. In the long run, the web is well served with a
wake-up call every once in a while, showing that investing in security
pays off. If some CAs will not be able to comply by 1st of August, and
will notice the effects, I consider this a good thing.

I think setting deadlines for moving off insecure methods is important,
and something which the CABForum will have to do more of in the future.
I think setting a date for good=good was a very wise decision by the
CABForum. The problem is that some players did not take the deadline
seriously. We can fix that problem now, or we can make it worse.

Several other arguments I don't really follow:
If knowledge of serial numbers is a problem, then something else needs
to be fixed anyhow. Anyone with a simple spider can harvest serial
numbers from the web, and with CT, there will be central databases of
serials. If hash collisions are a concern, then something else needs to
be fixed in any case. If data on the OCSP responder is not secure, then
there is already a problem elsewhere. If implementing good=good reduces
security elsewhere, then it is not done correctly. If the CA is hacked,
then all hell is loose anyway. I don't see how any of this is relevant
to specifying good=good.

Ultimately, I have yet to see any arguments for how extending the
deadline would benefit the web, while I see a lot of reasons for how
improving web security now does benefit the web.

-- 
Sigbjørn Vik
Opera Software



More information about the Public mailing list