StartCom remediation plan

[Inigo Barreira]

All,

 

In this link,
https://www.startssl.com/report/StartCom_Remediation_Plan_14102016.pdf,
you´ll find the detailed remediation plan for StartCom as was notified last
week. It took us some time to have all the people needed for these tasks and
clarify the dates for fixing all the possible findings.

StartCom considers this plan accurate and enough to the Mozilla community,
specially for their users base, to regain and keep the confidence on our
capacity as a trusted CA.

 

In the plan you all can see that regarding the PKI system, there are 2
actions based on timing, but always using the current roots, we may rethink,
due to the email delivered by Mozilla yesterday, if the mid term solution
has to be changed and instead of doing for the current roots, this has to be
done for new roots, which would mean a longer delay because would need to
almost start from scratch.

We´d like to hear from Mozilla in this regard and if so, would allow
Startcom some more time. 

Anyway, this remediation plan is to be executed by all means, but would like
to be sure about the mid term solution.

 

Regards

 



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: Remediation Plan for WoSign and StartCom

[bigiain]

On Friday, October 14, 2016 at 9:47:24 AM UTC+11, Percy wrote:
> > Others have noted the mismatch here with an October 1 date elsewhere in 
> > the document. I think we should pick a single date in the future, to 
> > allow the CAs concerned to wind down operations without leaving 
> > customers having just obtained certs which will stop working in a few 
> > months. So I would argue for October 21st in line with our principle of 
> > minimal disruption to cert owners. 
> 
> I think Oct 1st is a better deadline. WoSign has stopped issuing DV certs 
> since Sept 29th and Apple has banned certs after 2016-09-19. There is no 
> reason to give WoSign another week of time to issuing new certs. 

FWIW, I've got a StartCom cert here dated Not Valid Before: Tuesday, 4 October 
2016

I'll deal with if if it's decided to kill Start off and impact customers from 
before this decision, but it'll be a (possibly unintended?) pain in the arse...

(https://metricon.mobiddiction.com.au/ for anyone curious...)

Iain
___
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

[Nick Lamb]

On Friday, 14 October 2016 02:21:36 UTC+1, Matt Palmer  wrote:
> Will there be any requirements around the qualification status of the logs,
> or could anyone who wanted to be "nice" just stand up a log, and have these
> CAs obtain precerts from them?

I don't think Mozilla has declared any specific requirements, but presumably 
they would expect to choose the same or similar criteria as Google's Chrome 
which you're already aware of but I'll link for anybody else

https://www.chromium.org/Home/chromium-security/certificate-transparency/log-policy

For the immediate purpose here (allowing broad oversight over what the new CA 
is issuing) some of these criteria are less important, e.g. the >99% uptime may 
be less important because oversight would be done via a monitor, but Mozilla 
intends to add SCT-checking to Firefox, at which point all the criteria will be 
important.
___
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 2016-10-14 03:20, Matt Palmer wrote:

On Thu, Oct 13, 2016 at 09:49:50AM -0700, Kathleen Wilson wrote:

5. 100% embedded CT for all issued certificates, with embedded SCTs from
at least one Google and one non-Google log not controlled by the CA.


Will there be any requirements around the qualification status of the logs,
or could anyone who wanted to be "nice" just stand up a log, and have these
CAs obtain precerts from them?


I would suggest to use the same qualification criteria as Google uses 
for Chromium 
(https://www.chromium.org/Home/chromium-security/certificate-transparency/log-policy).


The requirement are otherwise more strict that what Chromium uses, it 
does not require them to be embedded, and they can operate the log 
themselves.  See 
https://www.chromium.org/Home/chromium-security/root-ca-policy/CTPolicyMay2016edition.pdf



Kurt


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

StartCom remediation plan

[Inigo Barreira]

All,





In this link, 
https://www.startssl.com/report/StartCom_Remediation_Plan_14102016.pdf, you´ll 
find the detailed remediation plan for StartCom as was notified last week. It 
took us some time to have all the people needed for these tasks and clarify the 
dates for fixing all the possible findings.



StartCom considers this plan accurate and enough to the Mozilla community, 
specially for their users base, to regain and keep the confidence on our 
capacity as a trusted CA.





In the plan you all can see that regarding the PKI system, there are 2 actions 
based on timing, but always using the current roots, we may rethink, due to the 
email delivered by Mozilla yesterday, if the mid term solution has to be 
changed and instead of doing for the current roots, this has to be done for new 
roots, which would mean a longer delay because would need to almost start from 
scratch.



We´d like to hear from Mozilla in this regard and if so, would allow Startcom 
some more time.



Anyway, this remediation plan is to be executed by all means, but would like to 
be sure about the mid term solution.





Regards,

Iñigo Barreira

CEO

StartCom CA limited



___
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 2016-10-14 10:19, Nick Lamb wrote:

On Friday, 14 October 2016 02:21:36 UTC+1, Matt Palmer  wrote:

Will there be any requirements around the qualification status of the logs,
or could anyone who wanted to be "nice" just stand up a log, and have these
CAs obtain precerts from them?


I don't think Mozilla has declared any specific requirements, but presumably 
they would expect to choose the same or similar criteria as Google's Chrome 
which you're already aware of but I'll link for anybody else

https://www.chromium.org/Home/chromium-security/certificate-transparency/log-policy

For the immediate purpose here (allowing broad oversight over what the new CA is 
issuing) some of these criteria are less important, e.g. the >99% uptime may be 
less important because oversight would be done via a monitor, but Mozilla intends 
to add SCT-checking to Firefox, at which point all the criteria will be important.


I think the 99% uptime is important. They need to be able to submit new 
certificates to it. This is clearly needed if embedding the SCTs is 
required. But I guess it's more important to the CA in that case than it 
is to Mozilla.



Kurt


___
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

[Gervase Markham]

On 14/10/16 02:20, Matt Palmer wrote:
> Will there be any requirements around the qualification status of the logs,
> or could anyone who wanted to be "nice" just stand up a log, and have these
> CAs obtain precerts from them?

Log qualification is a Chrome concept - it means "suitable for being
trusted by Chrome". When and if Firefox supports CT checking, we may
also need our own list of qualified logs, which may or may not be
related to the Chrome list, and we would have our own requirements for
how many SCTs need to be included, which again may or may not be related
to Chrome's requirements.

But before those things happen, it seems inappropriate to me to place
restrictions on the choice of CT server based on Chrome's log list.
Google may do so, of course, but that's up to them.

We do, of course, require that the CT server not be defective - i.e. not
be proved to be evil :-)

Gerv

___
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

[Rob Stradling]

On 13/10/16 20:52, Gervase Markham wrote:

> StartCom/WoSign have indicated ro me that they may have trouble
> complying with the non-Google log requirement because it's hard to find
> a non-Google log which can scale sufficiently. I suggest we allow them
> some leeway on this but they need to demonstrate evidence of efforts to
> meet the requirement.

Gerv, does Mozilla need to make a final decision on this point immediately?

I very much hope that there will be more CT logs by the time StartCom
and/or WoSign are readmitted into Mozilla's trust list.  Why not delay
making this decision until nearer that time?

Alternatively, why not just rely on the mechanisms built into CT for
detecting log misbehaviour?  ;-)

> If anyone reading controls a CT log which could accept their volume,
> even for payment, please contact StartCom/WoSign and let Mozilla know
> you have done so.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
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

[Gervase Markham]

On 14/10/16 10:41, Rob Stradling wrote:
> Gerv, does Mozilla need to make a final decision on this point immediately?
> 
> I very much hope that there will be more CT logs by the time StartCom
> and/or WoSign are readmitted into Mozilla's trust list.  Why not delay
> making this decision until nearer that time?

We don't have to make a decision, in that we are not going to mandate a
particular log. We have just set some criteria. If those criteria are
easier to meet by the time StartCom/WoSign have to meet them, then great
:-)

Gerv

___
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

[Gervase Markham]

On 13/10/16 23:42, Nick Lamb wrote:
> Please can Mozilla ensure that both EY Hong Kong and the overarching
> parent organisation in the United Kingdom (in Southwark) are informed
> of this ban and get a copy of Mozilla's findings if they haven't
> already ?

This is a good idea; I will try and figure out who to tell.

Gerv

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

Re: StartCom & Qihoo Incidents

[Gervase Markham]

On 12/10/16 20:11, Ryan Sleevi wrote:
> As Gerv suggested this was the official call for incidents with
> respect to StartCom, it seems appropriate to start a new thread.

There are indeed more of these than I remember or knew about. Perhaps it
would have been sensible to start a StartCom issues list earlier. In my
defence, investigating one CA takes up a lot of time on its own, let
alone two :-)

> K) StartCom impersonating mozilla.com.
> https://bugzilla.mozilla.org/show_bug.cgi?id=471702 StartCom's
> (former) CEO Eddy Nigg obtained a key and certificate for
> www.mozilla.com and placed it on an Internet-facing server.

I do consider it a significant error of judgement for Eddy to have
chosen www.mozilla.com, rather than a site owned and controlled by him
or by a third party with whom he had an agreement, for his demonstration.

On the other hand, this happened 8 years ago. I'd be interested in your
comments, Ryan, on whether you think it's appropriate for us to have
some sort of informal "statute of limitations". That is to say, in
earlier messages you were worried about favouring incumbents. But if
there is no such statute, doesn't that disadvantage incumbents? No code
is bug-free, and so a large CA with many products is going to have
occasional troubles over the years. If they then have a larger issue, is
it reasonable to go trawling back 10 years through the archives and pull
out every problem there's ever been? This is a genuine question, not a
rhetorical one.

All the WoSign issues I documented where the past two years. Many of the
StartCom issues you list are 2.5 - 3.5 years old. That may not be long
enough, but how long is?

Gerv

___
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

[Rob Stradling]

On 14/10/16 10:50, Gervase Markham wrote:
> On 14/10/16 10:41, Rob Stradling wrote:
>> Gerv, does Mozilla need to make a final decision on this point immediately?
>>
>> I very much hope that there will be more CT logs by the time StartCom
>> and/or WoSign are readmitted into Mozilla's trust list.  Why not delay
>> making this decision until nearer that time?
> 
> We don't have to make a decision, in that we are not going to mandate a
> particular log. We have just set some criteria. If those criteria are
> easier to meet by the time StartCom/WoSign have to meet them, then great
> :-)

Sure, but aren't we talking about specifying criteria for which log(s)
StartCom/WoSign _can't_ use in future?

If Mozilla would prefer to forbid StartCom/WoSign from using their own
or each other's logs, then ISTM that it would be best to specify
criteria that is conditional on the future state of the CT ecosystem:
e.g., "StartCom/WoSign must not use their own or each other's logs,
unless no other browser-accepted log accepts their roots"

If the criteria can't be conditional, then I think you'd end up with...
"StartCom/WoSign may use their own logs forever, because there was a
dearth of any other non-Google logs available to them in October 2016"

