Re: Remediation Plan for WoSign and StartCom

[Eric Mill]

Oh, I read too quickly and saw it as a list of certificates whose
expiration dates were within each month. In retrospect, that was not the
most likely way the numbers would be distributed -- apologies for causing
confusion.

On Sat, Oct 15, 2016 at 6:20 PM, Kurt Roeckx  wrote:

> On Sat, Oct 15, 2016 at 06:07:50PM -0400, Eric Mill wrote:
> > For the convenience of the thread -- assuming that a 1-year-oriented
> policy
> > covered the certs up to and including those listed as 2017-10-01, then
> > summing up Kurt's numbers:
> >
> > * Certs expiring by Oct 2017: 2,088,329
> > * Certs expiring after Oct 2017: 1,419,593
>
> I'm not sure where you get the numbers from, maybe they weren't
> clear.  But by 2017-10-01 the number of expired certifictes would
> be 196100 - 138156 = 57944
>
>
> Kurt
>
>


-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Kurt Roeckx]

On Sat, Oct 15, 2016 at 06:07:50PM -0400, Eric Mill wrote:
> For the convenience of the thread -- assuming that a 1-year-oriented policy
> covered the certs up to and including those listed as 2017-10-01, then
> summing up Kurt's numbers:
> 
> * Certs expiring by Oct 2017: 2,088,329
> * Certs expiring after Oct 2017: 1,419,593

I'm not sure where you get the numbers from, maybe they weren't
clear.  But by 2017-10-01 the number of expired certifictes would
be 196100 - 138156 = 57944


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[Eric Mill]

On Sat, Oct 15, 2016 at 4:31 AM, Peter Gutmann 
wrote:

>  The only one who's openly addressed this
> seems to be Mozilla.
>

It would certainly be nice if Mozilla weren't the only openly operated root
program. :)

It seems to put Mozilla in the situation of being the effective first-mover
whether they want to be or not, since they're the only entity hosting
public discussions about what to do. It certainly felt that way with
WorldPay, and Ryan's comments to Kathleen in the other thread about whether
Mozilla could be more aggressive with WoSign if they knew they were not
going to be saddled with first/only-mover disadvantage seems to point to
this dynamic as well.

-- Eric


> Peter.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Eric Mill]

For the convenience of the thread -- assuming that a 1-year-oriented policy
covered the certs up to and including those listed as 2017-10-01, then
summing up Kurt's numbers:

* Certs expiring by Oct 2017: 2,088,329
* Certs expiring after Oct 2017: 1,419,593

On Sat, Oct 15, 2016 at 4:28 AM, Kurt Roeckx  wrote:

> On Fri, Oct 14, 2016 at 11:23:55PM +0200, Hanno Böck wrote:
> > On Fri, 14 Oct 2016 13:21:32 -0700 (PDT)
> > Ryan Sleevi  wrote:
> >
> > > In particular, I'm hoping to expand upon the choice to allow existing
> > > certs to continue to be accepted and to not remove the affected roots
> > > until 2019.
> >
> > Hi,
> >
> > From my understanding the problem here is that the alternative of simply
> > whitelisting the existing certificates isn't feasible, because there
> > are too many of them.
> >
> > *however* from what I remember almost all the time the free options of
> > startcom/wosign were limited to one year. (I think there was a short
> > period of time when it was possible to get 3-year-certs from wosign for
> > free, but they removed that shortly afterwards.)
> >
> > Therefore there should be some middlegroupd option:
> > a) Keep the existing root for 1 year and trust that wosign won't
> > backdate certificates
> > b) After that the vast majority of wosign/startcom certificates will be
> > expired. The number of the remaining ones is probably low enough to
> > make whitelisting feasible.
> >
> > I haven't checked CT logs for expiration dates, so this is more a
> > guess, but given the history of cert issuance and the reasonable
> > assumption most certs used the free option this seems plausible.
>
> This is what I get for the number of valid certificates:
>  2016-10-01 | 196100
>  2016-11-01 | 185740
>  2016-12-01 | 175310
>  2017-01-01 | 168933
>  2017-02-01 | 166109
>  2017-03-01 | 162535
>  2017-04-01 | 157278
>  2017-05-01 | 154630
>  2017-06-01 | 151857
>  2017-07-01 | 147927
>  2017-08-01 | 144076
>  2017-09-01 | 139678
>  2017-10-01 | 138156
>  2017-11-01 | 137849
>  2017-12-01 | 137648
>  2018-01-01 | 132568
>  2018-02-01 | 126031
>  2018-03-01 | 120888
>  2018-04-01 | 110723
>  2018-05-01 |  98605
>  2018-06-01 |  82580
>  2018-07-01 |  69629
>  2018-08-01 |  55843
>  2018-09-01 |  42570
>  2018-10-01 |  37793
>  2018-11-01 |  37541
>  2018-12-01 |  37287
>  2019-01-01 |  35227
>  2019-02-01 |  32453
>  2019-03-01 |  29538
>  2019-04-01 |  25133
>  2019-05-01 |  21264
>  2019-06-01 |  17563
>  2019-07-01 |  14310
>  2019-08-01 |  10892
>  2019-09-01 |   5429
>  2019-10-01 |124
>  2019-11-01 | 71
>  2019-12-01 | 31
>  2020-01-01 |  2
>  2020-02-01 |  1
>
>
> Kurt
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident Report - certificate with 'sb' as a SAN:dnsName

[Hanno Böck]

Hello,

I think I have asked two reasonable questions here.
Can we get an answer?

On Tue, 4 Oct 2016 14:33:38 +0200
Hanno Böck  wrote:

> There seem to be more certificates of that kind that weren't mentioned
> in the incident report. Here's a .re / www.re certificate (expired
> 2015):
> https://crt.sh/?id=4467456
> 
> Has comodo checked its systems for other certificates of that kind?
> Can you provide a full list of all such certificates?
> 
> 
> Also my understanding is that the error here was that control over the
> www.[domain] subdomain would indicate control over [domain]. Does that
> mean that this bug could've been used to also get wildcard
> certificates in the form of *.[tld]?

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


pgpEhCBg0LpHm.pgp
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: StartCom & Qihoo Incidents

[Jeremy Rowley]

It's definitely not the place to discuss individual CAs. The CAB Forum
creates guidelines but, intentionally and by design, is not an enforcement
or root management authority. The CAB Forum can set policies about CAs, but
the browsers retain the sole right to decide what penalties are appropriate
for violating the policy. 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Peter Gutmann
Sent: Saturday, October 15, 2016 2:31 AM
To: Erwann Abalea ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom & Qihoo Incidents

Erwann Abalea  writes:

>And that's not CABF's duty and responsibility. What the CABF can impose 
>to CABF members is to follow the bylaws, the internal governance rules. 
>By following them, all members write the guidelines and decide on what 
>changes to adopt, and browsers then impose CAs to follow these guidelines.

Hmm, OK.  I was just wondering why the CABF seemed to be missing in action,
since it appeared to be the logical place to address this sort of issue.

>What appears from the CABF meeting minutes is that the 
>WoSign+StartCom+Qihoo combination is looked after, precisely regarding the
bylaws.

Hmm, I'm not quite sure what you mean by that, but a quick check of the most
recently published minutes:

https://cabforum.org/2016/09/15/2016-09-15-minutes/
https://cabforum.org/2016/09/29/2016-09-29-minutes/

indicate that not much has happened, there's just a brief comment about
whether { WoSign, Startcom, Qihoo 360 } should be treated as one entity or
three.  I assume that's the bylaw issue?

So there really is no-one running the show, meaning no coordinating body
that can say "bad things are happening over here, you need to take action to
deal with them"?  It just seems odd that the next time a CA goes rogue,
every end user on the planet has to wait for whatever browser vendor they
rely on to make some arbitrary decision on what to do, or as it seems for
many vendors in the case of WoSign, do nothing.  The only one who's openly
addressed this seems to be Mozilla.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[Peter Gutmann]

