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 loaded "every" cert
since a certain date into CT. If loads of CT-less older WoSign or
StartCom certs with long lifetimes started turning up on their customers
sites, it would be fairly obvious.

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

Everyone needs to make their own trust decisions, which will be affected
by what decisions their code lets them make. A while ago, Mozilla was in
this sort of position, but we did engineering work and now the situation
is not so bad.

I don't think any platform would have size or code constraints on
implementing our notBefore solution. A whitelist may have problems, but
we aren't proposing we use one.

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

See Kathleen's response.

Gerv

[Gervase Markham]

On 17/10/16 16:26, Kathleen Wilson wrote:
> 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.

We cannot fix everyone else's code, but I think it would be reasonable
for us to produce and maintain a wiki page which complements
certdata.txt which gives all the other restrictions Mozilla recommends
on the roots therein.

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

The audit report CNNIC has submitted covers the period from November 2,
2015 to February 29, 2016. Therefore, we would expect them to be
starting the process of getting another yearly audit in about 2 weeks
anyway, although it won't be done until next year.

I think the fairest thing is to allow them to proceed with the inclusion
application, get them in the queue, and follow through all the steps,
expecting that by the time they get to the end, their new audit (by
another auditor) will be completed. Assuming it is good, we can include
them.

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

Well, we already require that they meet the Baseline Requirements, and
"updated" is covered by the Network Security Requirements which, for all
their flaws, are included by reference in the BRs. So that seems like a
no-op. And I don't know how to define "well-designed".

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

Not really :-(

Gerv

[Gervase Markham]

On 18/10/16 01:00, Nick Lamb wrote:
> 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).

This is a difficult call.

On the one hand, I want to stand up for the right of all browsers to
make independent decisions on who to trust, and that includes Qihoo
360's Safe Browser. And as it's perfectly possible and not in any way
unacceptable or illegal for CA to operate while not being trusted by
Mozilla, I don't think it's reasonable to interfere with thr
relationship between a CA and its customers by requiring them to make
particular forms of communication about Mozilla's level of trust in them.

On the other hand, Qihoo 360 do have a conflict of interest when making
trust decisions about the CAs that they own.

It is not clear what Qihoo plans to do about WoSign. For StartCom, they
plan to rebuild or review all of its systems to remove the influence of
WoSign-authored code, which is agreed to be of poor quality. It would
certainly be a statement of how Qihoo 360 views security, as to whether
StartCom continued to issue certs during this process or whether they
suspended issuance until it was done.

I guess I would say the following to Qihoo 360, without knowing what
they plan to do. Continuing to trust StartCom and WoSign (assuming the
other browsers popular in China do the same), and continuing to issue
certs from them while other browsers are refusing them, runs the danger
of further splitting the Chinese internet from that of the rest of the
world. One thing that's clear about the Internet is that its value to
all goes up the more connected it is. Steps which make the Chinese
internet and the rest of the world less connected are to be avoided, for
everyone's benefit.

Gerv

[Peter Bowen]

On Tue, Oct 18, 2016 at 5:51 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 17/10/16 16:26, Kathleen Wilson wrote:

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

> We cannot fix everyone else's code, but I think it would be reasonable
> for us to produce and maintain a wiki page which complements
> certdata.txt which gives all the other restrictions Mozilla recommends
> on the roots therein.

I think making it clear which entries in certdata.txt have additional
constraints would be very helpful. Is it maybe possible to do so by
adding new attributes to the NSS_TRUST object instead of simply
putting it on a webpage? That way it is in the same place and is
machine readable. Even if the attribute are not processed when
creating libckfw, others can use them.

Thanks,
Peter

[Kurt Roeckx]

On 2016-10-18 14:51, Gervase Markham wrote:
>
> The audit report CNNIC has submitted covers the period from November 2,
> 2015 to February 29, 2016. Therefore, we would expect them to be
> starting the process of getting another yearly audit in about 2 weeks
> anyway, although it won't be done until next year.

If they now are on a yearly audit, I would expect the audit to start
somewhere in March 2017.


Kurt

[Inigo Barreira]

Hi all,


I´ve been reading some emails that need clarification form both sides.

Firstly I´d like to remind, if I´m not wrong, that Kathleen proposed an
action plan for distrusting StartCom, which has been taken as the final
decission, but with a small option to regain the trust for StartCom in
Mozilla if we can make her recover the confidance in StartCom.

Two weeks ago, there was a meeting between StartCom and Mozilla that
everybody was aware and on friday of that week, StartCom published the
outcome of that meeting, having this last week to set specific dates and
tasks for making it real. The surprise came when Kathleen droped the
email with the sanctions plan. In any case, StartCom published on
friday, at 10:30 CET, a remediation plan (it was already done by
thursday that week, but it´s difficult to coordinate with so many hours
of difference) on StartCom´s website. Surprisingly, there hasn´t been
any comment, in this mailing list, to that message (I even had to ask
Gerv if I posted correctly) in which there is more detailed information
on the next steps to be done.

Here´s the link again:
https://www.startssl.com/report/StartCom_Remediation_Plan_14102016.pdf

So, regarding the situation of StartCom I think that some people has
lost what happened and it´s considering Wosign and Startcom the same.

Let´s focus on the 3 issues for which StartCom has been proposed to a
sanction (hopefully we can change that), and these are:

1.- Bad coding of a new solution called startencrypt, which basically
was barely used and not affected StartCom

2.- Issues with serial numbers, not able to generate serial numbers
starting with zero and the reuse of some. Those were bugs fixed on time
and were because of a software and hardware upgrading as explained
before, due to the acquisiton of Wosign because the PKI was cloned. This
is also indicated in the plan

3.- Backdating 2 certs for Tyro. I think this is the issue that has made
Mozilla to include Startcom in the equation and fine it. But as also
explained this is not a security issue (same as other SHA1 certs
legitimacy issued on time) but a bad practice

In any case, this mailing list is called mozilla.dev._security_.policy,
and for these 3 issues, imho there´s no security problem. We can talk
about how things have been done, there´s been some cheating, hidden
info, bad practices, etc. That´s totally true but as Mozilla always
remembers about their users base, these have not been affected by any
security problem. Recently some emails remembered the comodogate, the
diginotar, etc. back in 2011, and those were different because the
attacker had control over the issuance process and some certificates
were issued without knowledge and/or consent of the CA, and this is not
what has happened to StartCom in which all the cryptographic material
was under control of the companies (including wosign)

Of course, there has been bad decissions, bad practices and procedures,
etc. but if you see the plan, there you can find all the actions that
are taking place to avoid this situation again.

In any case, taking as examples the recent issues affecting Comodo and
Globalsign (I´m just mention these because have been published at the
same time) it makes me feel with a strange feeling. Comodo issue was an
unintentionally or unauthorized issuance of a certificate for a ".sb",
can´t remember now, (could be compared to the 2 backdated certificates)
and globalsign revoked an intermediate certificate and later un-revoked
it (I don´t know if this is allowed in the RC 6960, but in ETSI once a
certificate is revoked, you can´t reisntate it status). Again, those are
examples and the only concern for me, it´s that the bar in the case of
StartCom is not the same in the case of others, again, taking into
account what has mentioned above and the control over the keys has not
been lost. The price for StartCom is too high.

For some specific questions that are around this issue, for example,
those related to communicate the end users, I have to say that:

- Mozilla runs a root program on a voluntary basis. So any CA may join,
stay or leave on its own discretion. If the CA decides to join, then it
shall follow the root program requirements

- Every CA must have its own procedures and practices for doing its
business, independently if decides to join a specific root program or not

