On Tue, 2025-09-23 at 17:25 +0300, Jarkko Sakkinen wrote: > On Mon, Sep 22, 2025 at 05:31:24PM -0400, James Bottomley wrote: > > On Mon, 2025-09-22 at 11:56 +0300, Jarkko Sakkinen wrote: > > > On Thu, Sep 18, 2025 at 08:35:38PM +0300, Jarkko Sakkinen wrote: [...] > > > > The way I see it, a "random project" would apply to any project > > > > that a format is locked in, and it is quite obvious that fixing > > > > handle as the anchor is exactly fit for exactly for this > > > > project, and within those exact limits it is probably a > > > > sustainable choice. > > > > > > > > Being able to fix key into cryptographic identity is somewhat > > > > sane addition because not only does it lock-in the creator but > > > > it also allows to use offline stored keys with the same scheme > > > > i.e., non-endorsement hierarchy derived keys created with > > > > TPM2_Create or TPM2_Import. > > > > > > > > In the context of OpenSSL TPM2 engine, perhaps the current > > > > scheme is fine but in the context of supporting a "ecosystem" > > > > as a kernel feature it's not in its current form robust enough. > > > > > > > > And how else I can describe it other than I don't care about > > > > the project, if the file format enforces me align with it? > > > > > > The ASN.1 definition limits types of keys while there's no any > > > good reasons to disregard transient keys. > > > > As I explained in the bit you quote above, the spec covers volatile > > parents. > > > > > It also enforces handle numbers, which is not very robust > > > approach. > > > > I think if you read the spec, you'll find it only requires handle > > numbers for persistent keys ... specific handle numbers being a > > feature of those keys required by TPM spec. > > > > > I've neither seen any cryptographic object in my life, which uses > > > ambiguous data as part of the identity no matter how hypothetical > > > the possible threat scenarios are. It's a bad security practice > > > plain and simple. > > > > This contains no actionable technical content. However, it is > > possible the spec doesn't cover your use case, it's just you > > haven't actually outlined what your use case is, so no-one who > > knows the spec can actually confirm or deny this. > > I revisited the issue and this is how I see the situation. > > I think the most feasible approch especially for volatile keys would > be to store all structures included in TPM2_Create response, instead > of only storing the first two response parameters. Rest of the blobs > can be e.g. optional. It's the most bottleneck free way to address > any issues.
I still don't understand what issues you're referring to. However ... > Creation data contains indefinitive information about parent and this > also enable the use of tickets. This is already being discussed on the list if you want to join: https://groups.io/g/openssl-tpm2-engine/topic/patch_doc_update_draft_rfc/115384542 Regards, James
