On 03/10/2016 20:41, Kyle Hamilton wrote:
The WoSign affair shows that there exist serious deficiencies and vulnerabilities in the Web PKI (and PKI in general).
For starters, you need to recheck your terminology.
1. Certificates are clearly not acceptable revocation vectors.
You mean "revocation subjects"? "revocation targets"? A revocation vector is something that spreads/communicates the revocation of something, not that which is thereby revoked.
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.
This is the reason for the recent and repeated insistence by Mozilla that all the CAs still trusted need to disclose all the cross certificates they have issued.
2. There is only One Certificate Path that can be proven in TLS, which prevents risk management by end-entities.
Are you sure, I thought the standard TLS protocol transmitted a *set* of certificates in which the client could/should search for a chain leading to a client trusted CA. For example, this is how cross- certificates are often used by servers: Send the cross certificate for the benefit of those clients that don't trust the (newer) root that leads to the server cert.
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.
The big limitation here is that most CAs have conditions of certification that end entities are not allowed to submit the same public key more than once, thus ensuring that each end entity public key would be in only one cert from one CA.
(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.)
Even more servers send '' and don't want a client cert at all.
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.
Because IETF took over all protocol development when SSL3 was replaced by TLS 1.0, perhaps?
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
"Proof of Possession" is the signature the end-entity sends to the CA to prove it has the private key that it wants a certificate for. For someone talking to a TLS server, the fact of the server using the private key during the handshake is all the proof of possession that could be needed.
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.
Maybe because the technical proposal contained as many errors as your text above?
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".
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
