vsecm sentinel shall be able to use nested encryption

[v0lkan]

VSecM Sentinel can be, in theory, put outside the main cluster that it's in (in a federated SPIFFE setup).

From the perspective of SPIFFE, network is already breached, so where you put VSecM Sentinel does not really matter as the security model relies on fast rotated certs, trusted attestation, and SPIFFE mTLS.

However, when the actors are outside the boundaries of the physical network (arguably when they are within the same network/trust-boundary too) a second level of encryption is fruitful.

In this "enhanced trust mode" interaction

1. At every request VSecM sentinel create two keypairs and an AES cyphertext.
2. VSecM Safe does the same thing.
3. each party validate their application-level signatures
4. the secrets are exchanged encrypted.
5. the keys are discarded at every request.

Since VSecM Sentinel is not used frequently, the computational overhead will not be too big of a burden.

Later, we can extend this approach to VSecM SDKs, and also VSecM Sidecar too.

This feature will be optional.
It will be enabled by default for VSecM sentinel.
It will be disabled by defualt for any other workload.