Remediation Plan for WoSign and StartCom

[Kathleen Wilson]

All,

Thanks again to all of you who have put in so much time and effort to determine what happened with WoSign and StartCom and discuss what to do about it.

Based on the information that I have seen regarding WoSign, I believe that WoSign intentionally bent the rules in order to continue issuing SHA-1 SSL certs, when they knew full well that was no longer allowed. I also believe that the deception continued even after Mozilla directly asked WoSign about this. WoSign has lost my confidence in their ability and intention to follow Mozilla's policies. Therefore, I think we should respond similarly to WoSign as we did to CNNIC [1][2]. Unfortunately, the number of certificates and the timescales involved are such that we prefer not to create a list of the domains for which previously-issued certs that chain up to the Affected Roots may continue to be trusted, so our approach will be a little different, as Gerv previously described[3].

Within this message, the term “Affected Roots” applies to the following 7 root certificates.

1) Subject: CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN
Certificate Serial Number: 50706bcdd813fc1b4e3b3372d211488d
SHA-1 Fingerprint
16:32:47:8D:89:F9:21:3A:92:00:85:63:F5:A4:A7:D3:12:40:8A:D6
SHA-256 Fingerprint
D6:F0:34:BD:94:AA:23:3F:02:97:EC:A4:24:5B:28:39:73:E4:47:AA:59:0F:31:0C:77:F4:8F:DF:83:11:22:54

2) Subject: CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=CN
Certificate Serial Number: 5e68d61171946350560068f33ec9c591
SHA-1 Fingerprint
B9:42:94:BF:91:EA:8F:B6:4B:E6:10:97:C7:FB:00:13:59:B6:76:CB
SHA-256 Fingerprint
4B:22:D5:A6:AE:C9:9F:3C:DB:79:AA:5E:C0:68:38:47:9C:D5:EC:BA:71:64:F7:F2:2D:C1:D6:5F:63:D8:57:08

3) Subject: CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA Limited, C=CN
Certificate Serial Number: 6b25da8a889d7cbc0f05b3b17a614544
SHA-1 Fingerprint
FB:ED:DC:90:65:B7:27:20:37:BC:55:0C:9C:56:DE:BB:F2:78:94:E1
SHA-256 Fingerprint
D4:87:A5:6F:83:B0:74:82:E8:5E:96:33:94:C1:EC:C2:C9:E5:1D:09:03:EE:94:6B:02:C3:01:58:1E:D9:9E:16

4) Subject: CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN
Certificate Serial Number: 684a5870806bf08f02faf6dee8b09090
SHA-1 Fingerprint
D2:7A:D2:BE:ED:94:C0:A1:3C:C7:25:21:EA:5D:71:BE:81:19:F3:2B
SHA-256 Fingerprint
8B:45:DA:1C:06:F7:91:EB:0C:AB:F2:6B:E5:88:F5:FB:23:16:5C:2E:61:4B:F8:85:56:2D:0D:CE:50:B2:9B:02

5) Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
Certificate Serial Number: 01
SHA-1 Fingerprint
3E:2B:F7:F2:03:1B:96:F3:8C:E6:C4:D8:A8:5D:3E:2D:58:47:6A:0F
SHA-256 Fingerprint
C7:66:A9:BE:F2:D4:07:1C:86:3A:31:AA:49:20:E8:13:B2:D1:98:60:8C:B7:B7:CF:E2:11:43:B8:36:DF:09:EA

6) Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
Certificate Serial Number: 2d
SHA-1 Fingerprint
A3:F1:33:3F:E2:42:BF:CF:C5:D1:4E:8F:39:42:98:40:68:10:D1:A0
SHA-256 Fingerprint
E1:78:90:EE:09:A3:FB:F4:F4:8B:9C:41:4A:17:D6:37:B7:A5:06:47:E9:BC:75:23:22:72:7F:CC:17:42:A9:11

7) Subject: CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., C=IL
Certificate Serial Number: 3b
SHA-1 Fingerprint
31:F1:FD:68:22:63:20:EE:C6:3B:3F:9D:EA:4A:3E:53:7C:7C:39:17
SHA-256 Fingerprint
C7:BA:65:67:DE:93:A7:98:AE:1F:AA:79:1E:71:2D:37:8F:AE:1F:93:C4:39:7F:EA:44:1B:B7:CB:E6:FD:59:95

