search

tpm2-software / tpm2-openssl

OpenSSL Provider for TPM2 integration
BSD 3-Clause "New" or "Revised" License
82 stars 36 forks source link

URI schemes are strange #71

Open dwmw2 opened 1 year ago

dwmw2 commented 1 year ago

At https://github.com/tpm2-software/tpm2-openssl/blob/1.2.0-rc1/src/tpm2-provider-store-object.c#L59 we seem to use object: as the URI scheme for... a file? Shouldn't that be file: ?

Then at https://github.com/tpm2-software/tpm2-openssl/blob/1.2.0-rc1/src/tpm2-provider-store-object.c#L63 we use handle:. That's a really strange choice; shouldn't it have tpm somewhere in the scheme name?

See https://www.ietf.org/archive/id/draft-mavrogiannopoulos-tpmuri-01.txt for example, which defined a URI scheme for TPMv1.2 keys. Let's do this properly for TPMv2 too?

Tag @jejb

gotthardp commented 1 year ago

Well, everything can be improved. The object scheme was just easier to implement.

jejb commented 1 year ago

On Fri, 2023-05-19 at 04:01 -0700, David Woodhouse wrote:

At https://github.com/tpm2-software/tpm2-openssl/blob/1.2.0-rc1/src/tpm2-provider-store-object.c#L59  we seem to use object: as the URI scheme for... a file? Shouldn't that be file: ?

Technically it is. The default file scheme, which every provider also uses, has an optional file: prefix.

Then at https://github.com/tpm2-software/tpm2-openssl/blob/1.2.0-rc1/src/tpm2-provider-store-object.c#L63  we use handle:. That's a really strange choice; shouldn't it have tpm somewhere in the scheme name?

See https://www.ietf.org/archive/id/draft-mavrogiannopoulos-tpmuri-01.txt  for example, which defined a URI scheme for TPMv1.2 keys. Let's do this properly for TPMv2 too?

Tag @jejb

You want to know what I use in my provider? By default //nvkey for backwards compatibility with the engine:

https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/tree/src/provider/store.c#n14

But it's also settable to anything in the config file.

James

dwmw2 commented 1 year ago

You want to know what I use in my provider?

I don't want to know anything :) I especially don't want to have to teach users anything.

Well, I lie. What I want to teach users is basically what I've put into the Fedora packaging guidelines and http://david.woodhou.se/draft-woodhouse-cert-best-practice.html — which in redux is:

jejb commented 1 year ago

On Fri, 2023-05-19 at 05:30 -0700, David Woodhouse wrote:

You want to know what I use in my provider?

I don't want to know anything :) I especially don't want to have to teach users anything.

Well, I lie. What I want to teach users is basically what I've put into the Fedora packaging guidelines and http://david.woodhou.se/draft-woodhouse-cert-best-practice.html — which in redux is:

  Any software which accepts a key in a file shall accept any half-sane key format and Just Work™   Any software which accepts a key in a file shall accept the standard TPMv2 PEM format and Just Work™   Any software which accepts a key in a file shall accept a RFC7512 PKCS#11 URI (pkcs11:...) instead of a filename and Just Work™    ... and the bit I'm seeking to add for TPMv2 NV storage, which is:   Any software which accepts a key in a file shall accept the standard tpmkey: URI format instead of a filename and Just Work™

The RFC isn't good enough. It says tpmkey: where can be file name (prefixed with file=), UUID (prefixed with UUID=) and pkcs11 prefixed with (storage=). The latter is wrong because pkcs11 keys are identified with the pkcs11: prefix in the pkcs11 provider and we shouldn't be different, but I think the spec doesn't mean pkcs11 at all, it's trying to identify a storage location, which, again, isn't a tpm2 thing. The former is wrong because the file store already uses the file: prefix, which seems sensible and is used for all file types, so we shouldn't deviate.

What we have in TPM2 are hex NV key addresses begining with 0x81 MSO. We could probably all agree on tpmkey:81 as the key format but someone, somewhere should state it. We can also use an NV MSO 0x01 for certificates (that's where the EK cert should be), but that would be something like tpmkey:01

 ... for which you lot have to agree on a URI form that actually makes sense, and I present @.***'s older TPMv1.2 draft](https://www.ietf.org/archive/id/draft-mavrogiannopoulos-tpmuri -01.txt) an example of such.

That just doesn't really work for tpm2 keys because they only have the NV index form. In place of the UUID, you could use the key name (which is a hash over the public area) but that would again require spec work (and either specification of the hash or a binding decision on which one to use) and would also involve us in searching.

James

dwmw2 commented 1 year ago

Agreed. Files have no place in such a URI format because we have file: URIs for that, and the standard PEM form that we've already agreed on covered by your doc at : https://www.hansenpartnership.com/draft-bottomley-tpm2-keys.html

The other parts of that older draft made sense for TPMv1.2 but things are different for TPMv2 so a new definition is needed. I was merely presenting it as an example of the genre.

AndreasFuchsTPM commented 1 year ago

FWIW my 2 cents:

I agree that object: is weird.

Proposal:

dwmw2 commented 1 year ago

These URIs should be considered not just in the context of the TPM2 engine/provider, but the context of the user and the application.

The user provides a string describing the key to be used. If that's a filename (prefixed with file: or otherwise), then if it happens to contain a -----BEGIN TSS2 PRIVATE KEY----- then the TPM2 code should handle it. If the user provides something starting with pkcs11: then that's a RFC7512 URI and some other code should handle it. I'll grant you tss2: or some variant thereof as a way to identify keys in NV storage.

But I question whether handle: makes sense, and especially the bare 0x81000001 string. Maybe you could allow those to work when explicitly dealing with the TPM2 engine or provider, but that should never be the case in the ideal world.

No application or crypto library should have to look at a string starting handle: or just 0x81... and say "oh, that looks like the TPM2 provider wants it".

dwmw2 commented 1 year ago

I finally got round to updating http://david.woodhou.se/draft-woodhouse-cert-best-practice.html to include TPMv2 support. It references James's ASN.1 draft but laments the lack of a URI form for TPMv2 as I didn't think I could use https://github.com/tpm2-software/tpm2-openssl/issues/71#issuecomment-1560914554 as a normative reference.

I'd love to see that defined somewhere I can reference it, even if it's just an extra one-line section in James's doc?