| 1 |
On 6/1/21 3:38 PM, Michael Orlitzky wrote: |
| 2 |
> *Any* CA can just generate a new key and sign the corresponding |
| 3 |
> certificate. |
| 4 |
|
| 5 |
This is where what can /technically/ be done diverges from what is |
| 6 |
/allowed/ to be done. |
| 7 |
|
| 8 |
CAs adhering to the CA/B Forum's requirements on CAA records mean that |
| 9 |
they aren't allowed to issue a certificate for a domain that doesn't |
| 10 |
list them in the CAA record. |
| 11 |
|
| 12 |
If a CA violates the CAA record requirement, then the CA has bigger |
| 13 |
issues and will be subject to distrusting in mass. |
| 14 |
|
| 15 |
Certificate Transparency logs make it a lot easier to identify if such |
| 16 |
shenanigans are done. -- I think that the CA/B Forum is also requiring |
| 17 |
C.T. Logs. |
| 18 |
|
| 19 |
Also, CAs /should/ *NOT* be generating keys. The keys should be |
| 20 |
generated by the malicious party trying to pull the shenanigans that |
| 21 |
you're talking about. |
| 22 |
|
| 23 |
> All browsers will treat their fake certificate corresponding to the |
| 24 |
> fake key on their fake web server as completely legitimate. The "real" |
| 25 |
> original key that you generated has no special technical properties |
| 26 |
> that distinguish it. |
| 27 |
|
| 28 |
Not /all/ browsers. I know people that have run browser extensions to |
| 29 |
validate the TLS certificate that they receive against records published |
| 30 |
via DANE in DNS, which is protected by DNSSEC. So it's effectively |
| 31 |
impossible for a rogue CA and malicious actor to violate that chain of |
| 32 |
trust in a way that can't be detected and acted on. |
| 33 |
|
| 34 |
|
| 35 |
|
| 36 |
-- |
| 37 |
Grant. . . . |
| 38 |
unix || die |
Archives