I intend to move forward as follows, unless further information or input causes me to rethink this plan. Therefore, I will continue to appreciate your input, and this discussion is still open.

Mozilla will perform the following 4 actions. I have filed Bugzilla Bug #1309707 to track the engineering work for this. Please keep discussion here in mozilla.dev.security.policy, and not in the bug.

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.

WoSign may apply for inclusion of new (replacement) root certificates following Mozilla's normal root inclusion/change process (minus waiting in the queue for the discussion), after they have completed all of the following action items, and no earlier than June 1, 2017. If StartCom is able to provide proof enough to convince the Mozilla community in the mozilla.dev.security.policy forum that WoSign has no control (people or code) over StartCom, then StartCom may re-apply for inclusion earlier, as soon as the following action items are completed.

1. Provide a list of changes that the CA plans to implement to ensure that there are no future violations of Mozilla Policy and the Baseline Requirements.

2. Implement the changes, and update their CP/CPS to fully document their improved processes. The CP/CPS must explicitly state that it is prohibited to backdate the notBefore of certificates by more than one day.

3. Provide a public-facing attestation from a Licensed WebTrust Practitioner[5] other than EY Hong Kong that the changes have been made. This audit may be part of an annual WebTrust CA audit.

4. Provide auditor attestation that a full performance audit has been performed confirming compliance with the CA/Browser Forum's Baseline Requirements[6]. This audit may be part of an annual WebTrust BR audit. It must include a full security audit of the CA’s issuing infrastructure.

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.

Notes:
* The new (replacement) root certificates may be cross-signed by the Affected Roots. However, the Affected Roots may *not* be cross-signed by the new (replacement) root certificates, because that would bring the concerns about the Affected Roots into the scope of the new roots.
* Mozilla's root inclusion/change process includes checking that certificates in the CA hierarchy comply with the CA/Browser Forum's Baseline Requirements.

Please let me know if I’ve missed anything.

Thanks,
Kathleen

[1] https://blog.mozilla.org/security/2015/04/02/distrusting-new-cnnic-certificates/
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1177209
[3] https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/edit#
[4] https://wiki.mozilla.org/RapidRelease/Calendar
[5] http://www.webtrust.org/licensed-webtrust-practitioners-international/item64419.aspx
[6] https://wiki.mozilla.org/CA:BaselineRequirements

[Jonathan Rudenberg]

On Oct 13, 2016, at 12:49, Kathleen Wilson <kwi...@mozilla.com> 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.

Can you clarify if the notBefore cutoff is October 1, 2016, and not October 21, 2016? There are two conflicting dates in the listed actions.

[Kathleen Wilson]

On Thursday, October 13, 2016 at 10:17:28 AM UTC-7, Jonathan Rudenberg wrote:
> Can you clarify if the notBefore cutoff is October 1, 2016, and
> not October 21, 2016? There are two conflicting dates in the listed actions.

My thinking is that we would distrust certs issued after next week (Oct 21), and that Oct 1 would be sufficient time for any clients to find an alternative solution.

But, as you mention, that may be too confusing, so we should pick one date.

Is there any reason why that date cannot be October 1?

Thanks,
Kathleen

[Han Yuwei]

在 2016年10月14日星期五 UTC+8上午12:50:02，Kathleen Wilson写道：

Is this the final decision or still pending?

[Kathleen Wilson]

On Thursday, October 13, 2016 at 10:39:05 AM UTC-7, Han Yuwei wrote:
>
> Is this the final decision or still pending?

Please consider this the draft of my decision. We are actively working on the Mozilla action items, but this plan is still open for discussion.

Thanks,
Kathleen

[Nick Lamb]

I suggest Mozilla should - at the very least - strongly urge the actual current owners of these CA roots to use their resources to reach out to subscribers informing them of this decision and of its consequences. If it cannot, it should hand over all available contact details for the subscriber to another CA/B member, for them to do that work on behalf of the whole industry.

We know in the SHA-1 threads that subscribers often seem ignorant of important decisions affecting them, and the CA is best placed to contact the subscriber because they're most likely to have useful email addresses, phone numbers etc. that lead to people with the correct mix of technical ability and decision making authority to act.

