[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CUHEL5OD3UR8.FRBWNF6MTP1Y@suppilovahvero>
Date: Tue, 01 Aug 2023 21:01:12 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Peter Gonda" <pgonda@...gle.com>,
"Dan Williams" <dan.j.williams@...el.com>
Cc: <dhowells@...hat.com>,
"Kuppuswamy Sathyanarayanan"
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
"Dionna Amalie Glaze" <dionnaglaze@...gle.com>,
"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
"Samuel Ortiz" <sameo@...osinc.com>, <peterz@...radead.org>,
<linux-coco@...ts.linux.dev>, <keyrings@...r.kernel.org>,
<x86@...nel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] keys: Introduce tsm keys
On Mon Jul 31, 2023 at 7:33 PM EEST, Peter Gonda wrote:
> What is the purpose of this report? What does it prove to whom? I'm a
> bit confused because it doesn't seem like there is an ability for a
> remote party to participate in a challenge and response to introduce
> any freshness into this protocol.
>
> Also shouldn't the report have a little more context into the key we
> are signing? For instance what type of public key is this? And what is
> its purpose? In your example this isn't even a valid public key.
Yeah, I agree.
It is pretty hard to even evaluate whether this should be in kernel or
could handled by the user space (perhaps with something less intrusive
added to the kernel).
With cover letter starting with not one but two three letter acronyms
that are not common vocabulary is already a red flag for me at least.
A lot more clarity is needed on what the heck this thing is anyway.
BR, Jarkko
Powered by blists - more mailing lists