On June 2, 2021 1:51:06 AM UTC, Grant Taylor <gtay...@gentoo.tnetconsulting.net> wrote: >On 6/1/21 3:38 PM, Michael Orlitzky wrote: >> *Any* CA can just generate a new key and sign the corresponding >> certificate. > >This is where what can /technically/ be done diverges from what is >/allowed/ to be done. > >CAs adhering to the CA/B Forum's requirements on CAA records mean that >they aren't allowed to issue a certificate for a domain that doesn't >list them in the CAA record. > >If a CA violates the CAA record requirement, then the CA has bigger >issues and will be subject to distrusting in mass. > >Certificate Transparency logs make it a lot easier to identify if such >shenanigans are done. -- I think that the CA/B Forum is also >requiring >C.T. Logs. > >Also, CAs /should/ *NOT* be generating keys. The keys should be >generated by the malicious party trying to pull the shenanigans that >you're talking about. > >> All browsers will treat their fake certificate corresponding to the >> fake key on their fake web server as completely legitimate. The >"real" >> original key that you generated has no special technical properties >> that distinguish it. > >Not /all/ browsers. I know people that have run browser extensions to >validate the TLS certificate that they receive against records >published >via DANE in DNS, which is protected by DNSSEC. So it's effectively >impossible for a rogue CA and malicious actor to violate that chain of >trust in a way that can't be detected and acted on.
From my understanding its all based on trust and faith unless I take steps from my side. That doesnt seem very safe. Tech should be based on tech. Not faith and trust on the other party. Marinus
pEpkey.asc
Description: application/pgp-keys