As it stands currently the plan does not invalidate most (any?) end entity certificates that we believe were legitimately issued and such notification could make that clear, but subscribers deserve some warning even of the risk that invalidation would happen in future, not to mention that they will not be able to receive renewals from these CAs, at least for some time.

[Gervase Markham]

On 13/10/16 17:49, Kathleen Wilson wrote:
> Thanks again to all of you who have put in so much time and effort to
> determine what happened with WoSign and StartCom and discuss what to
> do about it.

You are welcome.

As people will have read, the current decision at Mozilla is to treat
the WoSign and StartCom roots the same, except that StartCom has an
opportunity to be re-included faster than WoSign if they can meet the
conditions in time. It is also the current position that we will require
the companies to use new roots, although cross-signing of the new by the
old is permissible.

Some further comments for Kathleen:

> Within this message, the term “Affected Roots” applies to the
> following 7 root certificates.

Yes; it appears my root list in the investigation document missed one.
Sorry about that.

> 1) Distrust certificates chaining up to Affected Roots with a
> notBefore date after October 21, 2016.

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.

> 3) No longer
> accept audits carried out by Ernst & Young Hong Kong.

To be clear, this is a permanent ban, applicable worldwide, but only to
the Hong Kong branch of E&Y. (If further issues are found with E&Y
audits elsewhere, then we might consider something with wider scope.)

> 4) Remove the
> Affected Roots from NSS after the SSL certificates issued before
> October 1, 2016, have expired or have been replaced.

That should be in approximately 39 months time, as that's the max
issuance length allowed by the BRs.

> 4. Provide auditor attestation that a full performance audit has been
> performed confirming compliance with the CA/Browser Forum's Baseline
> Requirements[6]. This audit may be part of an annual WebTrust BR
> audit. It must include a full security audit of the CA’s issuing
> infrastructure.

I would recommend that Mozilla retain the option to approve the security
auditor, and that it be an external company.

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

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.

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.

Gerv

[Kurt Roeckx]

On Thu, Oct 13, 2016 at 08:52:13PM +0100, Gervase Markham wrote:
> > 4) Remove the
> > Affected Roots from NSS after the SSL certificates issued before
> > October 1, 2016, have expired or have been replaced.
>

> That should be in approximately 39 months time, as that's the max
> issuance length allowed by the BRs.

There is actually an expection allowing 60 months. But the last
one currently seems to be expiring on 2020-01-07 09:30:49+00,
which is 39 months from now.


Kurt

[Nick Lamb]

On Thursday, 13 October 2016 20:52:54 UTC+1, Gervase Markham wrote:
> To be clear, this is a permanent ban, applicable worldwide, but only to
> the Hong Kong branch of E&Y. (If further issues are found with E&Y
> audits elsewhere, then we might consider something with wider scope.)

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 ?

[Matt Palmer]

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?

- Matt

--
Yes, Java is so bulletproofed that to a C programmer it feels like being in
a straightjacket, but it's a really comfy and warm straightjacket, and the
world would be a safer place if everyone was straightjacketed most of the
time. -- Mark 'Kamikaze' Hughes

[big...@gmail.com]

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

