Nico Williams <[email protected]> writes: >Typically applications that support client certificates will have a list of >client _names_ that are allowed to access the service, or some other form of >authorization ultimately keyed by the client's authenticated name.
This is how rationally-written applications do things [*]. The problem is that, particularly under Windows, it's very easy to get drawn into trusting everything Windows trusts, which means in effect any cert issued by any public CA anywhere. The example I like to give for this is a developer who inadvertently got access to USG systems with a GoDaddy cert they'd bought for testing, because what was at the other end trusted anything from a CA that Windows trusted. I only know of the final end effect but I'm pretty sure the systems weren't originally set up to allow this, they just ended up in that state at some point. Does Linux have an equivalent systemwide cert store that everything ends up using? That is, do people use the NSS cert store or the Chrome cert store as a de facto equivalent of CERT_SYSTEM_STORE_LOCAL_MACHINE or whatever? Peter. [*] In my case I tell people to key off the public key fingerprint since proof of control of the user's private key is what matters, not what some random CA decides to sign. So it's more like AADS than anything-some-CA-signs-we- trust. _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
