Re: Remediation Plan for WoSign and StartCom
> 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. Because 360 safe browser is the most dominant browser in China. Qihoo, the parent company of WoSign/StartCom produced this browser. I assume Qihoo's browser will not take any action against its own CAs. So If Mozilla or other parties is not mandating WoSign/StartCom disclose such incidents to its users, but WoSign is portraying WoSign to be this fast growing company with great security record (as WoSign's latest press release did), users of WoSign will not be able to know about the distrust, even sometime after the grace period ends (1 year or 2 year from now). Web owners will only found out after the grace period, when they somehow accessed the site with non-360 safe browser. Indeed, your announcement about CNNIC was censored in China. In fact, I monitored and broke this news. However, WoSign is not a government agency and the announcement shouldn't be censored. I suggest Mozilla at least publish a blog post in Chinese about this, but preferably mandating WoSign/StartCom to publish on its official sites to inform users about its bad security practices. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom & Qihoo Incidents
On 18/10/2016 01:22, Kurt Roeckx wrote: On Tue, Oct 18, 2016 at 12:39:42AM +0200, Kurt Roeckx wrote: On Tue, Oct 18, 2016 at 12:22:21AM +0200, Jakob Bohm wrote: Over the past few years, this has caused the Mozilla root list to become less and less useful for the rest of the open source world, a fact which at least some of the Mozilla-root-list-copying open source projects seem not to be aware of yet. I think the problems for the open source community are: 1) There is no good way to deal with revocation checking, it doesn't have anything that deals with something like OneCRL 2) Mozilla doesn't care about non-https. I wanted to add that none of this is relevant to what Ryan was saying. Maybe the root list itself is becomming less useful, but that doesn't mean the discussion list is. Also, the problems for the open source community aren't new it's just that some of Mozilla's solutions either don't work for them, they don't know about them, or they don't use it. (It's probably a combination.) In the not so distant past, the Mozilla root program was much more useful due to different behavior: 1. Mozilla managed the root program based on an assumption that relying parties would use the common standard revocation checking methods *only* (regular CRLs as present since Netscape created SSL and OCSP). 2. Mozilla managed trust bits and inclusion policies for https, non-https TLS (e.g. imaps, pops and smtps), e-mail S/MIME, and generic object/code signing. Again, this was true since the days when this was the Netscape Navigator trust list. 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: StartCom & Qihoo Incidents
On Tue, Oct 18, 2016 at 12:39:42AM +0200, Kurt Roeckx wrote: > On Tue, Oct 18, 2016 at 12:22:21AM +0200, Jakob Bohm wrote: > > > > Over the past few years, this has caused the Mozilla root list to > > become less and less useful for the rest of the open source world, a > > fact which at least some of the Mozilla-root-list-copying open source > > projects seem not to be aware of yet. > > I think the problems for the open source community are: > 1) There is no good way to deal with revocation checking, it >doesn't have anything that deals with something like OneCRL > 2) Mozilla doesn't care about non-https. I wanted to add that none of this is relevant to what Ryan was saying. Maybe the root list itself is becomming less useful, but that doesn't mean the discussion list is. Also, the problems for the open source community aren't new it's just that some of Mozilla's solutions either don't work for them, they don't know about them, or they don't use it. (It's probably a combination.) Kurt ___ 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 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). 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: 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). 2. If this affects all AlphaSSL and CloudSSL certificates or only some of them. 3. If this was an "exercise" (training/experimental etc.) or an actual operational decision. 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. 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. 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: StartCom & Qihoo Incidents
On 18/10/2016 00:39, Kurt Roeckx wrote: On Tue, Oct 18, 2016 at 12:22:21AM +0200, Jakob Bohm wrote: Over the past few years, this has caused the Mozilla root list to become less and less useful for the rest of the open source world, a fact which at least some of the Mozilla-root-list-copying open source projects seem not to be aware of yet. I think the problems for the open source community are: 1) There is no good way to deal with revocation checking, it doesn't have anything that deals with something like OneCRL 2) Mozilla doesn't care about non-https. The solution that seems to be prefered for 1) is to have mandatory OCSP stapling. But I don't see that happening any time soon. Let me add: 3) Any ad-hoc code added to Mozilla products (e.g. to apply some new checking method for WoSign certificates) will not magically appear in other code at the same time, if ever. 4) Contrary to what OCSP-stapling fans claim, it is not a panacea, and is notably missing in many server side code bases. 5) OneCRL, even if it was checked by other projects, is an arbitrary hodgepodge of CA revocations, SubCA revocations and selected end-cert revocations, that cannot possibly match the policies of anyone except its maintainers. 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: StartCom & Qihoo Incidents
On 15/10/16 00:32, Peter Gutmann wrote: > I would have expected some sort of coordinating action to provide a unified > response to the issue and corresponding unified, consistent behaviour among > the browsers, rather than the current lottery as to what a particular browser > (other than Apple and Mozilla's ones) will do when it encounters a WoSign > cert. Browsers are capable of coordinating independent of the CAB Forum. However, some browsers are concerned about doing so (for legal reasons, I believe) and so the level of coordination is limited. But actually, I think this is a feature. Root stores are a decision about who to trust. It is entirely reasonable for different people to have different views on a person or organization's trustworthiness. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
