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, 

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

Reply via email to