- Mozilla and other root programs can impose its rules to the CAs that
voluntary decide to adhere to the programs but can´t have any decission
on what a CA decides or not related to its business. Of course comments,
suggestions, etc. are welcome in the comunity

- StartCom has made publicly this report in which they explain what are
going to do, dates and tasks, for everybody to check out the ongoing
tasks. I will indicate periodically how these tasks are going

- The decission on what/how/when to communicate whatever to the StartCom
customers is a decission of StartCom. Mozilla and the rest of the root
programs can make comments or suggestions for sure, but can´t interfere.
And this is not a matter of trust or something similar I´m reading here.
And again, taking into account that the security of the end users have
not been affected.


I´d also like to comment the issue regarding the CT, which I think is
unfair, but let me explain:

- Firefox does not support CT yet

- All CT log servers operators out there have to follow the same
requisites, for example, RFC 6962 up to now, and google requires some
more requisites to be admitted into Chrome browser. These are the same
for every CT log server operator independently who manages them

- There are additional tools, such as crt.sh, that are also valid to
check out certificates

so and as stated in the plan:

- Before Mozilla asked, StartCom started publishing all their
certificates in the CT logs

- In the document, you can see that for EV (and to meet google
requisites) StartCom uses a google and non-google log server

- for the non-EV certificates, StartCom uses a google and non-google log
server. These non-google log servers were announced to be include in
release 54 (which has been already released)

- StartCom has been in touch with other CT log server operators but it´s
complicated due to the number of certificates StartCom issues. Not all
log servers accept these numbers for many reasons, i.e. performance
because can´t create some delays that will affect its status in Chrome.
Having said this, I´ve contacted Symantec to see how´s the current
situation (were some talks in the past), also was commented the choice
of using CNNIC log server (but maybe there are suspicions), and was
planned to talk in person with Digicert.

In any case, StartCom follows the google rule of one google and one
non-google log (which of course this does not have to be the same rule
in case of Mozilla but as Firefox does not support it, will be
contradictory to have some other rules) and don´t understand the
reasoning of not using the StartCom one, when ALL of them have to pass
the same requirements.


Finally, I´d like to ask Mozilla if the remediation plan released by
StartCom last friday can make Mozilla regain the confidence and trust in
StartCom with the current roots. Maybe there are some additional steps
to make or some other conditions proposed by Mozilla, but in general, I
think this plan is good enough to be maintained in the Mozilla root
program because it solves all the issues that have happened.

I´d also like to know if we are forced to set up new roots to be
admitted because that will make us need some more time and in any case,
need to know the auditor Mozilla is suggesting to contact them asap for
arranging agendas.


Lastly, and now I´m finishing, also has been said about the transparent
of the process, how different root programs work, a unique source of
information, etc. I think this is good, but it´s only one leg, the
information to provide to the root programs, but it will be good to have
also another one listing the issues and the penalties. For example,
something similar of what the EU Commission is doing with eIDAS and
article 19, in which CAs have to communicate to their supervisory body
(the equivalent of the browsers root program) all the incidents they
have and then decide based on a specific procedure and with the help of
a tool. ENISA is working in developing this tool and providing this
procedure to all SB and TSPs, and this procedure is divided into
different categories with different levels and possible issues that are
going to be treated differently and with accordingly sanctions, from
monetary to distrust. With this solution, all CAs will know in advance
what will happen if you make a mistake and not treat them on a
one-by-one case and applying different resolutions for similar
incidents. The aim is to be the more objective possible.

If you think this option will improve the transparency of an open
collaboration, I´m willing to help.


Best regards,

Iñigo Barreira

CEO

StartCom CA Limited

El 18/10/2016 a las 1:26, Kathleen Wilson escribió:
> 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.
>

> 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

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

--

Iñigo Barreira
CEO
StartCom CA Limited

[Gervase Markham]

Help me understand how you get to that figure, given that their previous
audit started on November 2nd, 2015?

Gerv

[Nick Lamb]

On Tuesday, 18 October 2016 15:38:07 UTC+1, Inigo Barreira wrote:
> Let´s focus on the 3 issues for which StartCom has been proposed to a
> sanction (hopefully we can change that), and these are:
>
> 1.- Bad coding of a new solution called startencrypt, which basically
> was barely used and not affected StartCom
>
> 2.- Issues with serial numbers, not able to generate serial numbers
> starting with zero and the reuse of some. Those were bugs fixed on time
> and were because of a software and hardware upgrading as explained
> before, due to the acquisiton of Wosign because the PKI was cloned. This
> is also indicated in the plan
>
> 3.- Backdating 2 certs for Tyro. I think this is the issue that has made
> Mozilla to include Startcom in the equation and fine it. But as also
> explained this is not a security issue (same as other SHA1 certs
> legitimacy issued on time) but a bad practice
>
> In any case, this mailing list is called mozilla.dev._security_.policy,
> and for these 3 issues, imho there´s no security problem.

Without any doubt in my mind, all three issues were in fact security problems. Most broadly this is because StartCom deviated from its stated policy and obeying that policy is itself a security requirement. It is not for StartCom to declare that it has decided after the fact some aspects of the policy are not "security" and it chose to ignore those, the Relying Parties are entitled to expect that StartCom will obey the entire policy and to rely on however much or little of the policy as they like. Likewise for the Baseline Requirements.

StartCom was of course welcome to write a policy saying "We might issue backdated certificates, we might re-use serial numbers, we might not bother actually doing domain verification properly" and I believe a hypothetical alternative CA which documented such policies, let's call it "Garbage StartCom" would not be trusted by Mozilla, nor by any major trust store. Why should the actual StartCom be permitted to document good policies, then act like Garbage StartCom anyway with the thin excuse that you think it was not a "security" problem?

For the backdated SHA-1 certificates in particular, signing these certificates involved taking a huge risk each time because of the known vulnerability of the Merkle–Damgård construction and relatively short hashes in SHA-1. When this is done for the Exception process the _entire_ community gets to examine the tbsCertificates first, with both statistical analysis tools and simple visual inspection of the contents to see if there's anything dubious. But StartCom / WoSign instead issued certificates without so much as telling anybody, forcing the risk upon the entire Web PKI relying community without notice, for their financial benefit.

StartCom's Issuer for the back-dated SHA-1 certificates has a CA:TRUE certificate without a path length constraint allowing a hypothetical bad guy to create themselves a full CA:TRUE certificate of their own using a chosen-prefix attack or some as-yet unknown improvement on the same idea. That's basically game over for the PKI if it had happened, but StartCom/ WoSign risked it to get some cash in direct defiance of the Baseline Requirements, and the rules of the trust store programmes they'd agreed to. How is that _not_ a security problem ?

[Gervase Markham]

Hi Inigo,

On 18/10/16 07:34, Inigo Barreira wrote:
> So, regarding the situation of StartCom I think that some people has
> lost what happened and it´s considering Wosign and Startcom the same.

Kathleen may also respond, but my understanding is that (based on her
consideration of the arguments put forth in this forum) her decision was
that the right approach was to treat WoSign and StartCom in mostly the
same way, based on the fact of their shared ownership, management etc.
over the past 10 months or so. As you know, this is not entirely how I
saw it, but I was at pains to make it clear to you that I was not the
final decision-maker, and I respect the decision which has been made.

> Let´s focus on the 3 issues for which StartCom has been proposed to a
> sanction (hopefully we can change that), and these are:

This line of argument starts from the position that StartCom and WoSign
can be treated separately. But Kathleen has decided that this is not so.

In addition, the three issues you list are not the only issues with
StartCom - while I have not compiled a formal list like the one for
WoSign, Ryan does point out several more.

> In any case, this mailing list is called mozilla.dev._security_.policy,

