On Wednesday, August 9, 2017 at 5:50:43 PM UTC-4, Peter Bowen wrote: > The point of certlint was to help identify issues. While I appreciate > it getting broad usage, I don't think pushing for revocation of every > certificate that trips any of the Error level checks is productive. > This reminds of me of people trawling a database of known > vulnerabilities then reporting them to the vendors and asking for a > reward, which happens all too often in bug bounty programs. > > I think it would be much more valuable to have a "score card" by CA > Operator that shows absolute defects and defect rate.
In one of the few times I think it's happened, I think I disagree with you, Peter. I appreciate the perspective that revocation of these certificates externalizes the cost of misissuance from the CA (responsible for it) onto the customer (who purchased the certificate), and thus a viewpoint that suggests this is somehow unjust (since it's the victim of misissuance who suffers), but I think an argument that suggests these shouldn't be revoked is similar to an argument that says those who purchased stolen merchandise should get to keep it, as long as they didn't know it was stolen. That is, if we look at it from a lens of incentives, CAs have little incentive to properly issue the certificates if the consequence of misissuance is not an immediate result, but one of potential future action. Sadly, humans are terrible at recognizing those potential long-term costs (c.f. obesity/heart disease/dental care/global warming as all examples of long-term costs with short-term benefits). While I don't disagree we should keep a scoreboard, I think it's also the right incentive - for CAs, and the overall ecosystem - to ensure that any misissuance is revoked in a timely fashion (which is currently 24 hours), because it helps encourage a market where the best step a CA can take to minimize risk to their subscribers, the ones actually paying them money and engaging in a business relationship with them, is to simply not misissue the certificates. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
