[pbs-devel] [PATCH proxmox 01/12] auth-api: move signing into the private key
Stefan Sterz
s.sterz at proxmox.com
Tue Feb 27 10:12:10 CET 2024
On Mon Feb 26, 2024 at 9:22 PM CET, Esi Y wrote:
> This might be a bit nitpicky, but wouldn't this exactly be an
> opportunity to properly introduce traits, so that in the future on the
> same kind of swapout, it is more streamlined and less regression prone
> going forward? Just wondering ... if there was a reason not to, on
> such a rewrite.
i am a bit uncertain as to what you mean here, as this series more or
less uses such wrapper traits around the openssl api. `PrivateKey` and
`PublicKey` wrap a `PKey<Private>` and `PKey<Public>` respectivelly.
`HMACKey` wraps a `PKey<Private>` that is treated as an hmac key. this
means that users of the auht-api crate don't have to use openssl to
generate keys or handle them. it also means that the implementation of
these traits is entirely private in the auth-api, so users don't need to
adapt if we extend them with support for more cryptographic schemes
(note that removing such schemes is always a breaking change).
in the future, if you needed to switch out a key you have the keyring in
the authcontext that can handle roll over (for the most part, but i am
working on the missing links here). new keys would be added as the
signing key (hence my introduction of the `SigningKey` and
`VerificationKey` enums in patch 3) the old keys would stay as
verification keys and be evicted after a given number of key rotations.
using enums here was just simple, and unless a third type of crypto
beside symmetric and asymmetric arises, this should be sufficient and
not overcomplicate the code.
what kind of traits would you propose to make such transitions even
easier?
ps: hard wrapping your emails would be nice :)
-- >8 snip 8< --
More information about the pbs-devel
mailing list