It's called that because when I asked for it to be created, I thought it
was logically a sub-part of mozilla.dev.security, which was the existing
discussion forum for these topics. You should not read too much into the
group name.

The issue of who is trusted in Mozilla's root program is an issue of
trust, which includes but is not limited to whether a CA is behaving
securely.

> In any case, taking as examples the recent issues affecting Comodo and
> Globalsign (I´m just mention these because have been published at the
> same time) it makes me feel with a strange feeling. Comodo issue was an
> unintentionally or unauthorized issuance of a certificate for a ".sb",
> can´t remember now, (could be compared to the 2 backdated certificates)
> and globalsign revoked an intermediate certificate and later un-revoked
> it (I don´t know if this is allowed in the RC 6960, but in ETSI once a
> certificate is revoked, you can´t reisntate it status).

I don't think it's helpful to go into a detailed comparison of CAs and
issues and rating their relative severity, but I would note that there
are two components to how Mozilla views an incident - firstly what
happened, and secondly how the CA reacts. (I will say more about this in
Browser News at the CAB Forum tomorrow.)

> In any case, StartCom follows the google rule of one google and one
> non-google log (which of course this does not have to be the same rule
> in case of Mozilla but as Firefox does not support it, will be
> contradictory to have some other rules) and don´t understand the
> reasoning of not using the StartCom one, when ALL of them have to pass
> the same requirements.

To fulfil the non-Google log server requirement, it is not necessary
that you use a log server which is included in Chrome. Therefore there
is no formal uptime requirement (although clearly you'd want a decent
uptime as you were using it). The only requirement is that it not be
controlled by you.

> Finally, I´d like to ask Mozilla if the remediation plan released by
> StartCom last friday can make Mozilla regain the confidence and trust in
> StartCom with the current roots.

This is a question for Kathleen but, as you know, her current decision
is to require new roots.

> I´d also like to know if we are forced to set up new roots to be
> admitted because that will make us need some more time and in any case,
> need to know the auditor Mozilla is suggesting to contact them asap for
> arranging agendas.

For WebTrust and other normal CA audits, Mozilla has no requirements on
who the auditor should be other than it should not be E&Y HK. You may
choose.

For the security auditing of your infrastructure, you may suggest a firm
but Mozilla retains the right to approve your choice or ask you to make
another. However, I suspect you are not at that stage yet?

> information to provide to the root programs, but it will be good to have
> also another one listing the issues and the penalties.

I don't think it's either possible to helpful to make a list of all the
possible forms of CA mistake and the penalty to be applied in each case.
This would only work if it happened a lot. With it being so relatively
uncommon, I think every situation must be taken on its particular
circumstances. This is a benefit to you, because it allows for Mozilla
discretion where there are mitigating circumstances.

Gerv

[Han Yuwei]

在 2016年10月18日星期二 UTC+8下午10:38:07，Inigo Barreira写道：

Security is not only in code but in the process.

I think the reason of back-dating SHA1 cert is for the finanical benefit.

I am confused about conflicts between non-profit and commercial CA. On the one hand, non-profit CA can avoid violating rules for money, On the other hand, commercial CA can provide a stable service and avoid security issues from financial problems.

[Kurt Roeckx]

You said the period was until February 29, 2016. I assume the next
period starts on March 1, 2016 and is for 1 year. I don't expect it to
from from March to November, it would be an 8 month period.


Kurt

[Gervase Markham]

On 18/10/16 09:03, Kurt Roeckx wrote:
> You said the period was until February 29, 2016. I assume the next
> period starts on March 1, 2016 and is for 1 year. I don't expect it to
> from from March to November, it would be an 8 month period.

Surely if audits last one year, one would be auditing the CA at the same
time each year? And the last audit was Nov -> Feb. That's certainly what
my neighbour here in the CAB Forum meeting room is suggesting is true.

Gerv

[Gervase Markham]

Hi Peter,

On 18/10/16 06:02, Peter Bowen wrote:
> I think making it clear which entries in certdata.txt have additional
> constraints would be very helpful. Is it maybe possible to do so by
> adding new attributes to the NSS_TRUST object instead of simply
> putting it on a webpage? That way it is in the same place and is
> machine readable. Even if the attribute are not processed when
> creating libckfw, others can use them.

We could have a flag saying "this root is special", so people could
detect when new "special" roots had appeared so they could check the
wiki page, but I think it would be hard to programmatically encode the
restrictions such that they are machine-readable, because there are such
a wide variety of restrictions which one could imagine making.

Gerv

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

Measure with a micrometer, mark with chalk and cut with an axe... it's the best you can do.

[Gervase Markham]

On 18/10/16 06:02, Peter Bowen wrote:

> I think making it clear which entries in certdata.txt have additional
> constraints would be very helpful.

Here's a start:
https://wiki.mozilla.org/CA:Root_Store_Trust_Mods

I believe the ANSSI root has now been removed and so CNNIC is the only
one (leaving aside WoSign/StartCom) which should appear on the list. Am
I right?

Gerv

[Kurt Roeckx]

On Tue, Oct 18, 2016 at 10:02:00AM -0700, Gervase Markham wrote:
> On 18/10/16 09:03, Kurt Roeckx wrote:

> > You said the period was until February 29, 2016. I assume the next
> > period starts on March 1, 2016 and is for 1 year. I don't expect it to
> > from from March to November, it would be an 8 month period.
>

> Surely if audits last one year, one would be auditing the CA at the same
> time each year? And the last audit was Nov -> Feb. That's certainly what
> my neighbour here in the CAB Forum meeting room is suggesting is true.

Are you saying you're expecting an audit report from November 2015
to November 2016, and so have the period from November to March
covered twice?

Since the previous audit wasn't one that covered a whole year, I
expect the new audit to start where the previous one stopped and
have it a year from that point.


Kurt

[Gervase Markham]

On 18/10/16 12:46, Kurt Roeckx wrote:
> Are you saying you're expecting an audit report from November 2015
> to November 2016, and so have the period from November to March
> covered twice?

There seems to be a persistent misunderstanding here.

https://cert.webtrust.org/SealFile?seal=2092&file=pdf
https://cert.webtrust.org/SealFile?seal=2091&file=pdf
both say that the period when the auditors were examining CNNIC was
November 2, 2015 to February 29, 2016. Obviously, it then took them time
to write up their report and get it published and so on, but that's not
relevant for this.

Therefore, as WebTrust audits last a year, I would expect CNNIC to begin
being re-examined on or about November 2nd 2016, one year after the
previous examination started.

Unless I've misunderstood what that date range means. If it means the
period of audit validity, then the audits have already expired, so we
shouldn't rely on them. So it can't be that, otherwise they wouldn't
have submitted them.

Gerv

[Ryan Sleevi]

Gerv,

I think there's some confusion there. CNNIC's audits "expire" on Feb "29" 2017 (I say "29" because of ambiguity on "1 year"). That is, within 3 months of Feb "29", 2017, CNNIC would be expected to provide a new audit, which covers February 29, 2016 (the end of the previous audit period) until February "29", 2017. This would then be delivered to Mozilla within 3 months - May 29, 2017.

I'm not sure I understand your remark "last a year" - merely, there must be an unbroken sequence of audits. The current sequence ends February 29, 2016. The next sequence must not exceed a year, and must be delivered within 3 months of the full year period expiring.

[Peter Bowen]

