Support description field

[salrashid123]

if the specs alteast here mentions a "description" field which can get encoded into PEM tpm keys:

• https://www.hansenpartnership.com/draft-bottomley-tpm2-keys.html#name-description

However, it looks like that if the key contains that field, the provider fails outright.

this bug is to support reading in keys with that field:

$ openssl version
    OpenSSL 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13 30 Jan 2024)

$ cat private.pem 
-----BEGIN TSS2 PRIVATE KEY-----
MIICHAYGZ4EFCgEDoAMBAf+kBgwEZm9vbwIEQAAAAQSCARoBGAABAAsABAByAAAA
EAAUAAsIAAABAAEBAMM+R7HEMaRrnv2Ekhe15UN63VTk4Uvo4uHLumS6sIKM0/l2
0WcJLDvh53zVCx1wYdOgQbGAR/wlU82E5BhFzeMotc03KVeIFffQ2+Aj2qYPSA1X
6kEZ3yGgQnPE/wNQP0gxFh8ZDfSJiSocPLuPMXxOrmuBzKRgqJ+HNe9XFZFx02Sc
cM1A8lH5XvvqxAWvgT+pBEZIjjEf+AlkXS+LdyaSYxRBwriS65UTfYbu5PdDa5ip
/EMZKSpnu+8k8fip5T1K5bbSGGXkt6F3bz7ScO3DUF1p2xPtxRDOG8L2pgeecteu
YwrGsT+PUAQFcg2iSefX7RcwiwEFPWjpbQ/AN0MEgeAA3gAgxm9uFbP9VM3hmiwb
pC0uaZq0/C3raGyPSZkaAJb0LLwAEKxk5HjUkkmnFOZO0t/MqOnYl+9xz1txLT87
pDvUCR6sf3FbQBGvHMV//iu2Nqu7D6+P5hgQiWvqsfxXcX8P9Fz6/2RbrPTLxYB4
jRw4lv8In/kzpTJavgK+CLlgWd5IxVS2lxY6yg8GYKh/7MTNfdwzq2S9jRZoWv8/
e1fthed2sDYTFhTtrWVXbAMCuy2D0NV7gF25jTFs6CLAhL63FI6XHY8cqaV0vOv1
H5TmuZ4cWdKyOagdW/Z+6A==
-----END TSS2 PRIVATE KEY-----

$ openssl asn1parse -inform PEM -in private.pem
    0:d=0  hl=4 l= 540 cons: SEQUENCE          
    4:d=1  hl=2 l=   6 prim: OBJECT            :2.23.133.10.1.3
   12:d=1  hl=2 l=   3 cons: cont [ 0 ]        
   14:d=2  hl=2 l=   1 prim: BOOLEAN           :255
   17:d=1  hl=2 l=   6 cons: cont [ 4 ]        
   19:d=2  hl=2 l=   4 prim: UTF8STRING        :fooo        <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
   25:d=1  hl=2 l=   4 prim: INTEGER           :40000001
   31:d=1  hl=4 l= 282 prim: OCTET STRING      [HEX DUMP]

if you try to read in the key, you'll see

$ openssl rsa -provider tpm2  -provider default -in private.pem --text
Could not read private key from private.pem
40C7EFD7647D0000:error:1608010C:STORE routines:ossl_store_handle_load_result:unsupported:../crypto/store/store_result.c:151:

---

if you want to generate a new key, i wroteup a small analog for tpm2tss-genkey here in go

[gotthardp]

This project does not support the structure mentioned in the referenced document. Before implementing something I prefer to wait until the draft gets adopted by some IETF WG.

[salrashid123]

ok, thats very fair; (i thought it was actually adopted);

closing this till its official

[Foxboron]

@gotthardp Okay, which spec does this tool implement?

[salrashid123]

reopening :) (shoud've asekd that too!)

i suspect its derived back tpm2-tss-engine cited here

• TSSPRIVKEY structure specification? tpm2-tss-engine#85
• PEM file incompatibilty tpm2-tss-engine#11

which references this https://marc.info/?l=openssl-dev&m=148305587514229&w=2

so, i don't know if whats now actual standard or inuse locally only

[Foxboron]

Okay, the discussion makes it clear to me that tpm2-openssl is actually just implementing an older iteration of the spec as proposed by James in 2016.

I suspect it would be nice to standardize this format though. @jejb how should we proceed to standardize this under IETF?

[jejb]

On Thu, 2024-10-10 at 04:18 -0700, Morten Linderud wrote: Okay, the discussion makes it clear to me that `tpm2-openssl` is actually just implementing an older iteration of the spec as proposed by James in 2016.

Actually, I think this bug report indicates not properly implementing even that. The design of the spec and its enhancements was to keep everything interoperable. Part of that interoperability is simply ignoring any optional const you don't understand, which would mean the description should simply have been unused. Obviously this doesn't work for things like importable keys, where you have to understand the optional const 2 for secret, but even if you ignore it, the error occurs lower down in TPM2_Load.

I suspect it would be nice to standardize this format though. @jejb how should we proceed to standardize this under IETF?

The only thing still missing, that was asked for by Matthew Garrett, is creation data. It looks simple to do and I asked him to propose an addition. However, it's also possible to proceed without it. Regards, James

[Foxboron]

The only thing still missing, that was asked for by Matthew Garrett, is
creation data. It looks simple to do and I asked him to propose an
addition. However, it's also possible to proceed without it.

That sounds like a great addition so it's probably a good idea to wait for it. Thanks!

[salrashid123]

fwiw, openssl also also fails outright if the key has policysyntax but as above, worth awaiting it its official

for ref, i'm not sure if i did it quite right but i tried to reconstruct a basic (pcr, policyauthvalue) policy command sequence in go here and generically here. I'll file a FR for go-tpm to help convert structs<->raw_commands

[m00nwtchr]

Is there any ETA for this? I don't need support for the field, just to be able to use keys which happen to contain it.