[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.

[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

[Kurt Roeckx]

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

[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

[Rob Stradling]

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

> 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

[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

[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

[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".

[okaphone.e...@gmail.com]

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

[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

[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

[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.

[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?

[Hanno Böck]

On Fri, 14 Oct 2016 13:21:32 -0700 (PDT)
Ryan Sleevi <ry...@sleevi.com> 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

[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.

[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.

[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 <ry...@sleevi.com> 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

[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

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



--
konklone.com | @konklone <https://twitter.com/konklone>

[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

[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.

[Kathleen Wilson]

All,

Here’s a summary of your input, and my thoughts.

~~
What about NSS?
We discussed this in the NSS team call last week, and the general decision was that the rules we put in place regarding these Affected Roots for Mozilla will also be put in place inside NSS.
That doesn’t help all consumers of the NSS root store, just the ones who use NSS validation.
I’m not sure what we can do about other consumers of the NSS root store, other than publish what we are doing and hope those folks read the news and update their version of their root store as they see appropriate for their use.

~~
Several comments about Mozilla’s Action #4.

> 4) Remove the Affected Roots from NSS after the SSL certificates
> issued before October 1, 2016, have expired or have been replaced.

I will change the date to October 21, 2016 to be consistent with the date previously listed.

When I wrote that we would remove the Affected roots after the certs had expired or been replaced, I was incorrectly only thinking about the 1-year SSL certs.

My intent was to find a reasonable date in the future when current clients have had enough notice and time to transition to other root certificates. Based on the data from Kurt, it looks like a year might be too little time. Two years seems like a lot of time.

~~
Regarding actions for the CA…
Several suggestions that Mozilla require or strongly urge the CA owners of the Affected Roots to reach out to their subscribers asap to let them know about these changes, and give those clients time to transition.

> subscribers
> deserve some warning even of the risk that invalidation would
> happen in future, not to mention that they will not be able to
> receive renewals from these CAs, at least for some time.

> 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

I would hope that the CA would figure out how to communicate this to their customers in order to help their customers have minimum disruption.

The CA could create new root certs, and put information on their website to make it easier for users to manually import their new root certs, and also put information on their website for their current customers who will need to get new intermediate certs, and instruct their customers about downloading the new root certs. That’s basically what CAs whose root certs aren’t included in NSS (and aren’t cross-signed by an included root) have to do anyways.

I’m not sure what I could reasonably require (and enforce) of the CA in regards to communicating with their customers.

I recall that my security blog about CNNIC got censored in China, so I'm not sure what Mozilla can do about informing the CA's customers of this pending change/impact.


~~
>> 4. Provide auditor attestation that a full performance audit has been
>> performed confirming compliance with the CA/Browser Forum's Baseline
>> Requirements[6]. This audit may be part of an annual WebTrust BR
>> audit. It must include a full security audit of the CA’s issuing
>> infrastructure.
>
> I would recommend that Mozilla retain the option to approve the
> security auditor, and that it be an external company.

I will add the sentence: “The auditor must be an external company, and approved by Mozilla.”


~~

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

As suggested, I will add:
”The CA SHOULD NOT fulfill 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.

I don't think that changes the sentence that is being added.


~~

> 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 ?

I think Gerv is doing that.

It will also impact CNNIC.
https://bugzilla.mozilla.org/show_bug.cgi?id=1177209#c13
So, does CNNIC's audit get grandfathered in? Or does CNNIC have to get audited by a different auditor before they can re-apply for full inclusion?

~~
I think we need to add an action item regarding making sure that all of the code and systems used by the CA are well-designed and updated, and fully meet the CA/Browser Forum’s Baseline Requirements.

What would be a reasonable requirement to state for each of the CAs?

Are there tests that we could require the CA to run/pass that would satisfy our concerns about quality of the code and systems?

Thanks,
Kathleen

[Nick Lamb]

On Tuesday, 18 October 2016 00:27:09 UTC+1, Kathleen Wilson wrote:
> I’m not sure what I could reasonably require (and enforce) of the CA in regards to communicating with their customers.

As I understand it QiHoo 360 says they intend to co-operate in order to eventually get the new StartCom CA trusted. If they are unwilling to communicate with existing subscribers of both existing CAs effectively, it seems to me this is evidence of bad faith and excludes the possibility of the new CA being trusted by Mozilla (or in my opinion any right-thinking person).

So, essentially I'd argue that explaining Mozilla's decision to existing subscribers is a pre-requisite of any future trust for the new StartCom and Mozilla should emphasise that to QiHoo 360. The communication needn't walk through all Mozilla's findings, but it should clearly say what will happen (new certificates won't be trusted) and that QiHoo 360/ WoSign/ StartCom accept this as legitimate.

[Gervase Markham]

Hi Ryan,

Kathleen has responded, but here are my two cents:

On 14/10/16 13:21, Ryan Sleevi wrote:
> 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?

It is not that are we willing to blindly trust them on this; it is that
we believe that in practice it will be impossible for them to backdate
lots of certs to get around the block without it being detected. Such
certs, of course, would need to be CT-less, although both CAs have
committed to full CT from now on, and both have