...that is, unless you say...
"StartCom/WoSign must not use their own or each other's logs.  This
policy may be revised in the future".

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

StartCom remediation plan

[Inigo Barreira]

All,











In this link, 
https://www.startssl.com/report/StartCom_Remediation_Plan_14102016.pdf, you´ll 
find the detailed remediation plan for StartCom as was notified last week. It 
took us some time to have all the people needed for these tasks and clarify the 
dates for fixing all the possible findings.







StartCom considers this plan accurate and enough to the Mozilla community, 
specially for their users base, to regain and keep the confidence on our 
capacity as a trusted CA.











In the plan you all can see that regarding the PKI system, there are 2 actions 
based on timing, but always using the current roots, we may rethink, due to the 
email delivered by Mozilla yesterday, if the mid term solution has to be 
changed and instead of doing for the current roots, this has to be done for new 
roots, which would mean a longer delay because would need to almost start from 
scratch.







We´d like to hear from Mozilla in this regard and if so, would allow Startcom 
some more time.







Anyway, this remediation plan is to be executed by all means, but would like to 
be sure about the mid term solution.











Regards,



Iñigo Barreira



CEO



StartCom CA limited



___
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

[okaphone . elektronika]

99% uptime sounds good but it allows being down for three and half days in a 
year. It's not actually a very high availabillity. ;-)

CU Hans
___
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

[Gervase Markham]

On 14/10/16 11:37, Rob Stradling wrote:
> Sure, but aren't we talking about specifying criteria for which log(s)
> StartCom/WoSign _can't_ use in future?
> 
> If Mozilla would prefer to forbid StartCom/WoSign from using their own
> or each other's logs, then ISTM that it would be best to specify
> criteria that is conditional on the future state of the CT ecosystem:
> e.g., "StartCom/WoSign must not use their own or each other's logs,
> unless no other browser-accepted log accepts their roots"

I think the rule we are putting in place is that: "StartCom/WoSign
SHOULD NOT fulfil the non-Google log requirement by using logs that they
run themselves. For as long as they do so, they will need to demonstrate
ongoing evidence of efforts to get other logs to take their volume, and
why those efforts have not been successful."

Is that better?

Gerv

___
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

[Gervase Markham]

On 14/10/16 15:46, Gervase Markham wrote:
> I think the rule we are putting in place is that: "StartCom/WoSign
> SHOULD NOT fulfil the non-Google log requirement by using logs that they
> run themselves. For as long as they do so, they will need to demonstrate
> ongoing evidence of efforts to get other logs to take their volume, and
> why those efforts have not been successful."

I should add that if StartCom/WoSign have a CT log codebase capable of
taking the volume necessary, they could always open source it, and then
pay a 3rd party to run an instance of it, with an arms-length contract.
That sort of solution may well be acceptable, depending on contract details.

Gerv

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

Re: StartCom remediation plan

[Gervase Markham]

Hi Inigo,

On 14/10/16 09:16, Inigo Barreira wrote:
> In this link,
> https://www.startssl.com/report/StartCom_Remediation_Plan_14102016.pdf,
> you´ll find the detailed remediation plan for StartCom as was notified last
> week. 

Thanks for this. Is this a correct summary of the situation as regards
the origin of the codebases?

Website/Ordering System

Before: WoSign-authored, but not the same as the one WoSign uses
After:  Same WoSign-authored code, audited and improved by Qihoo R&D

CMS

Before: WoSign-authored, but not the same as the one WoSign uses
After:  Same WoSign-authored code, audited and improved by Qihoo R&D

PKI

Before: WoSign-authored, same code that WoSign uses
After:  StartCom-authored, improved by Qihoo R&D (short term)
Third-party solution (medium term)

OCSP/CRL

Before: WoSign-authored, same code that WoSign uses
After:  Same WoSign-authored code, audited and improved by Qihoo R&D


From my perspective, the "technical separation" part is more than just
"not using the same servers WoSign uses" or "not running the same code
that WoSign runs". One of the things we have lost confidence in is the
coding of the WoSign development team, and therefore any piece of code
remaining which they wrote is suspect - no matter whether it is
StartCom-specific or also run by WoSign.

Given that, it is concerning that after your plan is executed, 3 of the
4 key systems will still be running WoSign-authored codebases, even if
they have been audited and improved to some degree by Qihoo R&D. For
each system where that is true, I think that Mozilla may wish to require
a full external security audit, which would both be expensive and
time-consuming (and may lead to a great deal of remediation required).

Was consideration given to switching back to the old StartCom codebase,
or buying in a third party solution, for the website, the CMS or the
OCSP/CRL function?

Gerv
___
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

[Rob Stradling]

On 14/10/16 15:46, Gervase Markham wrote:
> On 14/10/16 11:37, Rob Stradling wrote:
>> Sure, but aren't we talking about specifying criteria for which log(s)
>> StartCom/WoSign _can't_ use in future?
>>
>> If Mozilla would prefer to forbid StartCom/WoSign from using their own
>> or each other's logs, then ISTM that it would be best to specify
>> criteria that is conditional on the future state of the CT ecosystem:
>> e.g., "StartCom/WoSign must not use their own or each other's logs,
>> unless no other browser-accepted log accepts their roots"
> 
> I think the rule we are putting in place is that: "StartCom/WoSign
> SHOULD NOT fulfil the non-Google log requirement by using logs that they
> run themselves. For as long as they do so, they will need to demonstrate
> ongoing evidence of efforts to get other logs to take their volume, and
> why those efforts have not been successful."
> 
> Is that better?

SGTM.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

Re: StartCom remediation plan

