[cabfpub] "Rob's tool" (was Re: Ballot 161 - Notification of incorrect issuance)

Fri Feb 5 12:17:50 UTC 2016

I don't think anyone's actually posted the links to this list yet, so 
here they are...

https://crt.sh/?cablint=1+week
is a regularly auto-updated per-CA summary of "issues" found in certs 
that have notBefore dates within the past 1 week.  From this page you 
can drill down to find the affected certs.

https://crt.sh/?cablint=issues
shows the number of certs affected by each "issue".  From this page you 
can drill down to see which CAs are responsible for each "issue", and 
then drill down further to find the affected certs.

The clever stuff (i.e. diagnosing the "issues") is done by Peter Bowen's 
excellent "cablint" tool (https://github.com/awslabs/certlint).  :-)

On 05/02/16 11:50, Doug Beattie wrote:
> Inigo,
>
> The security of the ecosystem can only be improved if all CAs are doing the same thing, otherwise the attacker will go to the one which is not implementing the feature, CT in this case. The same is true for CAA where there is not much benefit until everyone is doing it.
>
> I also oppose this ballot because of the level at which "incorrect issuance" is being requested.  For real misissuance when a certificate was falsely approved or a bug exploited to receive a certificate, sure, I have no issue with that.  But if the reporting needs to include typos, the improper encoding of a field, minor non-compliance with referenced specs like RFC5280 then no, this is not something I can support.  It's both vague, and in my view, unnecessary at that level.  All you need to do is use Rob's tool and you'll fine errors in certificates from virtually every CA.  The CABF would be flooded with irrelevant notices of misissuance which would make it harder to understand the real ones.  The bar for reporting needs to be higher that proposed in the current ballot.
>
> CAs need to think hard about voting for this ballot because the increased scope of misissuance will lead to increased WT audit findings as well as add workload to report problems via 2 different methods, as Inigo points out.
>
> Let's see if we can work something out at the F2F that works for everyone.
>
> Doug
>
>
>
>
>> -----Original Message-----
>> From: "Barreira Iglesias, Iñigo" [mailto:i-barreira at izenpe.eus]
>> Sent: Friday, February 5, 2016 3:02 AM
>> To: Doug Beattie <doug.beattie at globalsign.com>; Ryan Sleevi
>> <sleevi at google.com>; Rick Andrews <Rick_Andrews at symantec.com>
>> Cc: public at cabforum.org
>> Subject: RE: [cabfpub] Ballot 161 - Notification of incorrect issuance
>>
>> Doug,
>>
>> 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.
>>
>> Regards
>>
>>
>> Iñigo Barreira
>> Responsable del Área técnica
>> i-barreira at izenpe.eus
>> 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 Doug Beattie
>> Enviado el: jueves, 04 de febrero de 2016 18:34
>> Para: Ryan Sleevi; Rick Andrews
>> CC: public at cabforum.org
>> Asunto: Re: [cabfpub] Ballot 161 - Notification of incorrect issuance
>>
>>
>>>> On Wed, Feb 3, 2016 at 5:07 PM, Rick Andrews
>> <Rick_Andrews at symantec.com> wrote:
>>>> In summary, Symantec can’t support this ballot. Symantec instead
>>>> recommends adoption of a new ballot that would require all publicly
>>>> trusted CAs to log all their issued certificates in accordance with
>>>> the Google EV/CT Plan. This requirement should provide CAs a
>>>> 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.
>>
>>> Given that no 6962-bis-compliant CT log servers exist, and 6962-bis
>>> continues to be worked on as the lessons learned from CT are applied,
>>> what timeframe do you see as reasonable? While it's understandable
>>> that Symantec is expected to comply with this policy in four months,
>>> regardless of the status of 6962-bis, it would be helpful to know what you
>> believe is reasonable.
>>
>> 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.
>>
>> 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.
>>
>> Doug
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.