<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 5 February 2016 at 08:02, "Barreira Iglesias, Iñigo" <span dir="ltr"><<a href="mailto:i-barreira@izenpe.eus" target="_blank">i-barreira@izenpe.eus</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Doug,<br>
<br>
You can log all your SSL certs in the CT logs now, there´s no "technical" or "legal" restrictions to do so. If you consider that logging all SSL certs issued will improve the transparency, then do it. We are doing it for the same reasoning but also consider that this is not the "unique" solution and there are other options to improve the whole ecosystem, and this ballot could be one for sure. But, what I indicated is to work together and not having 2 similar procedures/processes for the same goal, which is what is stated in eIDAS regulation article 19 and that affects to lots of CAs. So, what I´m against is to have a procedure for the CABF and another one (quite similar or not) according to eIDAS when the goal is the same.<br></blockquote><div><br></div><div>Whilst I am very much in favour of CAs logging all certs to CT, I have to point out that until a browser requires CT, some types of misissuance (i.e. malicious ones) will presumably not be detectable because such certs will not be logged.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards<br>
<span class=""><br>
<br>
Iñigo Barreira<br>
Responsable del Área técnica<br>
i-barreira@izenpe.eus<br>
945067705<br>
<br>
<br>
<br>
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!<br>
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.<br>
<br>
-----Mensaje original-----<br>
</span>De: <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>] En nombre de Doug Beattie<br>
Enviado el: jueves, 04 de febrero de 2016 18:34<br>
Para: Ryan Sleevi; Rick Andrews<br>
CC: <a href="mailto:public@cabforum.org">public@cabforum.org</a><br>
Asunto: Re: [cabfpub] Ballot 161 - Notification of incorrect issuance<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
>> On Wed, Feb 3, 2016 at 5:07 PM, Rick Andrews <<a href="mailto:Rick_Andrews@symantec.com">Rick_Andrews@symantec.com</a>> wrote:<br>
>> In summary, Symantec can’t support this ballot. Symantec instead<br>
>> recommends adoption of a new ballot that would require all publicly<br>
>> trusted CAs to log all their issued certificates in accordance with<br>
>> the Google EV/CT Plan. This requirement should provide CAs a<br>
>> reasonable amount of time to complete implementation, and to address privacy concerns, Symantec further recommends that all certificates be logged in 6962-bis-compliant CT log servers.<br>
<br>
> Given that no 6962-bis-compliant CT log servers exist, and 6962-bis<br>
> continues to be worked on as the lessons learned from CT are applied,<br>
> what timeframe do you see as reasonable? While it's understandable<br>
> that Symantec is expected to comply with this policy in four months,<br>
> regardless of the status of 6962-bis, it would be helpful to know what you believe is reasonable.<br>
<br>
GlobalSign endorses the plan presented by Rick and we would be ready to support a mandatory CT effective date of December 1, 2016 for compliance with the Google EV/CT Plan for all SSL certificates, provided 6962-bis is approved at least 4 months prior to this date and there are a sufficient number of CT logs to use with this updated RFC. We would support earlier, interim dates for mandatory posting all DV certificates to CT logs post issuance (without included SCTs). While this isn’t necessarily compliant with the Google EV/CT plan, it would improve transparency sooner and define a phased plan.<br>
<br>
We would also support the use of CAA to flag orders for manual review to further strengthen issuance processes with pre-issuance checks to supplement CT logging by December 1, 2016.<br>
<br>
Doug<br>
<br>
</div></div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
</div></div></blockquote></div><br></div></div>