[谭晓生]

Dear Gerv,

We’ll rewrite all the code with different programing language or buy 3rd party 
components (for example: PKI), Wosign team using .Net, but my team never use 
.Net, they are good at C/C++ and PHP, Python.

Thanks，
Xiaosheng Tan



在 2016/10/14 下午11:01，“dev-security-policy 代表 Gervase 
Markham” 写入:

Hi Inigo,

On 14/10/16 09:16, Inigo Barreira wrote:
> In this link,
> https://www.startssl.com/report/StartCom_Remediation_Plan_14102016.pdf,
> you´ll find the detailed remediation plan for StartCom as was notified 
last
> week. 

Thanks for this. Is this a correct summary of the situation as regards
the origin of the codebases?

Website/Ordering System

Before: WoSign-authored, but not the same as the one WoSign uses
After:  Same WoSign-authored code, audited and improved by Qihoo R&D

CMS

Before: WoSign-authored, but not the same as the one WoSign uses
After:  Same WoSign-authored code, audited and improved by Qihoo R&D

PKI

Before: WoSign-authored, same code that WoSign uses
After:  StartCom-authored, improved by Qihoo R&D (short term)
Third-party solution (medium term)

OCSP/CRL

Before: WoSign-authored, same code that WoSign uses
After:  Same WoSign-authored code, audited and improved by Qihoo R&D


From my perspective, the "technical separation" part is more than just
"not using the same servers WoSign uses" or "not running the same code
that WoSign runs". One of the things we have lost confidence in is the
coding of the WoSign development team, and therefore any piece of code
remaining which they wrote is suspect - no matter whether it is
StartCom-specific or also run by WoSign.

Given that, it is concerning that after your plan is executed, 3 of the
4 key systems will still be running WoSign-authored codebases, even if
they have been audited and improved to some degree by Qihoo R&D. For
each system where that is true, I think that Mozilla may wish to require
a full external security audit, which would both be expensive and
time-consuming (and may lead to a great deal of remediation required).

Was consideration given to switching back to the old StartCom codebase,
or buying in a third party solution, for the website, the CMS or the
OCSP/CRL function?

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


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

Re: StartCom remediation plan

[Gervase Markham]

Hi Xiaosheng,

On 14/10/16 16:06, 谭晓生 wrote:
> We’ll rewrite all the code with different programing language or buy
> 3rd party components (for example: PKI), Wosign team using .Net, but
> my team never use .Net, they are good at C/C++ and PHP, Python.

It would be great to be clear about what the plan in each case - whether
it's a "audit, check and review" of the existing codebase, or whether
it's a rewrite, or whether it's a 3rd party implementation.

The deadlines in the document are:

Website:  Dec 31st 2016
CMS:  Dec 31st 2016
PKI:  Dec 1st 2016 (replace with StartCom version)
  Feb 2017 (implement 3rd party)
OCSP/CRL: Dec 1st 2016

There are only six weeks between now and Dec 1st 2016. There is no way
your team, no matter how big or skilled it is, can safely and securely
write a new OCSP/CRL system in six weeks, and then finish a website and
a CMS four weeks after that. Even if Python is awesome ;-)

Gerv

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

Re: StartCom remediation plan

[Han Yuwei]

在 2016年10月14日星期五 UTC+8下午11:23:10，Gervase Markham写道：
> Hi Xiaosheng,
> 
> On 14/10/16 16:06, 谭晓生 wrote:
> > We’ll rewrite all the code with different programing language or buy
> > 3rd party components (for example: PKI), Wosign team using .Net, but
> > my team never use .Net, they are good at C/C++ and PHP, Python.
> 
> It would be great to be clear about what the plan in each case - whether
> it's a "audit, check and review" of the existing codebase, or whether
> it's a rewrite, or whether it's a 3rd party implementation.
> 
> The deadlines in the document are:
> 
> Website:  Dec 31st 2016
> CMS:  Dec 31st 2016
> PKI:  Dec 1st 2016 (replace with StartCom version)
>   Feb 2017 (implement 3rd party)
> OCSP/CRL: Dec 1st 2016
> 
> There are only six weeks between now and Dec 1st 2016. There is no way
> your team, no matter how big or skilled it is, can safely and securely
> write a new OCSP/CRL system in six weeks, and then finish a website and
> a CMS four weeks after that. Even if Python is awesome ;-)
> 
> Gerv

There's no any open-source solution? Maybe Mozilla could build one?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom remediation plan

[Christian Felsing]

Am 14.10.2016 um 17:25 schrieb Han Yuwei:
> There's no any open-source solution? Maybe Mozilla could build one?

Hi,

maybe EJBCA (https://www.ejbca.org/) could be a solution for your problem.

Christian


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

Re: StartCom & Qihoo Incidents

[Ryan Sleevi]

On Friday, October 14, 2016 at 3:01:16 AM UTC-7, Gervase Markham wrote:
> There are indeed more of these than I remember or knew about. Perhaps it
> would have been sensible to start a StartCom issues list earlier. In my
> defence, investigating one CA takes up a lot of time on its own, let
> alone two :-)

10 minutes with "site:bugzilla.mozilla.org StartCom"

Which was only possible due to the many Mozilla contributors who, when they saw 
something improper, filed bugs. I just want to make sure to thank all of the 
contributors who have done so, and hopefully continue to do so.

> On the other hand, this happened 8 years ago. I'd be interested in your
> comments, Ryan, on whether you think it's appropriate for us to have
> some sort of informal "statute of limitations". That is to say, in
> earlier messages you were worried about favouring incumbents. But if
> there is no such statute, doesn't that disadvantage incumbents? No code
> is bug-free, and so a large CA with many products is going to have
> occasional troubles over the years. If they then have a larger issue, is
> it reasonable to go trawling back 10 years through the archives and pull
> out every problem there's ever been? This is a genuine question, not a
> rhetorical one.

Right, I had the same question when investigating. We know Eddy's position on 
it ('It was in the past, get over it' - if I may so aggressively strawman). I 
suppose a core question is: What is the goal of the root program? Should there 
be a higher bar for removing CAs than adding them? Does trust increase or 
decrease over time?

That is, I can totally see the argument that frequently adding new CAs is bad, 
because new CAs may not have the organizational or operational experience to 
meet the high bar expected of CAs. We frequently see this with addition 
requests - CAs well below what the community standard might be. In this model, 
the more time passes, the more institutional knowledge and expertise the 
organization develops, the better users are protected by keeping CAs in longer 
(and allowing them to remediate).

Another view is that we want a consistent bar, and that means CAs that fall 
short of that should be culled, regardless of age of the CA. This model 
suggests that a longitudinal analysis of a CA's operation is necessary - that 
we must never forget past mistakes when evaluating current mistakes or in 
predicting future mistakes.

We can hopefully assume that CA are rare, at least for an individual CA, and so 
we may never get sufficient samples to accurately predict future behaviour. 
Analyzing a longer period of time gives us data to establish a pattern and 
trend, but also disadvantages those who go through 'growing pains' on their way 
to becoming a mature CA.

I don't have a good answer for your question in the general case, for reasons 
hopefully explained, but I think towards the question of predicting 
responsiveness to incidents, and how they'll be treated, I think the longer 
analysis of StartCom is useful for the discussion. My own gut is that the 
ecosystem is better served if we look at the whole of a CA's operation. My view 
is that the theory that experience is developed over time is one not borne out 
by practice - what we see instead is the same players from existing CAs 
shifting around to different organizations.

> All the WoSign issues I documented where the past two years. Many of the
> StartCom issues you list are 2.5 - 3.5 years old. That may not be long
> enough, but how long is?

Well, the past year it's been run by WoSign, so 2.5 - 3.5 years really reflects 
the past 1.5 to 2.5 years of independent operation, right?
___
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

[Percy]

On Wednesday, October 12, 2016 at 8:12:29 PM UTC-7, Percy wrote:
> WoSign has so far announced nothing about those incidents or immediate 
> distrust (Apple and Mozilla) to its end users. On the contrary, WoSign had a 
> press release dated Oct 8th 
> (https://www.wosign.com/news/netcraft-ssl-oct.htm) titled "WoSign SSL certs 
> reaches almost 50% market share in China". In the press release, it stated 
> that "WoSign's achievement today is due to company founder and CEO Richard 
> Wang leads all staff to be dedicated". WoSign is depicted as this positive, 
> strong growing company. Nothing about its distrust in the immediate future is 
> mentioned. 
> 
> In Oct 7th, in the incident report in English, WoSign admitted multiple 
> intentional mistakes and deceptions  
> (https://www.google.com/url?q=https%3A%2F%2Fwww.wosign.com%2Freport%2FWoSign_Incident_Report_Update_07102016.pdf&sa=D&sntz=1&usg=AFQjCNGRzAxwYrEEiA_SN5gfcsftSst0nA)
>  and that the CEO Richard Wang to be relieved of its duties. 
> 
> I'm calling WoSign out on this two-faced behavior towards Chinese end users 
> and foreign security researchers.

WoSign and StartCom are still actively selling certs which cost one hundreds or 
more dollars. I think Mozilla should mandate that WoSign/StartCom inform their 
users of such incidents or at least the imminent distrust by Mozilla (and 
Apple). Now users are left in the dark for those trust decisions which violates 
the minimum disruption principle.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[Eddy Nigg]

On 10/14/2016 01:00 PM, Gervase Markham wrote:

K) StartCom impersonating mozilla.com.
https://bugzilla.mozilla.org/show_bug.cgi?id=471702 StartCom's
(former) CEO Eddy Nigg obtained a key and certificate for
www.mozilla.com and placed it on an Internet-facing server.

I do consider it a significant error of judgement for Eddy to have
chosen www.mozilla.com, rather than a site owned and controlled by him
or by a third party with whom he had an agreement, for his demonstration.


Well, at time I didn't think that much - I noticed it when requesting a 
certificate for startcom.org in order to investigate a completely 
different issue and later got one for mozilla.org (note it wasn't .com). 
Initially I thought about some really high-profile name, but then I 
tried with mozilla.org since I assumed that A) Mozilla will forgive me 
and B) I was frequently involved here at that time. :-)


Surprisingly it worked and I got my certificate for mozilla.org


On the other hand, this happened 8 years ago. I'd be interested in your
comments, Ryan, on whether you think it's appropriate for us to have
some sort of informal "statute of limitations". That is to say, in
earlier messages you were worried about favouring incumbents. But if
there is no such statute, doesn't that disadvantage incumbents? No code
is bug-free, and so a large CA with many products is going to have
occasional troubles over the years. If they then have a larger issue, is
it reasonable to go trawling back 10 years through the archives and pull
out every problem there's ever been? This is a genuine question, not a
rhetorical one.


I believe there is also something called "reasonability " - I believe 
during my tenure StartCom tried to reduce risks first and foremost 
through its policies, honestly and earnest. And then unintentional 
mistakes and issues can happen


