On Fri, 15 Feb 2019 05:05:16 -0800 (PST) info--- via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> Feb 14th 13:28 -> reported the incident to our PKI software > manufacturer > Feb 14th 15:24 -> received the answer from the > manufacturer. They tell us that there’s a bug in the preventive > filter with the OU, and that they have a hotfix to solve it. > Feb 14th 17:21 -> Izenpe reports to mozilla.dev.security.policy list One value from incident reports is that other participants can learn from what has happened rather than having to learn only from their own experiences. With that in mind, two thoughts 1. This incident report doesn't tell me whether the "PKI software manufacturer" has other customers in the Web PKI. We should definitely want not only Izenpe but any other participating CAs using the same software to apply a fix for this issue or verify that they're unaffected. The most trivial way to achieve that would be for Izenpe to tell us the name of this manufacturer and any other info (e.g. patched build numbers, manufacturer's internal bug tracker codes) other CAs (which are obliged to watch m.d.s.policy by Mozilla rules) should follow. However it may be that this is too commercially sensitive, and if that is the case Izenpe (and other CAs who find themselves in a similar situation) should I think make sure the "PKI software manufacturer" tells any other customers who may be affected, and add comments to this effect in the Incident follow-up so that those following along know it was taken care of, without it being made public which exact CAs are using the same vendor's software. 2. Where third party software is essential to the Web PKI, I'd encourage openness from this "PKI software manufacturer" and anybody else in the like business. That could mean participating here (you needn't mention specific customers if that's a problem) or it could mean setting up some a continuing discussion elsewhere, especially if it's going to inevitably drift far from Mozilla's focus. There's plenty to discuss about security of these products without straying into commercially sensitive issues like pricing or non-security features, but it feels as though in reality a lot of the time the makers don't talk to one another, which can mean the same problem recurs in different software since lessons were not passed on, the exact thing m.d.s.policy Incident reports are intended to prevent. Nick. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
