Re: StartCom & Qihoo Incidents
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
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
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
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
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
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
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
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
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)
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
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
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 c
Re: Remediation Plan for WoSign and StartCom
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