Of course every CA wants to issue hundreds of thousands of certificates, 
but it usually doesn't start like this. I admit that some of the issues 
were due to growth pain, scalability or simply doesn't happen below a 
certain number of users/certificates. Any programmer working on larger 
scale projects and long enough in the profession can tell some stories 
about bugs that happen only every 50K or 50M time.


I don't want to offer cheap excuses, but reality has it that things do 
happen and this is also part of that "reasonability". CAs must however 
have policies and procedures in order to evaluate issues that do happen, 
make the correct assessment and deliver a reasonable solution based 
thereof. This is the logic of a correctly functioning CA (or other 
businesses for that matter), this is what auditors verify and what 
software vendors should expect.


There is no business, no software and no certificate authority without 
fault - realistically and reasonably.


--
Regards
Signer: Eddy Nigg, Founder
StartCom Ltd. 
XMPP:   start...@startcom.org 

___
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

[Ryan Sleevi]

On Thursday, October 13, 2016 at 9:50:02 AM UTC-7, Kathleen Wilson wrote:
> 1) Distrust certificates chaining up to Affected Roots with a notBefore date 
> after October 21, 2016. If additional back-dating is discovered (by any 
> means) to circumvent this control, then Mozilla will immediately and 
> permanently revoke trust in the Affected Roots.
> -- This change will go into the Firefox 51 release train [4]. 
> -- The code will use the subject key id (hash of public key) to identify the 
> Affected Roots, so that the control will also apply to cross-certs of the 
> Affected Roots.
> 2) Add the previously identified backdated SHA-1 certs chaining up to the 
> Affected Roots to OneCRL.
> 3) No longer accept audits carried out by Ernst & Young Hong Kong.
> 4) Remove the Affected Roots from NSS after the SSL certificates issued 
> before October 1, 2016, have expired or have been replaced.

Hi Kathleen,

I appreciate the thoughtfulness and time spent on reviewing and considering the 
feedback and the incident. At the risk of asking you to do even more work, 
would it possible to ask that you expand a bit more on the reasoning behind 
this proposal?

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.

>From an outsider perspective, it would appear the reasoning is to minimize any 
>negative impact on existing WoSign customers, which in turn minimizes any 
>impact on Firefox users, by assuming that all (but a few) of the existing 
>certificates were correctly issued and reamin trustworthy. Is that a fair 
>statement?

It seems to accomplish this, you're willing to continue to trust that WoSign 
will not demonstrate any of the past behaviours it already demonstrated - such 
as backdating and misissuance, but not to issue new certificates. Is that 
correct?

I ask because it seems to be a very challenging position - we don't necessarily 
trust that new certificates will abide by the policies, but at the same time, 
we need to trust that they'll abide by the new policies and not issue any new 
certificates. Is that a fair statement of the conflict?

Thinking back to Mozilla's core principles, I'm curious how you weigh the risk 
to Firefox users versus the overall ecosystem risk. For example, many consumers 
of NSS-based trust stores have only the logic to trust (by inclusion) or 
distrust (by omission or by distrust records). This is true for applications 
like OpenSSL-/GnuTLS-based applications, but also true for other root stores 
and programs (for example, both Windows and Android, in their mass-deployed 
versions, lack more extensive capabilities). As a consequence of this - which, 
to be fair, is not a problem of Mozilla's creation - there exists the ecosystem 
risk that in order to minimize any incompatibilities, these applications will 
need to continue to trust WoSign and StartCom for as long as other popular 
programs - such as Mozilla - do. If these applications/devices lack the 
capability to distrust new certificates, as Mozilla plans to implement, then it 
means they may face risk that Mozilla users may not.

While again, I want to emphasize this is not a problem of Mozilla's creation, 
I'm curious how considerations such as other applications' behaviour is 
weighted in such decisions. As a concrete example, if it was weighted 
particularly high (that is, ecosystem good were seen to be as-valuable-or-more 
than the individual good to Firefox/Mozilla users), then it might be more 
desirable to have an accelerated plan to move Firefox to full distrust, rather 
than minimizing Firefox impact. For example, fully distrusting these 
certificates in, say, 6 months, would allow other players in the ecosystem to 
take appropriate steps and block these certificates, without having to suffer 
the first-mover/only-mover problem.

I understand this is somewhat unique, as notable other programs have not fully 
announced what they're intending, perhaps because they're allowing Mozilla the 
opportunity to lead the public discussion and investigation, but if other 
programs were concerned about the trustworthiness of WoSign and the ability to 
abide with a requirement to not issue new certificates, would you consider a 
path that moved to a full distrust (of both new and existing) in a more 
accelerated fashion, if it was not Mozilla moving alone?
___
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

[Hanno Böck]

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.


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

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


pgp3HxEEpd6Tt.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: Remediation Plan for WoSign and StartCom

[Ryan Sleevi]

On Friday, October 14, 2016 at 2:24:37 PM UTC-7, Hanno Böck wrote:
> 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.

Well, there's a spectrum, right? That's been discussed on the list - whether a 
whitelist of a portion of certificates, as part of an overall phase down, is 
viable.

Clearly, there's a spectrum of options - which range from no impact whatsoever 
to clients (e.g. continue trusting indefinitely) to immediate impact (complete 
distrust). I was mostly trying to figure out what criteria were being weighted 
/ how the choice of where to end on the spectrum was chosen.

As it stands, it seems a little inconsistent with respect to security 
messaging, and seems to leave Mozilla clients at risk (of backdating), but it 
avoids any impact to sites/users. Alternatively, Mozilla might choose to more 
consistently/aggressively protect users, but with the corresponding impact to 
sites/users. And then there's the broader discussion of whether or not Mozilla 
feels it should strive to protect non-Mozilla users, or if that's an 
externality that cannot be accounted for, or somewhere in between.

