The WoSign affair shows that there exist serious deficiencies and vulnerabilities in the Web PKI (and PKI in general).
1. Certificates are clearly not acceptable revocation vectors. WoSign is known to be cross-signed by several independent CAs (as well as 1 CA which is no longer deemed to be independent). If it wished to bypass any attempt to distrust it, all it would have to do is be cross-signed by another CA. Because we don't have any idea how many cross-signing links actually exist to it, it's inappropriate to proceed on the hypothesis that all have been found and properly added to a CRL. Instead, public keys need to be able to be individually distrusted, no matter what identities they're certified with or who they're certified by. Once a CA's public key is distrusted, cross-certificates of that key would no longer be valid certification paths. 2. There is only One Certificate Path that can be proven in TLS, which prevents risk management by end-entities. The primary reason why CAs have historically not been fully and unilaterally distrusted is because of the damage that would be done to the certified end-entities by distrusting the One Certificate Chain that can be provided via TLS. We need a means to provide multiple certificate chains simultaneously, with 1/N of those chains needing to pass verification in order for the connection to be deemed authentic. (No, it's not acceptable for clients to send lists of the CAs that they will accept, because that would be a very useful fingerprinting technique. Servers also send lists of CAs they'll accept client certificates from, but much of the time they send '*' and do the actual verification processing at application level.) In 2011, there existed a protocol (but not a protocol implementation) which could do so. It was presented to two engineers from Mozilla. It was met and received with no interest, referred instead to IETF where it was laughed at. 3. Mozilla has been complicit in the perpetuation of these deficiencies. In 2011, Dan Veditz and Bryan Smith (both at that time of Mozilla) were presented with the sketch of a protocol which could do simultaneous multiple certificate chain presentment with Proof of Possession without modification to the TLS protocol's capacity for only a single Proof of Possession. It would have required the creation of a new certificate validator, and could be signaled to the server as acceptable by the creation of a new TLS extension (which would have been side-by-side with the SCSV and SNI extensions in the handshake). There was no interest. This protocol would have permitted end entities to have multiple certificate chains from multiple providers, so that they wouldn't have had to go into crisis mode if one of their providers was distrusted. It also would have permitted in-protocol stapling of all necessary OCSP responses for validation. In other words, the One True Certificate issue (which has been known for several years as being the main reason why issuers could not be simply distrusted) has been worked around and worked around and worked around -- most recently with Certificate Transparency -- when the actual reason for the problem was simply "end entities cannot do risk management within the current protocols". (How do I know they were presented with this? Simple: I'm the one who presented it to them, after I was shot in the back in domestic violence and during the time I was rendered homeless for a couple of years, while on psychiatric medications that made it impossible for me to code or to advocate well enough for its adoption. I concealed these conditions from them, because of the twin fears of stigma from mental health issues and homelessness. I still have fears of these stigmas, but I'm sick of the problems existing and not being able to do anything about them.) -Kyle H _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
