[cabfpub] Misissuance of certificates

"Barreira Iglesias, Iñigo" i-barreira at izenpe.eus
Tue Nov 10 09:01:10 UTC 2015




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





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.


De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Ryan Sleevi
Enviado el: lunes, 09 de noviembre de 2015 15:16
Para: Dean Coclin
CC: public at cabforum.org
Asunto: Re: [cabfpub] Misissuance of certificates





	Also, I think Inigo raised some privacy concerns that may make the above a violation of local laws. 


Considering that our very documents refer to them as "Publicly Trusted Certificates", it is intrinsic in the definition that they be Public in order to be Publicly Trusted. Any CA that is issuing certificates that they cannot freely and readily disclose due to local jurisdictions either:

a) Needs to relocate jurisdictions

b) Change their issuance process to not impinge upon such local jurisdictions

c) Request that their CA be removed from being Publicly Trusted.


In concrete, and absolute, terms: Privacy is not a justification for nor a shield during misissuance.


I´m partially agree with this statement “privacy is not a justification …” but unfortunately, and I´m not a lawyer, there´s the so called data protection organic law that usually is in contradiction with the e-signatures law (which is not applicable to SSL certs but it´s about the same more or less) and even worst has preference or is above this one, and this is EU wide. The issue here is that if the problem with the misissuance of a certificate is due to a technical problem or with a validation stuff prior to the issuance and in the Opera´s proposal there´s no such distinction. 

I can make a report of what I did wrong technically and explain the whole world my fault but if the issue was related to some “private” information of the company that I didn´t do correctly, and I´m afraid I can´t publish/mention that information in the report because I can be accused/sue by that company. The information on the certificate is public but not all the information we have to gather to issue the certificate is public.

I´m not against Opera´s proposal but I think a little rewording detailing exactly what it´s expected and the reasoning would help. And it´s not about relocating jurisdictions or local laws, this is applicable in the whole EU, so we (the EU TSPs) are not able to move around the globe J


OTOH, I wonder if this is only about this particular issue, the mis-issuance of certificates, or can be in a wider proposal, about any security breach, having in mind this is a security breach. For this, as per new EU regulation (eIDAS), the EU TSPs are mandate to communicate any security breach to our supervisory body (ENISA is working on defining/developing a procedure) and as mentioned at a workshop in Brussels, I consider the browsers a kind of a supervisory body, so the same procedure to communicate to our supervisory body can be used to let the browsers/CABF the incident. This way, we wouldn´t need to have a different procedure to communicate that “incident” depending if this is for our national supervisory body or to the CABF. Have in mind that this notification to the “local” supervisory body means that this is distributed across the EU and the Commission, so everybody knows what happened to that TSP as well. Can this make sense? I can ask ENISA how they´re going or if they can provide any info.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151110/8fe9f0a0/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 8648 bytes
Desc: image001.jpg
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151110/8fe9f0a0/attachment-0003.jpg>

More information about the Public mailing list