I apologize if I wasn't clearer, but I was trying to communicate that there are 
a number of notable, non-Mozilla platforms, that don't support whitelisting. So 
the only viable solution for them is full trust or full distrust (these 
platforms have the ability to update trust, but not to add more nuanced 
options. This is the case for Windows and Android, for example). So a Mozilla 
option that leaves partial trust, these other players must consider either full 
trust or full distrust - and that's the ecosystem challenge.

> *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.)

It was quite some time, and outside of the free cert realm, it certainly was 
easier to get 3year certs. As noted elsewhere, the proposal would basically 
involve trusting for 3y.
___
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]

Ryan Sleevi  writes:

>What is the goal of the root program? Should there be a higher bar for
>removing CAs than adding them? Does trust increase or decrease over time?

Another thing I'd like to bring up is the absolute silence of the CAB forum
over all this.  Apple have quietly unilaterally distrusted, Mozilla have
debated at length (three months now) and are taking action, but the regulatory
body that should be taking charge, the CAB forum, has (apparently) taken
absolutely no action.

Does anyone know the position among other browser vendors, Chrome, IE, Opera,
Konqueror, Chromium, Midori, the dozen or more forks of various bigger
browsers, the dozens(?) of mobile browsers, and so on.

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

Re: StartCom & Qihoo Incidents

[Peter Bowen]

On Fri, Oct 14, 2016 at 3:44 PM, Peter Gutmann
 wrote:
> Ryan Sleevi  writes:
>
>>What is the goal of the root program? Should there be a higher bar for
>>removing CAs than adding them? Does trust increase or decrease over time?
>
> Another thing I'd like to bring up is the absolute silence of the CAB forum
> over all this.  Apple have quietly unilaterally distrusted, Mozilla have
> debated at length (three months now) and are taking action, but the regulatory
> body that should be taking charge, the CAB forum, has (apparently) taken
> absolutely no action.

The CA/Browser Forum is not a regulatory body.  They publish
guidelines but do not set requirements nor regulate compliance.  The
Forum does not require that members follow the Forum guidelines; it
only requires that they are either a browser or CA operator following
the basic WebTrust requirements or ETSI requirements.

What action would you expect the Forum to be taking?

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

Re: StartCom & Qihoo Incidents

[Ryan Sleevi]

On Friday, October 14, 2016 at 3:44:50 PM UTC-7, Peter Gutmann wrote:
> Another thing I'd like to bring up is the absolute silence of the CAB forum
> over all this. 

It has not been.

> Apple have quietly unilaterally distrusted, Mozilla have
> debated at length (three months now) and are taking action, 

mid-August to mid-October is not three months.

> but the regulatory body that should be taking charge, the CAB forum, 

The CA/B Forum is not a regulatory body.

> has (apparently) taken absolutely no action.

What action is there for the Forum to take, if your description (though 
inaccurate) was accepted?

> Does anyone know the position among other browser vendors, Chrome, IE, 

IE > Edge

> Opera, Konqueror, Chromium, Midori,

You treated three Chromium-based browsers (Opera, Chrome, Chromium) as 
distinct, and referenced two others (Konqueror, Midori) which have yet to 
manage their own root store or policies.

___
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]

Ryan Sleevi  writes:
>On Friday, October 14, 2016 at 3:44:50 PM UTC-7, Peter Gutmann wrote:
>> Another thing I'd like to bring up is the absolute silence of the CAB forum
>> over all this. 
>
>It has not been.

I haven't heard anything from them.  If they've made any statements, they've
been very quiet about it.

>> Apple have quietly unilaterally distrusted, Mozilla have
>> debated at length (three months now) and are taking action, 
>
>mid-August to mid-October is not three months.

August, September, October, seems like three to me.

>[blah blah blah nitpick nitpick nitpick]

Response, response, response, boring boring boring.

Any chance of answering my question?  What's the CAB forum doing? What are
other browser vendors doing?

Peter.
___
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]

Peter Bowen  writes:

>The CA/Browser Forum is not a regulatory body.  They publish guidelines but
>do not set requirements nor regulate compliance.

It's a bit hard to describe its actual functioning, in theory they just
advise, but then so does ISO, IEEE, and others.  They're not regulatory bodies
either, but when ISO or IEEE says X you do it.

>What action would you expect the Forum to be taking?