On Tue, Oct 18, 2016 at 2:33 PM, Ryan Sleevi <ry...@sleevi.com> wrote:
>
> I think there's some confusion there. CNNIC's audits "expire" on Feb "29" 2017 (I say "29" because of ambiguity on "1 year"). That is, within 3 months of Feb "29", 2017, CNNIC would be expected to provide a new audit, which covers February 29, 2016 (the end of the previous audit period) until February "29", 2017. This would then be delivered to Mozilla within 3 months - May 29, 2017.
>
> I'm not sure I understand your remark "last a year" - merely, there must be an unbroken sequence of audits. The current sequence ends February 29, 2016. The next sequence must not exceed a year, and must be delivered within 3 months of the full year period expiring.

There is also a requirement that each audit period may not be less than 60 days.

Thanks,
Peter

[Kurt Roeckx]

On Tue, Oct 18, 2016 at 01:35:59PM -0700, Gervase Markham wrote:
> On 18/10/16 12:46, Kurt Roeckx wrote:

> > Are you saying you're expecting an audit report from November 2015
> > to November 2016, and so have the period from November to March
> > covered twice?
>

> There seems to be a persistent misunderstanding here.
>
> https://cert.webtrust.org/SealFile?seal=2092&file=pdf
> https://cert.webtrust.org/SealFile?seal=2091&file=pdf
> both say that the period when the auditors were examining CNNIC was
> November 2, 2015 to February 29, 2016. Obviously, it then took them time
> to write up their report and get it published and so on, but that's not
> relevant for this.

It does not say when the audit was performed. It says which period
of activity has been audited. Some reports also indicate when they
did the audit, but that's really not important.

Somewhere between 2016-03-01 and 2016-04-05 E&Y went to CNNIC
to audit them for what CNNIC did between 2015-11-02 and 2016-02-29.

If they have an audit that covers a year now, I expect the period to
be covered from 2016-03-01 to 2017-02-28. The auditor would then
have 3 months to perform the audit of that period and write a new
report. The new report (according to the BR rules) should be in by
2017-05-28 (or 2017-05-31, depending on how you want to count
months.) But I think Mozilla starts to count the 3 months from
date of the last report, so they would actually have until
2016-07-05.


Kurt

[Ryan Hurst]

All,

I do not understand the desire to require StartCom / WoSign to not utilize their own logs as part of the associated quorum policy.

Certificate Transparency's idempotency is for not dependent on the practices of the operator. By requiring the use of a third-party log (in this case Google's) and requiring that the logs are public, CT "works" as expected.

There appears to be an argument being made that this restriction comes from the fact that Firefox does not yet have CT support, I would argue that this is not material. My justification for this argument is that today, Firefox depends on SafeBrowsing, this is a Google-provided service and Firefox uses it to protect users from malicious sites.

This is not significantly different from the way Chrome (and others) rely on the wonderful Mozilla Trusted Root Program.

Based on this it seems reasonable to allow them to use the same logs they use for EV.

Ryan

[Gervase Markham]

On 18/10/16 14:33, Ryan Sleevi wrote:
> I think there's some confusion there. CNNIC's audits "expire" on Feb
> "29" 2017 (I say "29" because of ambiguity on "1 year"). That is,
> within 3 months of Feb "29", 2017, CNNIC would be expected to provide
> a new audit, which covers February 29, 2016 (the end of the previous
> audit period) until February "29", 2017. This would then be delivered
> to Mozilla within 3 months - May 29, 2017.

Ah, OK. Thanks :-)

Gerv

[Gervase Markham]

On 18/10/16 15:42, Ryan Hurst wrote:
> I do not understand the desire to require StartCom / WoSign to not
> utilize their own logs as part of the associated quorum policy.

My original logic was that it could be seen that the log owner is
trustworthy. However, you are right that CT does not require this.

If the consensus of the group is that it's OK for StartCom/WoSign to run
their own CT servers for the 2nd log, we can drop that part of the
requirement.

Gerv

[Han Yuwei]

在 2016年10月19日星期三 UTC+8上午6:42:18，Ryan Hurst写道：

Could you explain what "idempotency" means? Because I am not a native English speaker and I can't lookup a good meaning about this word.

For the StartCom/Wosign's log, I think maybe Mozilla's logic is that they are not trustworthy when ther are appling CAs, so their CT logs can't be trusted.But I don't think that's right because there's a Google log also monitoring this.What I am interested in is why some CT log operator rejected the including request from StartCom. Performance is not persuading reason.

For the CT support, is there any plan to implement it into effect in Firefox? And if implemented, what would happen if server's certificate don't have enough SCTs?

[Gervase Markham]

On 18/10/16 16:04, Han Yuwei wrote:
> For the CT support, is there any plan to implement it into effect in
> Firefox? And if implemented, what would happen if server's
> certificate don't have enough SCTs?

The mechanism is being implemented. When it's closer to being
implemented, there will be a discussion of the policy (what logs to
trust, how many SCTs to require etc.)

Gerv

[Rob Stradling]

On 18/10/16 23:49, Gervase Markham wrote:
> On 18/10/16 15:42, Ryan Hurst wrote:

>> I do not understand the desire to require StartCom / WoSign to not
>> utilize their own logs as part of the associated quorum policy.
>

> My original logic was that it could be seen that the log owner is
> trustworthy. However, you are right that CT does not require this.

A log operator could offer a split view of their log, and this might go
undetected. That's why we need CT gossip to exist.

Is that a concern here?

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

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

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

[Andrew Ayer]

On Tue, 18 Oct 2016 15:49:26 -0700
Gervase Markham <ge...@mozilla.org> wrote:

> On 18/10/16 15:42, Ryan Hurst wrote:

> > I do not understand the desire to require StartCom / WoSign to not
> > utilize their own logs as part of the associated quorum policy.
>

> My original logic was that it could be seen that the log owner is
> trustworthy. However, you are right that CT does not require this.

This is true only as long as TLS clients are auditing logs for correct
operation by demanding inclusion proofs for SCTs (or alternatively,
gossiping them to someone who will). Otherwise, CT logs are just
another trusted third party and could easily claim a certificate is
logged when it really isn't. What are Mozilla's plans for implementing
inclusion proof checking or SCT gossip (not just SCT signature
validation) in Firefox?

That said, I think a much more important question is not whether
StartCom/WoSign can be trusted to operate a CT log, but whether they
can be trusted to operate a CA.

Regards,
Andrew

[Adrian R.]

Kurt Roeckx wrote:

> Since the previous audit wasn't one that covered a whole year, I
> expect the new audit to start where the previous one stopped and
> have it a year from that point.

this might be more of a question for cabforum but why do audits have to be non-overlapping?


i would think that a new audit would at least look at a random small period from the last audit (let's say one month, either at middle or end or around important event dates, like the SHA1 issuance ending on Dec 31st) and re-audit again that small period just to check that the previous auditor didn't miss any glaring issues.

If the audit report must cover a non-overlapping time period then have a separate section in the report for this small overlapped period and report it as such but at least it provides some checks that the previous auditor didn't miss obvious stuff.


This should be especially true (IMHO) for the case of E&Y HK where Gerv said for CNNIC:

"I think the fairest thing is to allow them to proceed with the inclusion
application, get them in the queue, and follow through all the steps,
expecting that by the time they get to the end, their new audit (by
another auditor) will be completed. Assuming it is good, we can include
them."

I'm ok with that but i'd like to also see that the new auditor looks at (and reports on) a random sample time period that's covered by the the previous audit.


~~~~
Adrian R.

[Ryan Hurst]

It is true, that without gossip, CT is dependent on browsers monitoring the log ecosystem, this is one reason why in the Chrome policy the one Google log is required.

I would argue, with the monitoring Google does and the one Google log policy that this risk is mitigated sufficiently, even without gossip.

Gossip is needed, as is Firefox's own implementation of CT verification, which is actively in the works, but given the above mitigations I still believe this extra requirement is not necessary.

Ryan

[Kurt Roeckx]

On 2016-10-19 01:37, Rob Stradling wrote:
> On 18/10/16 23:49, Gervase Markham wrote:
>> On 18/10/16 15:42, Ryan Hurst wrote:
>>> I do not understand the desire to require StartCom / WoSign to not
>>> utilize their own logs as part of the associated quorum policy.
>>
>> My original logic was that it could be seen that the log owner is
>> trustworthy. However, you are right that CT does not require this.
>
> A log operator could offer a split view of their log, and this might go
> undetected. That's why we need CT gossip to exist.

I at least have some concerns about the current gossip draft and talked
a little to dkg about this. I should probably bring this up on the trans
list.


Kurt

[Tom Ritter]

On 19 October 2016 at 02:58, Kurt Roeckx <ku...@roeckx.be> wrote:
> On 2016-10-19 01:37, Rob Stradling wrote:
>>

>> On 18/10/16 23:49, Gervase Markham wrote:
>>>
>>> On 18/10/16 15:42, Ryan Hurst wrote:
>>>>
>>>> I do not understand the desire to require StartCom / WoSign to not
>>>> utilize their own logs as part of the associated quorum policy.
>>>
>>>
>>> My original logic was that it could be seen that the log owner is
>>> trustworthy. However, you are right that CT does not require this.
>>
>>
>> A log operator could offer a split view of their log, and this might go
>> undetected. That's why we need CT gossip to exist.
>
>

> I at least have some concerns about the current gossip draft and talked a
> little to dkg about this. I should probably bring this up on the trans list.

Please do! For those not aware, the CT Gossip draft is in 'pre-final
review' in the sense that (we think) we're pretty much done but need
people to finally read it now. Draft is at:
https://datatracker.ietf.org/doc/draft-ietf-trans-gossip/


Because we're talking about a CA which used their private keys to get
around baseline requirements/prohibitions by backdating, I would not
be comfortable trusting them with operating a log where they could do
the same thing. The addition of the Google log prevents this to some
degree. So I would prefer the requirement either be 'one google and
one non-google/non-self-operated log' or just 'one google log'.

-tom

[Ryan Hurst]

On Wednesday, October 19, 2016 at 12:58:49 AM UTC-7, Kurt Roeckx wrote:
> I at least have some concerns about the current gossip draft and talked
> a little to dkg about this. I should probably bring this up on the trans
> list.
>

Please do, we would like to see this brought to closure soon and we want to make sure all feedback is considered.

[Ryan Hurst]

> Because we're talking about a CA which used their private keys to get
> around baseline requirements/prohibitions by backdating, I would not
> be comfortable trusting them with operating a log where they could do
> the same thing. The addition of the Google log prevents this to some
> degree. So I would prefer the requirement either be 'one google and
> one non-google/non-self-operated log' or just 'one google log'.
>
> -tom

Since you would be OK with one google log, it seems it would be harmless for them to log to their log also. As such treating them consistently as the Google EV policy (one google, one other) seems acceptable.

Ryan

[Tom Ritter]

On Oct 19, 2016 11:51 AM, "Ryan Hurst" <ryan....@gmail.com> wrote:
>
> > Because we're talking about a CA which used their private keys to get
> > around baseline requirements/prohibitions by backdating, I would not
> > be comfortable trusting them with operating a log where they could do
> > the same thing. The addition of the Google log prevents this to some
> > degree. So I would prefer the requirement either be 'one google and
> > one non-google/non-self-operated log' or just 'one google log'.
> >
> > -tom
>

> Since you would be OK with one google log, it seems it would be harmless
for them to log to their log also. As such treating them consistently as
the Google EV policy (one google, one other) seems acceptable.
>

It would be harmless, but if the only option for them to get to two logs is
to run their own, I don't see the point in requiring them to if we're not
going to really regard it as trusted. (Which at least I wouldn't. I'd
regard it as "A log I expect to be manipulated as soon as it is financially
expedient to do so.")

Unless we're proverbially doing it to give them more rope to hang
themselves with, so they get punished worse if they manipulate their log
like their CA issuance. But I'm not keen on that idea since we're
retroactively finding them putting users at risk, and this would be even
moreso.

-tom

[long...@gmail.com]

Hey Kathleen,
hey list,

I really don't get why Mozilla is pushing so hard on the Chinese and at the same time let others get away.
For example the Comodo case from today. Isn't that a much worse incident than what has happened here. People were able to issue certs for other people domains.
When I read the WoSign answer to the current case (https://www.wosign.com/report/WoSign_Incident_Report_Update_07102016.pdf) I personally felt, that they completely understood the seriousness of the situation.
I doubt we'll see a professional answer like this in the current Comodo case. But then - of cause - Comodos headquarter is in the United States and not in China.

I feel like Mozilla is misusing its market power in a beginning trade war and this is not a good thing for the Mozilla Foundation. We all trust Mozilla to fight for a free web and not to choose sides in a trade war.

Best,
Nikolai

Am Donnerstag, 13. Oktober 2016 18:50:02 UTC+2 schrieb 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

[Gervase Markham]

On 19/10/16 11:35, long...@gmail.com wrote:
> Hey Kathleen, hey list,
>
> I really don't get why Mozilla is pushing so hard on the Chinese and
> at the same time let others get away. For example the Comodo case
> from today. Isn't that a much worse incident than what has happened
> here.

Today at the CAB Forum I outlined some of Mozilla's thinking on how we
rate the severity of incidents. It might be helpful to reproduce that
here. This is what I said:

<blockquote>
Many CAs may have been looking at Mozilla’s actions a little nervously,
conscious that they have had an issue or two in the past, and wondering
where the tipping point is which might lead to the production of a
WoSign-style “issue list”, and if they will ever hit it. It might
therefore be worth noting that while CA incidents have differing levels
of seriousness, there are some components which every CA should be able
to avoid which are red flags for Mozilla in terms of a continued trust
relationship, and which would lead to an investigation. They are:

* Deliberate violation of Mozilla or other applicable policy
* Lying or deception

Mozilla will also assess how concerned we are about an issue in part
based on how the CA reacts to that issue, and previous ones. In incident
response, Mozilla is looking for the following factors:

* A CA takes responsibility for their own actions.
* Incidents are taken with an appropriate level of seriousness.
* Incidents are handled with haste.
* Root cause analysis is performed.
* Any questions posed, by anyone, are answered quickly and in detail.
* A reasonably-detailed report is made public on what happened, why,
and how things have changed to make sure it won’t happen again.

The recent issue experienced by Comodo was a good (albeit small) example
of this being done.

If people have further questions about this, they should feel free to
ask, either now or privately.
</blockquote>

> People were able to issue certs for other people domains. When
> I read the WoSign answer to the current case
> (https://www.wosign.com/report/WoSign_Incident_Report_Update_07102016.pdf)
> I personally felt, that they completely understood the seriousness of
> the situation.

If you compare WoSign's responses over the entire period of
investigation to the criteria above, I hope you can see how the two
incidents are not comparable. In particular, they engaged in deliberate
violations of Mozilla policy and lied to cover it up.

Gerv

[Kathleen Wilson]

On Wednesday, October 19, 2016 at 11:50:55 AM UTC-7, Gervase Markham wrote:
>
> Today at the CAB Forum I outlined some of Mozilla's thinking on how we
> rate the severity of incidents. It might be helpful to reproduce that
> here. This is what I said:
>

Thanks, Gerv!

I added that text to the wiki page:
https://wiki.mozilla.org/CA:MaintenanceAndEnforcement#Potential_Problems.2C_Prevention.2C_Response

Kathleen

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

Perhaps "haste" is not what you want here. How about "urgency"?

CU Hans

[Kathleen Wilson]

On Wednesday, October 19, 2016 at 3:13:50 PM UTC-7, okaphone.e...@gmail.com wrote:
> Perhaps "haste" is not what you want here. How about "urgency"?
>

Yep. Changed in the wiki page.

Thanks,
Kathleen

[Gervase Markham]

On 19/10/16 15:13, okaphone.e...@gmail.com wrote:
> Perhaps "haste" is not what you want here. How about "urgency"?

I was using it in the sense of the English phrase "more haste, less speed":
http://dictionary.cambridge.org/dictionary/english/more-haste-less-speed

But yes, urgency is fine.

Gerv

[Kathleen Wilson]

All,

I have filed the following two bugs.

WoSign Action Items:
https://bugzilla.mozilla.org/show_bug.cgi?id=1311824

StartCom Action Items:
https://bugzilla.mozilla.org/show_bug.cgi?id=1311832

I will work on a security blog that will probably get posted early next week.
It will point to these two bugs, and list the actions Mozilla plans to take.

As we have been discussing, Mozilla plans to take the following actions:

1) Distrust certificates with a notBefore date after October 21, 2016 which chain up to the following affected roots. 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.
a) This change will go into the Firefox 51 release train.
b) The code will use the following Subject Distinguished Names to identify the root certificates, so that the control will also apply to cross-certificates of these roots.
i) CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN
ii) CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=CN
iii) CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA Limited, C=CN
iv) CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN
v) CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
vi) CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., C=IL

2) Add the previously identified backdated SHA-1 certificates chaining up to these affected roots to OneCRL.

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

4) Remove these affected root certificates from Mozilla’s root store at some point in the future. If the CA's new root certificates are accepted for inclusion, then Mozilla may coordinate the removal date with the CA’s plans to migrate their customers to the new root certificates. Otherwise, Mozilla may choose to remove them at any point after March 2017.

5) Mozilla reserves the right to take further or alternative action.


This discussion is still open, and I will still continue to appreciate your input on this topic.

Thanks,
Kathleen

[Kathleen Wilson]

On Thursday, October 20, 2016 at 6:59:08 PM UTC-7, Percy wrote:
> Kathleen,
> As most users affected by this decision are Chinese, will you be able to make the blog post available in Chinese on the security blog as well? You can ask the Chinese firefox community or me to translate.
>
> As I stated earlier, there are almost no news of the distrust of WoSign/StartCom on the Chinese Internet and WoSign/StartCom has not posted anything related to this. I believe it's paramount to prepare Chinese website owners for the phasing out of the affected roots.

Noted. I will look into how to get it translated into Chinese and how to make that version available as well.

Thanks,
Kathleen

[marc....@gmail.com]

Am Freitag, 21. Oktober 2016 03:59:08 UTC+2 schrieb Percy:
> Kathleen,
> As most users affected by this decision are Chinese, will you be able to make the blog post available in Chinese on the security blog as well? You can ask the Chinese firefox community or me to translate.

Hi,

only the distrust of Wosign affects mostly chinese Users.

The distrust of StartCom affects individuals, non profit organizations and small companies worldwirde. StartCom was the only CA where these people and groups could get ov,dv,s/mime and code signing certificates for a reasonable price. Of course the incidents needed clarification and ofcourse actions are to be taken to prevent such behaviour in future. But Gerv stated that the main reasons for the harsh punishment are the lies and deceptions. The responsible person is no longer in charge, StartCom has to pay a lot of money to make the changes required by Mozilla. This is OK and fine from the view of a customer / user.

But with distrusting StartCom roots Mozilla isn't increasing security for their users and the web, Mozilla will decreasing the security.

A lot of people which have secured their services and code will lose this possibility. From the view of a user not really understandable.


Just the opinion of a user who is securing services, websites and his mails with certificates but is not capable of paying hundreds of Euros / Dollars for achieving this goal every year.

Greetings

Marc

[Nick Lamb]

On Friday, 21 October 2016 11:48:21 UTC+1, marc....@gmail.com wrote:
> Just the opinion of a user who is securing services, websites and his mails with certificates but is not capable of paying hundreds of Euros / Dollars for achieving this goal every year.

This is the "too big to fail" argument and I think we've addressed why that's not acceptable previously.

For DV TLS certificates, Let's Encrypt will be an admirable replacement for StartCom as far as most subscribers are concerned. There will inevitably be scenarios where StartCom were able to offer cheap or free certificates that aren't possible with Let's Encrypt because their validation strategy is different, but I think the addition of IDNs this week means Let's Encrypt now covers the vast majority of normal scenarios.

The pressure of "competing" with Let's Encrypt means Comodo and at least one other major CA (I want to say Symantec?) also now have offers which may be applicable for some subscribers. Comodo, through cPanel, gives away certificates to many people using bulk hosting, and the other CA has a deal with ISPs where free certificates are a loss leader to drive potential customers into an upsell - ie DV certificates are free, but you're gently encouraged to pay them for OV or EV instead.

So, that leaves S/MIME and Code Signing. Code Signing is no longer really Mozilla's concern as I understand it, they deprecated the Code Signing trust bits in their store. For S/MIME certificates I believe there are other options out there, which are either free or very affordable but I don't use S/MIME certificates so I might be wrong.

[Han Yuwei]

在 2016年10月21日星期五 UTC+8下午6:48:21，marc....@gmail.com写道：

I am also a StartCom's SSL & S/MIME certificate user. The only problem for me is that I must re-config nginx. S/MIME have a lot of alternatives for free. Code Signing may only works on Windows but Microsoft seems like don't care about this because CNNIC is still trusted.

[marc....@gmail.com]

Am Freitag, 21. Oktober 2016 17:31:17 UTC+2 schrieb Nick Lamb:
> This is the "too big to fail" argument and I think we've addressed why that's not acceptable previously.

I've not said that the whole certificate system depends on StartCom. Sorry if I had not expressed myself clearly. As someone who uses StartCom and is personal not able to pay the price of nearly 500 EUR for a wildcard cert to secure a few websites, some devices and a mailserver, I've read about the bull**** that StartCom made and followed the threads in this group. I've read a lot of (good and true) argumentation but only from the "technical" side not one single argument dealing with the impact on users. So my intention was to bring up this "view".

> For DV TLS certificates, Let's Encrypt will be an admirable replacement for StartCom as far as most subscribers are concerned. There will inevitably be scenarios where StartCom were able to offer cheap or free certificates that aren't possible with Let's Encrypt because their validation strategy is different, but I think the addition of IDNs this week means Let's Encrypt now covers the vast majority of normal scenarios.

Let's Encrypt is surely a very good approach but actually not an replacement for an CA that is listed in the root store of all major browsers. It's not really practicable for someone using shared space without shell access, for securing consumer devices (router, NAS, and so on), because of the 90 day period. To much effort for the "normal" people out there.

And this is what my argument dealing with. In times where everybody, also Mozilla, is "praying" to use encryption I find it hard to understand that one big (and nearly the only) opportunity to secure communication for small businesses and individuals is thrown out. No question StartCom has made mistakes and of course there should be arrangements made to keep the CA-system safe and to prevent others from making this mistakes. But with distrusting StartCom I think (my personal view) the "small" users are punished a lot more than everyone else and they haven't done something wrong.

My only intention was to bring up this thought, not to say that the whole system depends on StartCom. But for sure the effort for many, many small webmasters out there or people who want's to secure their LAN at home, there small networks in company, is groing intensively by distrusting StartCom and as a result of this, they will not use encryption.

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

Isn't that something you should take up with StartCom? Bottom line you payed them for your certificate, didn't you. Not Mozilla. Perhaps StartCom should have been a bit more careful so they could keep serving their customers.

CU Hans

[Samuel Pinder]

I have been reading into this discussion for quite some time since my
initial posting, and as a Startcom customer even I wholeheartedly
agree with the measures being taken. I think I am one of the lucky
ones, as I have got my set of certificates before the cut-off deadline
and intend to look after them very carefully as they are valid for two
years that I would otherwise not be able to afford elsewhere. I am
absolutely furious to hear that Richard Wang attempted to cover up
mis-issued SHA-1 certificates among other things. It is a perfectly
reasonable thing to expect- browser makers remember the debacle when
MD5 collisions became possible and are probably quite rightly
terrified of such a scenario happening again as it took years to
migrate away from all use of MD5, long after forged MD5-based
certificates became possible. I would hope that Startcom learn from
this and, although I do see their model as rather unique and have
quite a position in the market, they must realise that they are not
too big to fail. With any luck the measures taken will ensure that
more competent management takes place that avoid these issues ever
happening again. I am very concerned that neither Startcom nor WoSign
are publicly announcing these measures on their websites, I have even
contacted Startcom about this via live chat. Their only responses seem
to be that they are waiting for 'upper management' to make an
announcement, despite me directly sending links to the filed bug
reports clearly showing Mozilla's plans. Well, that's rather like
burying their heads in the sand, as the deadline is today and other
customers whom do not follow these security forums will have no idea
that newly certificates after today will not be valid in Firefox until
it is too late. Hopefully once the management of Startcom has changed
hands away from WoSign (their very well hidden incident report link
suggests this will happen around December), one can expect much more
expeditious and honest communication.
Samuel Pinder

On Fri, Oct 21, 2016 at 7:29 PM, <okaphone.e...@gmail.com> wrote:
> Isn't that something you should take up with StartCom? Bottom line you payed them for your certificate, didn't you. Not Mozilla. Perhaps StartCom should have been a bit more careful so they could keep serving their customers.
>
> CU Hans

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

[Jernej Simončič]

On Fri, 21 Oct 2016 10:03:46 -0700 (PDT), Han Yuwei wrote:

> I am also a StartCom's SSL & S/MIME certificate user. The only problem for me is that I must re-config nginx. S/MIME have a lot of alternatives for free. Code Signing may only works on Windows but Microsoft seems like don't care about this because CNNIC is still trusted.

In my experience, StartCom's non-EV codesigning certificates were never
actually useful - they explicitly disable timestamping, so after the
certificate expires, the signature is rendered invalid.

--
begin .sig
< Jernej Simončič ><>◊<>< jernej|s-ng at eternallybored.org >
end

[Samuel Pinder]

Following on from my previous posting, I have found that Startcom are
still issuing certificates past the 21st of October that should be
subject to blocking in an upcoming version of Firefox
https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 . I have
therefore obtained such a certificate via my active account and
decided to create the following test URL so that anyone trying new
builds of Firefox have a URL to test the proposed blocking against:
https://notbefore-after-21st-test.samspin.net/
I do not have an equivalent for WoSign as a I do not have a
subscription there and they no longer issue free certificates anyway.
I hope this helps in some way!
Samuel Pinder

[Jakob Bohm]

On 22/10/2016 00:57, Jernej Simončič wrote:
> On Fri, 21 Oct 2016 10:03:46 -0700 (PDT), Han Yuwei wrote:
>
>> I am also a StartCom's SSL & S/MIME certificate user. The only problem for me is that I must re-config nginx. S/MIME have a lot of alternatives for free. Code Signing may only works on Windows but Microsoft seems like don't care about this because CNNIC is still trusted.
>
> In my experience, StartCom's non-EV codesigning certificates were never
> actually useful - they explicitly disable timestamping, so after the
> certificate expires, the signature is rendered invalid.
>

That stinks.

While Mozilla doesn't care about code signing and Microsoft's root
store may be lax, I think there are probably a lot of (current)
StartCom low cost OV codesigning customers who will need a suggestion
for an alternative.

Talking of codesigning, which root store does Chrome use to validate
signatures on the PPAPI plug ins it is currently forcing developers to
switch to?

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Ryan Sleevi]

On Saturday, October 22, 2016 at 5:11:29 AM UTC-7, Jakob Bohm wrote:
> Talking of codesigning, which root store does Chrome use to validate
> signatures on the PPAPI plug ins it is currently forcing developers to
> switch to?

I've mentioned to you repeatedly that no one uses the code signing store of Mozilla. Chrome itself does not use a code signing store - as I've also mentioned, CA-mediated code-signing is largely a historical artifact of Microsoft's past decisions, and not something to be practiced or encouraged.

So such an action has no impact on anyone consuming the code signing certs, so there's no need to suggest alternatives.

[Jakob Bohm]

On 22/10/2016 14:59, Ryan Sleevi wrote:
> On Saturday, October 22, 2016 at 5:11:29 AM UTC-7, Jakob Bohm wrote:
>> Talking of codesigning, which root store does Chrome use to validate
>> signatures on the PPAPI plug ins it is currently forcing developers to
>> switch to?
>
> I've mentioned to you repeatedly that no one uses the code signing store of Mozilla. Chrome itself does not use a code signing store - as I've also mentioned, CA-mediated code-signing is largely a historical artifact of Microsoft's past decisions, and not something to be practiced or encouraged.
>

OK, I was unsure if Chrome required signing of PPAPI plugins
distributed outside the (being closed) store, and if so what the rules
were (I'll be researching that soon anyway for other reasons).

> So such an action has no impact on anyone consuming the code signing certs, so there's no need to suggest alternatives.
>

While Microsoft code signing typically uses the Microsoft root store
(obviously), there are many other ecosystems using the object/code
signing trust logic, even though Mozilla is out of the game:

- Some Mozilla clones/forks have kept the broader approach to extension
signature checks that Mozilla replaced by "all extensions must be
signed by addons.mozilla.org", those obviously maintain their own code
signing trust bits.

- Java applets that need extended access use either the Browser root
store, the OS root store or the Oracle root store depending on
circumstances, thus anyone signing Java applets need a CA chaining to
all those stores.

- iOS apps need a signature that chains to the Apple code signing root
store, which currently only trusts Apple's own root for this.

- Apps for some of Adobe's plugin systems use object signing with
unknown root stores.

- PDF document signing tends to use the object signing trust bits
rather than the e-mail signing trust bits.

- And Microsoft is still in business with their various code signature
checks.

I find it somewhat likely that at least some of the above will use a
root store that follows in Mozilla's footsteps regarding distrust of
WoSign and StartCom. Thus the need for those who obtaind OV code
signing certificates from StartCom to start looking for alternatives,
and my suggestion, as a public service, that someone here might chime
in with the names of small/individual developer friendly issuers of
code signing certificates.

In other words, my question was in the general context of this being
the only public forum about root store policies, rather than
specifically about the Mozilla store.

[Jernej Simončič]

On Sat, 22 Oct 2016 16:26:51 +0200, Jakob Bohm wrote:

> Thus the need for those who obtaind OV code
> signing certificates from StartCom to start looking for alternatives,
> and my suggestion, as a public service, that someone here might chime
> in with the names of small/individual developer friendly issuers of
> code signing certificates.

I'm currently using a Comodo-issued codesigning certificate for my
projects. While the reseller I bought it from (http://www.ksoftware.net/)
discouraged me from getting the certificate issued to me as an individual
(due to supposedly complicated checks required), the process wasn't really
that hard - it involved getting a notary-validated signature of Comodo's
document and notary-validated copies of a bank statement of mine and a
phone bill (while the requirements say you can use other utility bills, you
should use a phone bill if you don't have your phone number published in a
directory, since they use it for validation). It took about a week from
applying for the certificate to getting it issued.

When I was buying the certificate, I found a 25% discount code on some 3rd
party website.

[Peter Bowen]

On Thu, Oct 20, 2016 at 1:57 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> 1) Distrust certificates with a notBefore date after October 21, 2016 which chain up to the following affected roots. 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.
> a) This change will go into the Firefox 51 release train.
> b) The code will use the following Subject Distinguished Names to identify the root certificates, so that the control will also apply to cross-certificates of these roots.

> i) CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN
> ii) CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=CN
> iii) CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA Limited, C=CN
> iv) CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN
> v) CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
> vi) CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., C=IL

According to the wiki, Asseco Certum has cross-signed at least one of
these roots. Is it expected that Certum will take any action, or do
the above changes mean that Certum's cross-sign of WoSign will be
considered to not exist for the purpose of Mozilla policy?

Thanks,
Peter

[Erwann Abalea]

Bonjour,

Le vendredi 21 octobre 2016 12:48:21 UTC+2, marc....@gmail.com a écrit :
[...]

> Just the opinion of a user who is securing services, websites and his mails with certificates but is not capable of paying hundreds of Euros / Dollars for achieving this goal every year.

DV certificates can be found for much less than that. Less than 5$ for a DV cert, less than 35$ for an OV cert, 11$ for an S/MIME cert (which nobody uses so far because it's a mess, but I digress).

It's nice to be able to have free certificates, but I don't consider 5$ a year for a DV to be expensive.

[Richard Wang]

Hi Kathleen,

WoSign released the news today since I just came back from USA CABF meeting.

http://www.wosign.com/news/announcement_about_Mozilla_Action_20161024.htm (in Chinese)

https://www.wosign.com/english/News/announcement_about_Mozilla_Action_20161024.htm (in English)



Best Regards,

Richard

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosig...@lists.mozilla.org] On Behalf Of Kathleen Wilson
Sent: Friday, October 21, 2016 10:43 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Remediation Plan for WoSign and StartCom

On Thursday, October 20, 2016 at 6:59:08 PM UTC-7, Percy wrote:

> Kathleen,
> As most users affected by this decision are Chinese, will you be able to make the blog post available in Chinese on the security blog as well? You can ask the Chinese firefox community or me to translate.
>

> As I stated earlier, there are almost no news of the distrust of WoSign/StartCom on the Chinese Internet and WoSign/StartCom has not posted anything related to this. I believe it's paramount to prepare Chinese website owners for the phasing out of the affected roots.

Noted. I will look into how to get it translated into Chinese and how to make that version available as well.

Thanks,
Kathleen

[Eric Mill]

Hi Richard,

A few questions -

1) Your post says "There will be new SSL certificates issued by a new
WoSign intermediate CA which is signed by the one of global trusted root
CA, it supports all the browsers (including Firefox). This will be done
within one months."

How will this WoSign intermediate CA be different from the 4 affected
roots? Will it use the same WoSign issuance infrastructure used by the 4
roots that Mozilla has decided to distrust?

2) Your announcement to customers only discusses Mozilla's action. Are you
planning to inform customers of how Apple's decision to distrust WoSign's
roots will affect WoSign operations?

3) A previous Qihoo 360 document said that you are being removed as WoSign
CEO. Are you still authorized by Qihoo 360 to make announcements like this?

-- Eric

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

[Richard Wang]

For Q1: This is a OEM SSL from other trusted CA;
For Q2: We stopped the free SSL certificate after Apple announcement, it is announced in our free SSL website;
For Q3: I am the Acting CEO now till the new CEO arrives.


Best Regards,

Richard

From: Eric Mill [mailto:er...@konklone.com]
Sent: Monday, October 24, 2016 12:05 PM
To: Richard Wang <ric...@wosign.com>
Cc: Kathleen Wilson <kwi...@mozilla.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Remediation Plan for WoSign and StartCom

Hi Richard,

A few questions -

1) Your post says "There will be new SSL certificates issued by a new WoSign intermediate CA which is signed by the one of global trusted root CA, it supports all the browsers (including Firefox). This will be done within one months."

How will this WoSign intermediate CA be different from the 4 affected roots? Will it use the same WoSign issuance infrastructure used by the 4 roots that Mozilla has decided to distrust?

2) Your announcement to customers only discusses Mozilla's action. Are you planning to inform customers of how Apple's decision to distrust WoSign's roots will affect WoSign operations?

3) A previous Qihoo 360 document said that you are being removed as WoSign CEO. Are you still authorized by Qihoo 360 to make announcements like this?

-- Eric

On Sun, Oct 23, 2016 at 10:46 PM, Richard Wang <ric...@wosign.com<mailto:ric...@wosign.com>> wrote:
Hi Kathleen,

WoSign released the news today since I just came back from USA CABF meeting.

http://www.wosign.com/news/announcement_about_Mozilla_Action_20161024.htm (in Chinese)

https://www.wosign.com/english/News/announcement_about_Mozilla_Action_20161024.htm (in English)

Best Regards,

Richard

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+richard<mailto:dev-security-policy-bounces%2Brichard>=wosig...@lists.mozilla.org<mailto:wosig...@lists.mozilla.org>] On Behalf Of Kathleen Wilson
Sent: Friday, October 21, 2016 10:43 AM
To: mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-s...@lists.mozilla.org>
Subject: Re: Remediation Plan for WoSign and StartCom

On Thursday, October 20, 2016 at 6:59:08 PM UTC-7, Percy wrote:
> Kathleen,
> As most users affected by this decision are Chinese, will you be able to make the blog post available in Chinese on the security blog as well? You can ask the Chinese firefox community or me to translate.
>
> As I stated earlier, there are almost no news of the distrust of WoSign/StartCom on the Chinese Internet and WoSign/StartCom has not posted anything related to this. I believe it's paramount to prepare Chinese website owners for the phasing out of the affected roots.

Noted. I will look into how to get it translated into Chinese and how to make that version available as well.

Thanks,
Kathleen

_______________________________________________
dev-security-policy mailing list

dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>

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

dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy



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

[Samuel Pinder]

There's some good questions there, actually. OEM SSL, does that mean
another CA would be doing the validation and issuing using their own
infrastructure and team, which you would be reselling via a
constrained intermediate? I don't think it'd be a good idea at present
to be gaining effectively a new CA certificate that is cross-signed,
only to be using the existing infrastructure that is currently meant
to be undergoing remediation. That'd probably be put under the same
restrictions too if that's the case.
Samuel Pinder

> https://lists.mozilla.org/listinfo/dev-security-policy

[Gervase Markham]

On 22/10/16 20:41, Peter Bowen wrote:
> According to the wiki, Asseco Certum has cross-signed at least one of
> these roots. Is it expected that Certum will take any action, or do
> the above changes mean that Certum's cross-sign of WoSign will be
> considered to not exist for the purpose of Mozilla policy?

Certum are aware of the situation and may have their own comments to
make. But it is certainly not Mozilla's intention to allow our policy
decisions to be circumvented by cross-signing. (This is not saying that
Certum's intent was to do this!)

Gerv

[Gervase Markham]

On 24/10/16 06:55, Samuel Pinder wrote:
> There's some good questions there, actually. OEM SSL, does that mean
> another CA would be doing the validation and issuing using their own
> infrastructure and team, which you would be reselling via a
> constrained intermediate?

I suspect he means that the other CA will do validation and issuance,
and WoSign will be a sales channel. But Richard is welcome to clarify.

Of course, if parts of WoSign's infrastructure are involved in the
certificate issuance or validation process, those parts would become
subject to the audits of the other CA.

Gerv