> I think you're about right and it probably refers to matching public and private keys for CAs in SSL/TLS, looking up suitable intermediate CAs, for which they may have a few keys stashed away.
Compromise of a CA's key does not permit decryption of traffic encrypted by server keys that use certificates (signatures) from those CAs. This is a common misconception.
It would allow for issuing (signing) a rogue, second key that could then be used to silently active MITM a connection - but getting the CA's key does not give you the VPN server's key.
(Remember, a certificate is just a signature by a CA over the hash of the VPN server's public key. The CA never sees the private key of the VPN server, nor is the CA's key used for anything other than signing.)
Yes, but they're man-on-the-side already, and they already have the QUANTUM set of attacks and similar for actively racing an MITM on any TCP/UDP/ESP/etc/IP connection they want - and if they have a CA trusted for the purpose by the relevant endpoint, they can safely man-in-the-middle TLS, IPSec, etc.
That's what the diagram shows, essentially: the front end of that attack.
Compromise of a CA's key does not permit decryption of traffic encrypted by server keys that use certificates (signatures) from those CAs. This is a common misconception.
It would allow for issuing (signing) a rogue, second key that could then be used to silently active MITM a connection - but getting the CA's key does not give you the VPN server's key.
(Remember, a certificate is just a signature by a CA over the hash of the VPN server's public key. The CA never sees the private key of the VPN server, nor is the CA's key used for anything other than signing.)