I would have expected some sort of coordinating action to provide a unified
response to the issue and corresponding unified, consistent behaviour among
the browsers, rather than the current lottery as to what a particular browser
(other than Apple and Mozilla's ones) will do when it encounters a WoSign
cert.

Then there's the bigger question that if the CAB can't do anything about a CA
going rogue (fraudulently issuing certs to evade restrictions), does that mean
the web PKI is just a free-for-all?  Who's running the show if it's not the
CAB?

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

Re: StartCom & Qihoo Incidents

[Peter Bowen]

On Fri, Oct 14, 2016 at 4:32 PM, Peter Gutmann
 wrote:
> Peter Bowen  writes:
>
>>The CA/Browser Forum is not a regulatory body.  They publish guidelines but
>>do not set requirements nor regulate compliance.
>
> It's a bit hard to describe its actual functioning, in theory they just
> advise, but then so does ISO, IEEE, and others.  They're not regulatory bodies
> either, but when ISO or IEEE says X you do it.
>
>>What action would you expect the Forum to be taking?
>
> I would have expected some sort of coordinating action to provide a unified
> response to the issue and corresponding unified, consistent behaviour among
> the browsers, rather than the current lottery as to what a particular browser
> (other than Apple and Mozilla's ones) will do when it encounters a WoSign
> cert.
>
> Then there's the bigger question that if the CAB can't do anything about a CA
> going rogue (fraudulently issuing certs to evade restrictions), does that mean
> the web PKI is just a free-for-all?  Who's running the show if it's not the
> CAB?

As I wrote to someone else recently, there is no single or common "Web
PKI".  There are numerous PKIs operated by dozens of different
organizations and a number of privately managed trust anchor lists
(Adobe, Apple, Blackberry, Google, Microsoft, Mozilla, Opera, Oracle,
and many others). The contents of each trust anchor list vary and each
list maintainer has their own policies on what CAs they will include
under what circumstances.

The CA/Browser Forum doesn't even legally exist (it isn't an entity)
and you will note the bylaws (https://cabforum.org/bylaws/) have an
anti-trust statement that lays out a number of things not discussed or
coordinated.  Which CAs to accept is not coordinated between trust
anchor list maintainers - they each make their own decisions.

If some neutral organization wanted to publish a trust anchor list
that others could use, great.  Maybe browsers would choose to leave it
up to that org to choose which CAs are trusted.  But that isn't how it
works today.

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

Re: StartCom & Qihoo Incidents

[Erwann Abalea]

Le samedi 15 octobre 2016 01:33:05 UTC+2, Peter Gutmann a écrit :
> Peter Bowen  writes:
> 
> >The CA/Browser Forum is not a regulatory body.  They publish guidelines but
> >do not set requirements nor regulate compliance.
> 
> It's a bit hard to describe its actual functioning, in theory they just
> advise, but then so does ISO, IEEE, and others.  They're not regulatory bodies
> either, but when ISO or IEEE says X you do it.

Not that hard in fact.
ISO/IEEE/ETSI/CABF write guidelines and recommendations, which you're free to 
follow or not.
A regulatory body says: you must follow recommendation X and Y or Z from 
ISO/IEEE/... to be part of my club.

Here, browser vendors are regulatory bodies, and take a suitable combination of 
ETSI+WebTrust+CABF recos that CAs are required to follow.

> >What action would you expect the Forum to be taking?
> 
> I would have expected some sort of coordinating action to provide a unified
> response to the issue and corresponding unified, consistent behaviour among
> the browsers, rather than the current lottery as to what a particular browser
> (other than Apple and Mozilla's ones) will do when it encounters a WoSign
> cert.

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.

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

> Then there's the bigger question that if the CAB can't do anything about a CA
> going rogue (fraudulently issuing certs to evade restrictions), does that mean
> the web PKI is just a free-for-all?  Who's running the show if it's not the
> CAB?

Browsers.
___
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

[Erwann Abalea]

Bonsoir,

Le vendredi 14 octobre 2016 22:21:44 UTC+2, Ryan Sleevi a écrit :
> On Thursday, October 13, 2016 at 9:50:02 AM UTC-7, Kathleen Wilson wrote:
> > 1) Distrust certificates chaining up to Affected Roots with a notBefore 
> > date after October 21, 2016. If additional back-dating is discovered (by 
> > any means) to circumvent this control, then Mozilla will immediately and 
> > permanently revoke trust in the Affected Roots.
> > -- This change will go into the Firefox 51 release train [4]. 
> > -- The code will use the subject key id (hash of public key) to identify 
> > the Affected Roots, so that the control will also apply to cross-certs of 
> > the Affected Roots.
> > 2) Add the previously identified backdated SHA-1 certs chaining up to the 
> > Affected Roots to OneCRL.
> > 3) No longer accept audits carried out by Ernst & Young Hong Kong.
> > 4) Remove the Affected Roots from NSS after the SSL certificates issued 
> > before October 1, 2016, have expired or have been replaced.
> 
> Hi Kathleen,
> 
> I appreciate the thoughtfulness and time spent on reviewing and considering 
> the feedback and the incident. At the risk of asking you to do even more 
> work, would it possible to ask that you expand a bit more on the reasoning 
> behind this proposal?
> 
> 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.
> 
> >From an outsider perspective, it would appear the reasoning is to minimize 
> >any negative impact on existing WoSign customers, which in turn minimizes 
> >any impact on Firefox users, by assuming that all (but a few) of the 
> >existing certificates were correctly issued and reamin trustworthy. Is that 
> >a fair statement?
> 
> It seems to accomplish this, you're willing to continue to trust that WoSign 
> will not demonstrate any of the past behaviours it already demonstrated - 
> such as backdating and misissuance, but not to issue new certificates. Is 
> that correct?
> 
> I ask because it seems to be a very challenging position - we don't 
> necessarily trust that new certificates will abide by the policies, but at 
> the same time, we need to trust that they'll abide by the new policies and 
> not issue any new certificates. Is that a fair statement of the conflict?

The job of a CA is not only to issue or not issue certificates, it's also to 
maintain revocation status for the previously issued certificates, receive and 
consider revocation requests from anybody, and revoke certificates the CA knows 
are not valid anymore (for a number of reasons listed in the BR at least in 
section 4.9.1.1).
It's agreed that revocation checking is far from perfect, and that's why Google 
and Mozilla have developed CRLSets and OneCRL, which depends on the revocation 
status information published and/or declared by the CAs.

It's then important that the Affected Roots and their subordinate CAs continue 
to follow good practices regarding revocation of subscriber certificates.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy