7 ms·
It's specifically to discourage intermediate key pinning. If folks want to pin their own end-entity public key (and always re-use the same key when renewing the
by phasmantistes 2y ago
It's specifically to discourage intermediate key pinning. If folks want to pin their own end-entity public key (and always re-use the same key when renewing their cert), go for it -- dealing with compromise of their own key is their own problem to solve. Or if they want to pin a root public key to ensure some other CA doesn't issue a MITM certificate, go for it (although that doesn't prevent a bad actor from getting the same CA to issue a MITM certificate; there are other mechanisms to prevent that).
Just please don't pin intermediate CA keys, which should be opaque to the end-user and need to be able to change quickly without breaking a bunch of apps.
- agwa 2y ago> Or if they want to pin a root public key to ensure some other CA doesn't issue a MITM certificate, go for it Please don't pin roots, as that makes it harder to distrust CAs, reducing the agility of the WebPKI. See the Symantec distrust for a painful example. Chrome and Firefox will be introducing term limits on roots in the near future, which will hopefully help to discourage this harmful practice.
- gray_-_wolf 2y ago> Please don't pin roots So what would be the recommended way to protect against government MitM by using some obscure CA?
- schoen 2y agoCurrently CT logs: https://certificate.transparency.dev/ https://certificate.transparency.dev/ Monitor CT for your domain name and if you find an "obscure CA" misissuing for your domain, report it! This may result in the obscure CA getting explicitly distrusted. At some level this is not that great a solution, but it's really so much better than what we had 13-14 years ago.
- notachatbot123 2y agoAn adversary might MITM the CT as well.
- thrtythreeforty 2y agoI'm curious: What's the defense mechanism for a dodgy CA not publishing a CT log entry for the misused domain?
- woodruffw 2y agoA CT-honoring client should reject an end-entity certificate that isn't accompanied by a SCT. In other words: a dodgy CA that skips CT to avoid disclosure of their mis-issued certificate should be unable to convince any CT-honoring client to accept that certificate.
- michaelt 2y agoCT logs only mean that if after the horse has bolted, you can start the process to close the door within hours. That's adequate for low-value targets, but it's hardly sufficient for high-value targets. If a CA mis-issued a cert for *.aws.amazon.com should we be waiting around for a manual process on some mailing list to invalidate it?
- schoen 2y agoI agree conceptually, and I think it's sad that we don't have anything more absolute. (I was a fan of HPKP, which has been deprecated as a "footgun" because apparently users often didn't understand what it was doing or weren't cautious enough when using it.) But the CT system seems to work very well in practice. While the detection and remedy part is awkwardly manual, there are people working hard on them. There are also (following a "you have to disclose all intermediates ahead of time" rule introduced by Mozilla) fewer intermediates and we actually have a list of them. https://ccadb.my.salesforce-sites.com/ccadb/AllCertificateRecordsCSVFormat https://ccadb.my.salesforce-sites.com/ccadb/AllCertificateRe... Detected incidents involving intentional misissuance are very rare. When unintentional misissuance happens, the responsible CA has to publicly explain how it happened and what it will do to prevent the situation from happening again.