Re: [pbs-devel] [PATCH proxmox 01/12] auth-api: move signing into the private key

[Esi Y <esiy0676+proxmox@gmail.com>]

On Tue, Feb 27, 2024 at 10:12:10AM +0100, Stefan Sterz wrote:
>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).

This is a misundertanding indeed, what I was getting at was the 
state you already came to, so be easy on me in return please (too).

Wrapping PKey<T> is not really doing much when in fact auth_key.rs does 
not really encapsulate, an AuthKey. The whole thing still looks more 
like openssl helper of some universal kind with a keyring vector 
tossed in.

For instance there's no reason to follow the openssl in this even, 
there's no need to be splitting public and private key based on what is 
just a key processing tool logic. It could be AnyKey that can generate, 
derive, etc. This could have seperate impls, e.g. V1Key, V2Key, etc. 
The ticket.rs would ideally not even get to be passing on which 
MessageDigest it wants, it would just handle the formatting.

The AnyKey would be able (or not) to do import, export, sign, verify, 
(another trait could even do encrypt, decrypt). Unless I am missing 
something, the Keyring should not allow mixing key types and would 
generically handle AnyKeys' vector with a reference to current 
signing key.

>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.

This is nice as for rotation, I am more looking at upgrading API 
situation, where I am surprised at duplicate original code elements 
such as:

if let Ok(rsa) = self.key.rsa() { ...
if let Ok(ec) = self.key.ec_key() { ...

No love for polymorphism, but also convoluted:

pub fn generate_rsa()
pub fn generate_ec()

... all in one struct. I know this was all there originally, but does 
it have to stay?

>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.

The beauty of not worrying about any of this, i.e. having it 
encapsulated would mean that e.g. one does not need to know what 
crypto or digest is in use, if it's (a)symmetric and one calls any 
function, AneKey would know best which key to use for that operation. 
And ticket.rs shouldn't really care.

>what kind of traits would you propose to make such transitions even
>easier?

I suspect I get not much sympathy for the above already. I do not 
think it's making it more complicated though, more the other way 
around. Not for someone who knows difference between one time pad 
and prime fields' differences in Edwards curves.

>ps: hard wrapping your emails would be nice :)

I tried now, I hope aerc can handle format=flowed. I did set it to 
66 LaTeX-ish syndrome, but could not discriminate any further. I 
mean, I do like to uphold the good old of being conservative in 
what I send out and liberal in what I receive. Unlike some others:
https://lkml.org/lkml/2020/5/29/1038

>-- >8 snip 8< --
>
>