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

i-barreira at izenpe.net i-barreira at izenpe.net
Tue Jul 23 09:17:14 UTC 2013


+1

I´ve always said that our "deadlines" are not a "dead line" since some of us don´t make it on time. So, or change the deadlines or effective dates or we´re again in a situation like this one. Some of us have "fixed the problem" and some others don´t and want an overtime. I think it´s not fair for those who have done it on time.


Iñigo Barreira
Responsable del Área técnica
i-barreira at izenpe.net
945067705


ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.

-----Mensaje original-----
De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Sigbjørn Vik
Enviado el: martes, 23 de julio de 2013 11:08
Para: public at cabforum.org
Asunto: Re: [cabfpub] Ballot 106 DRAFT - Extended deadline to prohibit OCSP good response for non-issued certificates

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
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public



More information about the Public mailing list