Summary

Transit Secret Engine currently supports ECC keys for signature purpose, but it does not support ECDH key agreement allowing Alice and Bob to derive a shared secret.

Problem Statement

This feature would allow different OpenBao instances to exchange data protected with keys derived from a shared secret. The security of the exchanged data would not rely solely on the TLS security.

User-facing description

When deploying a hierarchical structure of OpenBao instances, this feature allows to setup a secure channel between two OpenBao instances (Alice = instance 1, Bob = instance 2, for example).

Technical Description

The Transit API should support new ECC key types for ECDH: ecdh-p256, ecdh-p384, ecdh-p521.

When creating a ECDH key, the API should support an attribute for specifying whether the new key is ephemeral or not (i.e. persistent, if not ephemeral).

The Transit API should support a new path ("derive") to be used with the new key type ECDH for deriving a shared secret.
The derivation endpoint should support the creation of a symmetric key.
A specific attribute of the API should indicate whether this derived key is ephemeral or not.

Rationale and alternatives

This is a new feature that should not break the compatibility with the existing Transit features.

Downsides

No response

Security Implications

No response

User/Developer Experience

No response

Unresolved Questions

No response

Related Issues

The initial discussion around supporting ECDH is here: #556

Proof of Concept

No response