Re: StartCom & Qihoo Incidents

[Peter Gutmann]

Peter Bowen  writes:

>I think you found the "wrong" True Thrive Limited.

Ah, thanks.

>This appears to just be a name collision.  Naming is hard :(

Actually if you think that's tough, try figuring out who the real Midco is...

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

Re: StartCom & Qihoo Incidents

[Peter Bowen]

On Sat, Oct 22, 2016 at 9:08 PM, Peter Gutmann
 wrote:
> popcorn  writes:
>
>>There were comments admonishing StartCom and WoSign for not reporting change
>>of ownership in a timely manner.
>>
>>I am not sure if this has been reported earlier, but if not, then Qihoo 360
>>change of ownership may be relevant to the current discussion:
>>
>>http://www.prnewswire.com/news-releases/qihoo-360-announces-completion-of-merger-300299435.html
>
> If I've followed this complicated trail of breadcrumbs correctly, since Qihoo
> 360 is now "a wholly owned subsidiary of Midco" where Midco is True Thrive
> Limited, then True Thrive is a subsidiary of Greenland Hong Kong Holdings
> Limited:
>
> http://www.bloomberg.com/research/stocks/private/snapshot.asp?privcapId=252817367
>
> which is a subsidiary of Greenland Group:
>
> http://www.greenlandhk.com/pages/en/intro.html
>
> which is the Chinese government (as a state-owned enterprise).

I think you found the "wrong" True Thrive Limited.
https://www.miaxoptions.com/sites/default/files/alert-files/QIHU_Merger_39333.pdf
states that the True Thrive Limited involved in the Qihoo transaction
is a wholly owned subsidiary of Tianjim Qixin Tongda Technology Co.,
Ltd. 
https://www.chinatechnews.com/2016/04/27/23475-qihoo-360s-privatization-approved-by-ndrc
provides information on the buyers, none of whom are Greenland group.

This appears to just be a name collision.  Naming is hard :(

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

Re: StartCom & Qihoo Incidents

[Peter Gutmann]

popcorn  writes:

>There were comments admonishing StartCom and WoSign for not reporting change
>of ownership in a timely manner.
>
>I am not sure if this has been reported earlier, but if not, then Qihoo 360
>change of ownership may be relevant to the current discussion:
>
>http://www.prnewswire.com/news-releases/qihoo-360-announces-completion-of-merger-300299435.html

If I've followed this complicated trail of breadcrumbs correctly, since Qihoo
360 is now "a wholly owned subsidiary of Midco" where Midco is True Thrive
Limited, then True Thrive is a subsidiary of Greenland Hong Kong Holdings
Limited:

http://www.bloomberg.com/research/stocks/private/snapshot.asp?privcapId=252817367

which is a subsidiary of Greenland Group:

http://www.greenlandhk.com/pages/en/intro.html

which is the Chinese government (as a state-owned enterprise).

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

Re: Remediation Plan for WoSign and StartCom

[Peter Bowen]

On Thu, Oct 20, 2016 at 1:57 PM, Kathleen Wilson  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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

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

-- 
begin  .sig
< Jernej Simončič ><>◊<>< jernej|s-ng at eternallybored.org >
end
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

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


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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Jakob Bohm]

On 21/10/2016 10:38, Han Yuwei wrote:


I think this is a major mistake and a investgation should be conducted for CPS 
is a critical document about CA. This is not just a translation problem but a 
version control problem. Sometimes it can be lying.



Let me try to be more specific:

When publishing a document called CPS version 4.3 the document with
that number must have the same contents in all languages that have a
document with that name and version number.

When making any change, even just correcting a mistyped URL, the
document becomes a new document version which should have a new and
larger number than the number of the document before the change.
Thus when a published document refers to a broken URL on your own
server, it is often cheaper to repair the server than to publish a new
document version.  Some of the oldest CAs have been proudly
publishing their various important files at multiple URLs corresponding
to whatever was mentioned in old CP and CPS documents etc., only
shutting down those URLs years after the corresponding CA roots were
shut down.

There can also be a "draft" document which has no number and which
contains the changes that will go into the next numbered edition.  Such
a "draft" would have no official significance, as it has not been
officially "published".  For a well-planned change, the final "draft"
would be translated and checked into the relevant languages (e.g.
Chinese with mainland writing system, Chinese with Hong Kong and Macao
Special Administrative Regions old writing system, English), before
simultaneously publishing the matching documents with the same number
on the same day.

There are infinitely many version numbers in the universe to choose
from.  There are also computer programs that can generate new version
numbers every time a draft is changed, but computers cannot decide when
a version is good enough in all languages to make an official
publication, and the computer generated version numbers are often
impractical for publication because they count all the small steps that
were not published.


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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Please avoid S/MIME signatures when posting to this group

[Jakob Bohm]

On 22/10/2016 02:24, Gervase Markham wrote:

On 21/10/16 17:21, Eric Mill wrote:

Can you confirm whether this affects people who subscribed through Google
Groups but participate via email, or whether it only impacts users who read
the list through the Google Groups web interface?


The lack-of-message affects everyone who views the Google Groups web
interface. It's not certain how to trigger the bug. I sent an
S/MIME-signed message to mozilla.test successfully via the newsgroup
gateway, so assuming the bug applies equally to all Mozilla groups,
that's not a problematic path. But there are several paths to posting.

If anyone wants to narrow this down, I'm sure the Groups team would
appreciate the further information.



I think he was asking if such messages are forwarded by Google Groups
to people who (somehow, I don't use it) tell Google Groups to forward
the mailing list to them.


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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Draft Email - Non-Disclosed SubCAs

[Jakob Bohm]

On 21/10/2016 00:24, Gervase Markham wrote:

On 20/10/16 15:05, Kathleen Wilson wrote:

You are receiving this email because our records indicate that there
are non-technically-constrained intermediate certificates that chain
up to your root certificates that are included in Mozilla’s program
that have not been entered into the CA Community in Salesforce.
Please complete this requirement by November 14, 2016.


I don't think we should set another deadline. We should remind them that
the deadline was June, tell them to do it ASAP, and warn them that we
could begin discussions about taking action at any time.


of Mozilla's CA Certificate Inclusion Policy, you are required to
provide public-facing documentation about the certificate
verification requirements and annual public attestation of
conformance to said requirements.


There is an open question, raised by Peter Bowen in CAB Forum, of what
to do about intermediate CAs which were created since the last audit. We
should work out what to do about that, at least in the short term,
before sending this message.



I think this could be covered together with the other issue you
mentioned by a text similar to:

For CA certificates signed or cross signed after the June deadline,
there is an ongoing requirement to enter them within ? calendar days
(?? hours) after signing them, preferably earlier.

For all the CA certificates entered in SalesForce, there is an ongoing
requirement to keep the information up to date, e.g. when there are
updates to audit reports, policy documents, ownership etc.  Generally
within ?? calendar days (??? hours) after these changes occur.  In
particular, changes of ownership should be reported as soon as they are
operational facts, even if the legal process of ownership change has
not yet completed.



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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla Root Store Elsewhere (Was Re: StartCom & Qihoo Incidents)

[Jakob Bohm]

On 18/10/2016 20:40, Eric Mill wrote:

The first thing that comes to mind is to define an intermediate
representation of per-root constraints, that Mozilla can distribute
alongside certdata.txt.

The simplest piece would be name constraints, but incorporating things like
CT constraints and date-based constraints would clearly be useful.

I think the tricky part would be deciding which things should go into the
data and which should go into the code. The spectrum could run all the way
from having the data store store all of "one Google and one non-Google log,
where certificates whose length is over X days require Y SCTs, etc." to
something as simple as "apply [the standard for this client] CT policy" and
having clients decide/iterate on what their preferred CT constraint policy
is. (I suspect the right answer is closer to the latter, but I don't manage
a client that performs TLS validation.)



I don't know the format of certdata.txt (since I am not the one who
clones it, or one of its historic formats(!)), but perhaps a simple
solution would be if that file was allowed, for each trust bit, to
specify the "third boolean value": Maybe, aka "X", aka "?".

That would signify, that for that particular trust bit, that there are
additional rules that a cloner need to look up and consider how this
applies to inclusion in his/her particular repository.

There should also be a web page, updated *before* the NSS code, with
those additional rules, as decided by the module owner.

Also there should obviously be a ChangeLog for certdata.txt split into
a "big news" document containing messages such as

"as of version X.Y.Z, the codesigning trust bit is no longer valid, and
roots that are only trusted for code signing have been omitted as if
they were distrusted, even though they might not be, Mozilla just isn't
tracking them anymore (Bugzilla #12345678)"
"As of version X.Y.Z, the trust bits columns in certdata.txt may now
contain the character (whatever) to indicate that trust for that
purpose is limited by a specific rule listed on the web page
https://foo.mozilla.org/bar/baz.  Changes to those rules will be listed
in the certdata ChangeLog even if the certdata.txt line was technically 
not changed (Bugzilla #12345678)"


While the main ChangeLog would also contain more normal changes such as:

"As of version X.Y.Z, WoSign was changed from trusted to maybe in
preparation for full distrust at a future date (Bugzilla #12345678)"
"As of version X.Y.Z, LetsEncrypt was added as trusted for TLS
(Bugzilla #12345678)"
"As of version X.Y.Z, certdata.txt is now encoded in UTF-8, previously
it was in ISO-8859-1 (Bugzilla #12345678)"
"As of version X.Y.Z, Geotrust root ABC was removed, because it is now
only trusted for codesigning, at the request of Symantec, and Mozilla
doesn't track codesigning (Bugzilla #12345678)"

(Of cause all of this would be in a more regular changelog format,
compatible with Mozilla internal procedures, the main point is to
include brief snippets that help downstream stores understand how a
change should be interpreted, with a special highlighting of changes
that affect the downstream import at a conceptual rather than just a
technical level).

Each of my examples above are examples of changes that could (and have
apparently in the past) lead downstream stores astray without that
tidbit of information.

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Ryan Sleevi]

On 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Globalsign accidental intermediate revocation incident

[Jakob Bohm]

On 18/10/2016 20:50, douglas.beat...@gmail.com wrote:

On Monday, October 17, 2016 at 4:19:34 PM UTC-7, Jakob Bohm wrote:

On 16/10/2016 09:59, Adrian R. wrote:

Hello

i read in the news (but not here on m.d.s.p) that a few days ago Globalsign 
revoked one of their intermediary roots and then un-revoked it (well, the 
revocation is accidental, but it was still a properly announced revocation, via 
signed CRL and OCSP).


The official report is available here:
  https://www.globalsign.com/en/customer-revocation-error/



Yes, I read the full report, I was nitpicking the bad communication
skills of whomever GlobalSign assigned to write the contents of the web
page (as it existed at that time).

Seems only fair to nitpick a western CA in perfect standing when we are
being so harsh on a Chinese CA in much worse standing.


To be clear, an intermediate root (not sure what this is tbh) was never revoked 
- we revoked a cross certificate between roots R2 and R1 and an unused/EOL CA 
under R2.  These correctly appeared and continues to appear on the CRL, in fact 
it was included on the October 7th Root R1 CRL well before the OCSP incident.





http://www.theregister.co.uk/2016/10/15/globalsign_incident_report/

They rolled back the revocation, but i thought that the BRs explicitly forbid 
that a suspended/revoked certificate be un-suspended/un-revoked.

https://www.globalsign.com/en/customer-revocation-error/

is this revival/un-revocation of an intermediary CA allowed by the BRs?




I have just read that page, and find it utterly confusing and badly
written.  Lot's of formal tone of voice, but no precision or clarity.

What I would have expected was a much clearer statement (on the page,
not in some linked document) as to:


I hope my responses help clarify the situation:


1. Which Intermediary CA certificates were affected (because
   certificate holders cannot see the cache state affecting relying
   parties, we need to check our certificates against something
   specific to see if we are affected).


All CAs under Root R1 were effected.


And the page should have said that.  Or more precisely:

- All certificates whose chain goes to Root R1 before going to Root R2.

- Maybe (unclear in retrospect) certificates under root R2 on machines
 that only trust root R1 (such as Windows 8.x without auto-root
 updates), and which checked the OCSP status of the R1 to R2 cross
 cert or R1-root, at a time affected by the OCSP responder bug.

- Maybe (unclear in retrospect) certificates under root R2 if the web
 server sends the R1 to R2 cross certificate to support R1-only
 trusting machines, and the web browser uses certificates sent be the
 web server in preference to checking that its root store already
 contains R2 (a common implementation limitation), while actually
 checking for revocation of R1-to-R2 cross or R1-root, at a time
 affected by the OCSP responder bug.




2. If this affects all AlphaSSL and CloudSSL certificates or only some
   of them.


This affects the CAs under Root R1 only (AlphaSSL, DV, OV, CloudSSL).  None of 
the actual end entity SSL certificates were ever revoked or marked as revoked 
either via CRL or OCSP.  The scope of the users impacted by this depends on 
many factors, which are outlined in the report.  Not all users were blocked 
from accessing sites with SSL certificates under R1.


Yes, the report explains the cache issue clearly, but the web page
could have said something like:

  AlphaSSL SHA-1 certificates issued before/after some dates (I guess 
all of them).

  AlphaSSL SHA-256 certificates issued before some date

  CloudSSL ...
  GlobalSign branded DV ...
  GlobalSign branded OV ...




3. If this was an "exercise" (training/experimental etc.) or an actual
   operational decision.


We intentionally revoked 2 CA certificates as listed in the incident report - 
One old CA that had no live certificates issued under it, and the one cross 
certificate referenced above.



So the word "exercise" was badly chosen (an exotic use of the word,
which I am fully aware of, but which is not clear in a context where
the meaning could just as well have been for example "as part of a
disaster readiness test").


We did not take actions to revoke any CAs other than these two; however as 
pointed out, the OCSP  responders incorrectly created and provided OCSP status 
messages for CAs under R1 indicating that the CA was revoked.  These CAs never 
appeared in any CRLs.


4. If the revoked cross certificate was one of the cross certificates
   previously provided to certificate holders to allow us to make our
   servers compatible with older clients, and if so, which one.




The report explains it was not, the web page was 100% vague.




5. If this was e-mailed to all potentially affected certificate
   holders, or just dumped in some public forums which certificate
   holders might not see in time to take necessary action.


GlobalSign contacted as many of our customers as possible with SSL 

Re: Remediation Plan for WoSign and StartCom

[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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy