From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 76E2195921 for ; Tue, 27 Feb 2024 19:14:09 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 541981A01 for ; Tue, 27 Feb 2024 19:14:09 +0100 (CET) Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Tue, 27 Feb 2024 19:14:07 +0100 (CET) Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-608342633b8so42511357b3.1 for ; Tue, 27 Feb 2024 10:14:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709057640; x=1709662440; darn=lists.proxmox.com; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=X40RIwYiYlhtfyUNzbJGQdZsIMPbjj+roOMctGfHBxs=; b=lrw5b3zpW8uobAqArv1TPiPPihTQ1ZPab9+ijn9fEsrz5S+j8ylBt3lhajLlcRyK97 KCvjjLft8tBVx2AGxooVGnGjyi7JpJXxCDJHiE0r8cwE0KG/zfTM83VZlp9XQLR1cJhR Q7BRYERfJakPqz3Dwx4SMN9vm5G7MjhAjUJGUCvl+OZFgTMp5lbEQru8YlnuQ1AOe5Gr z5JX5//TbOpEvvB4yhirhdj4xJKDnlBVD726G+b+qn+CFq4+htGBtw4AjPEthvCyMaCA /0Zg9zSZcQI9wxLNKCcasDXnNZEUa/lYo/jyU55ep7nl4m3duzR/BZMdSVIkKiP7ESea f5Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709057640; x=1709662440; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=X40RIwYiYlhtfyUNzbJGQdZsIMPbjj+roOMctGfHBxs=; b=JpQO/jc2LXkH2hmFmlq4IgqEcSlzkj5FLArat057OqP3VhV5V38ov5+29mdLJMUWtg 9dXPpN30mew9YR1z+jOErUzVhiBfLrGmuY5uYYseCfe+9to4FxMK27fAazMeumspOCdn qz/M1HdiF8va78engsAH+kswOw9ZvuTh0B7Ws0cD8fjpLGr2EI93iCf+vb1tUy61JvMd SZnf1DiRWUcy5zYOgI8ekgX2hRiDArRedoFgE4He899zVdZfmtK3XXTWTfYog97kHOSZ qiVhWQkz98D6kbJ/2p70pMdAVx5S4gNL7uBM4SlHIMyjPA7FwS+eI/7SOFZbcbN/xLPa k1ug== X-Gm-Message-State: AOJu0YzuPsxpE5O3JGoiK9zi0Y6TDF41h3dnM4ktbDsaRECCRNnk3e5S 4YhRvpiimS10gXJgz2VWOWCeFsKlqT9LXc5S0xWgh1zajgmyvUFDdb/kAEMhtNo= X-Google-Smtp-Source: AGHT+IE8vnM696klxMJp2wAciO6k7aFmwFGuN1YH2cDG5K8ygmcx8VY25nJYDY2ZlRqPyDVlqN0ypQ== X-Received: by 2002:a81:a7c6:0:b0:607:9504:ebf6 with SMTP id e189-20020a81a7c6000000b006079504ebf6mr2808365ywh.0.1709057640052; Tue, 27 Feb 2024 10:14:00 -0800 (PST) Received: from tema539532 ([2001:19f0:5c01:d22:5400:4ff:fe93:4e4a]) by smtp.gmail.com with ESMTPSA id g68-20020a0dc447000000b00608b8ac379fsm1919864ywd.123.2024.02.27.10.13.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Feb 2024 10:13:59 -0800 (PST) Sender: Esi Y Date: Tue, 27 Feb 2024 18:13:58 +0000 From: Esi Y To: Stefan Sterz Cc: pbs-devel@lists.proxmox.com Message-ID: References: <20240215152001.269490-1-s.sterz@proxmox.com> <20240215152001.269490-2-s.sterz@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-SPAM-LEVEL: Spam detection results: 0 AWL 0.071 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain DMARC_PASS -0.1 DMARC pass policy FREEMAIL_FROM 0.001 Sender email is commonly abused enduser mail provider RCVD_IN_DNSWL_NONE -0.0001 Sender listed at https://www.dnswl.org/, no trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pbs-devel] [PATCH proxmox 01/12] auth-api: move signing into the private key X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2024 18:14:09 -0000 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` and `PKey` respectivelly. >`HMACKey` wraps a `PKey` 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 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< -- > >