Remediation Plan for WoSign and StartCom

9168 views
Skip to first unread message

Kathleen Wilson

unread,
Oct 13, 2016, 12:50:02 PM10/13/16
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 13, 2016, 1:17:28 PM10/13/16
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 13, 2016, 1:31:06 PM10/13/16
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 13, 2016, 1:39:05 PM10/13/16
to mozilla-dev-s...@lists.mozilla.org
在 2016年10月14日星期五 UTC+8上午12:50:02,Kathleen Wilson写道:
Is this the final decision or still pending?

Kathleen Wilson

unread,
Oct 13, 2016, 1:43:50 PM10/13/16
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 13, 2016, 2:07:20 PM10/13/16
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 13, 2016, 3:52:54 PM10/13/16
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 13, 2016, 6:26:27 PM10/13/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 13, 2016, 6:42:15 PM10/13/16
to mozilla-dev-s...@lists.mozilla.org
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 ?
Message has been deleted

Matt Palmer

unread,
Oct 13, 2016, 9:21:36 PM10/13/16
to dev-secur...@lists.mozilla.org
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

unread,
Oct 14, 2016, 4:14:50 AM10/14/16
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 14, 2016, 4:19:39 AM10/14/16
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 14, 2016, 4:29:11 AM10/14/16
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 14, 2016, 4:35:01 AM10/14/16
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 14, 2016, 4:47:19 AM10/14/16
to Matt Palmer
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

unread,
Oct 14, 2016, 5:41:56 AM10/14/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 14, 2016, 5:51:31 AM10/14/16
to Rob Stradling
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

unread,
Oct 14, 2016, 5:53:17 AM10/14/16
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 14, 2016, 6:38:30 AM10/14/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 14, 2016, 7:49:23 AM10/14/16
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 14, 2016, 10:47:39 AM10/14/16
to Rob Stradling
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

unread,
Oct 14, 2016, 10:52:12 AM10/14/16
to Rob Stradling
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

unread,
Oct 14, 2016, 11:04:43 AM10/14/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
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.
Message has been deleted

Ryan Sleevi

unread,
Oct 14, 2016, 4:21:44 PM10/14/16
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 14, 2016, 5:24:37 PM10/14/16
to Ryan Sleevi, mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 14, 2016, 5:38:15 PM10/14/16
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 14, 2016, 8:09:24 PM10/14/16
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 15, 2016, 4:28:45 AM10/15/16
to Hanno Böck, Ryan Sleevi, mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 15, 2016, 6:09:38 PM10/15/16
to Kurt Roeckx, Ryan Sleevi, mozilla-dev-s...@lists.mozilla.org, Hanno Böck
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

unread,
Oct 15, 2016, 6:21:27 PM10/15/16
to Eric Mill, Ryan Sleevi, Hanno Böck, mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 15, 2016, 6:26:57 PM10/15/16
to Kurt Roeckx, Ryan Sleevi, Hanno Böck, mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 17, 2016, 7:27:09 PM10/17/16
to mozilla-dev-s...@lists.mozilla.org
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




Message has been deleted

Nick Lamb

unread,
Oct 18, 2016, 4:00:57 AM10/18/16
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 18, 2016, 8:44:55 AM10/18/16
to Ryan Sleevi
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

unread,
Oct 18, 2016, 8:52:24 AM10/18/16
to Kathleen Wilson
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

unread,
Oct 18, 2016, 8:59:38 AM10/18/16
to Nick Lamb
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

unread,
Oct 18, 2016, 9:02:37 AM10/18/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org, Kathleen Wilson
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

unread,
Oct 18, 2016, 10:18:04 AM10/18/16
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 18, 2016, 10:38:07 AM10/18/16
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 18, 2016, 11:27:17 AM10/18/16
to Kurt Roeckx
Help me understand how you get to that figure, given that their previous
audit started on November 2nd, 2015?

Gerv

Nick Lamb

unread,
Oct 18, 2016, 11:37:22 AM10/18/16
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 18, 2016, 11:40:29 AM10/18/16
to Inigo Barreira, Kathleen Wilson
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

unread,
Oct 18, 2016, 11:51:47 AM10/18/16
to mozilla-dev-s...@lists.mozilla.org
在 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

unread,
Oct 18, 2016, 12:03:48 PM10/18/16
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 18, 2016, 1:02:39 PM10/18/16
to Kurt Roeckx
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

unread,
Oct 18, 2016, 1:03:44 PM10/18/16
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 18, 2016, 1:06:50 PM10/18/16
to mozilla-dev-s...@lists.mozilla.org
Measure with a micrometer, mark with chalk and cut with an axe... it's the best you can do.

Gervase Markham

unread,
Oct 18, 2016, 1:18:28 PM10/18/16
to Peter Bowen, Kathleen Wilson
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

unread,
Oct 18, 2016, 3:47:29 PM10/18/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 18, 2016, 4:36:37 PM10/18/16
to Kurt Roeckx
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

unread,
Oct 18, 2016, 5:33:29 PM10/18/16
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 18, 2016, 5:49:24 PM10/18/16
to Ryan Sleevi, mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 18, 2016, 6:20:02 PM10/18/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 18, 2016, 6:42:18 PM10/18/16
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 18, 2016, 6:48:20 PM10/18/16
to Ryan Sleevi
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

unread,
Oct 18, 2016, 6:50:05 PM10/18/16
to Ryan Hurst
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

unread,
Oct 18, 2016, 7:04:48 PM10/18/16
to mozilla-dev-s...@lists.mozilla.org
在 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

unread,
Oct 18, 2016, 7:24:58 PM10/18/16
to mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 18, 2016, 7:38:03 PM10/18/16
to Gervase Markham, Ryan Hurst, mozilla-dev-s...@lists.mozilla.org
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

unread,
Oct 18, 2016, 7:45:47 PM10/18/16