Erwann Abalea  writes:

>And that's not CABF's duty and responsibility. What the CABF can impose to
>CABF members is to follow the bylaws, the internal governance rules. By
>following them, all members write the guidelines and decide on what changes
>to adopt, and browsers then impose CAs to follow these guidelines.

Hmm, OK.  I was just wondering why the CABF seemed to be missing in action,
since it appeared to be the logical place to address this sort of issue.

>What appears from the CABF meeting minutes is that the WoSign+StartCom+Qihoo
>combination is looked after, precisely regarding the bylaws.

Hmm, I'm not quite sure what you mean by that, but a quick check of the most
recently published minutes:

https://cabforum.org/2016/09/15/2016-09-15-minutes/
https://cabforum.org/2016/09/29/2016-09-29-minutes/

indicate that not much has happened, there's just a brief comment about
whether { WoSign, Startcom, Qihoo 360 } should be treated as one entity or
three.  I assume that's the bylaw issue?

So there really is no-one running the show, meaning no coordinating body that
can say "bad things are happening over here, you need to take action to deal
with them"?  It just seems odd that the next time a CA goes rogue, every end
user on the planet has to wait for whatever browser vendor they rely on to
make some arbitrary decision on what to do, or as it seems for many vendors in
the case of WoSign, do nothing.  The only one who's openly addressed this
seems to be Mozilla.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Kurt Roeckx]

On Fri, Oct 14, 2016 at 11:23:55PM +0200, Hanno Böck wrote:
> On Fri, 14 Oct 2016 13:21:32 -0700 (PDT)
> Ryan Sleevi  wrote:
> 
> > In particular, I'm hoping to expand upon the choice to allow existing
> > certs to continue to be accepted and to not remove the affected roots
> > until 2019.
> 
> Hi,
> 
> From my understanding the problem here is that the alternative of simply
> whitelisting the existing certificates isn't feasible, because there
> are too many of them.
> 
> *however* from what I remember almost all the time the free options of
> startcom/wosign were limited to one year. (I think there was a short
> period of time when it was possible to get 3-year-certs from wosign for
> free, but they removed that shortly afterwards.)
> 
> Therefore there should be some middlegroupd option:
> a) Keep the existing root for 1 year and trust that wosign won't
> backdate certificates
> b) After that the vast majority of wosign/startcom certificates will be
> expired. The number of the remaining ones is probably low enough to
> make whitelisting feasible.
> 
> I haven't checked CT logs for expiration dates, so this is more a
> guess, but given the history of cert issuance and the reasonable
> assumption most certs used the free option this seems plausible.

This is what I get for the number of valid certificates:
 2016-10-01 | 196100
 2016-11-01 | 185740
 2016-12-01 | 175310
 2017-01-01 | 168933
 2017-02-01 | 166109
 2017-03-01 | 162535
 2017-04-01 | 157278
 2017-05-01 | 154630
 2017-06-01 | 151857
 2017-07-01 | 147927
 2017-08-01 | 144076
 2017-09-01 | 139678
 2017-10-01 | 138156
 2017-11-01 | 137849
 2017-12-01 | 137648
 2018-01-01 | 132568
 2018-02-01 | 126031
 2018-03-01 | 120888
 2018-04-01 | 110723
 2018-05-01 |  98605
 2018-06-01 |  82580
 2018-07-01 |  69629
 2018-08-01 |  55843
 2018-09-01 |  42570
 2018-10-01 |  37793
 2018-11-01 |  37541
 2018-12-01 |  37287
 2019-01-01 |  35227
 2019-02-01 |  32453
 2019-03-01 |  29538
 2019-04-01 |  25133
 2019-05-01 |  21264
 2019-06-01 |  17563
 2019-07-01 |  14310
 2019-08-01 |  10892
 2019-09-01 |   5429
 2019-10-01 |124
 2019-11-01 | 71
 2019-12-01 | 31
 2020-01-01 |  2
 2020-02-01 |  1


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy