Open dwmw2 opened 1 year ago
Well, everything can be improved. The object
scheme was just easier to implement.
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 befile:
?
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 havetpm
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:
But it's also settable to anything in the config file.
James
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 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™
... for which you lot have to agree on a URI form that actually makes sense, and I present @nmav's older TPMv1.2 draft an example of such.
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 standardtpmkey:
URI format instead of a filename and Just Work™
The RFC isn't good enough. It says tpmkey:
What we have in TPM2 are hex NV key addresses begining with 0x81 MSO.
We could probably all agree on tpmkey:81
... 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
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.
FWIW my 2 cents:
I agree that object: is weird.
Proposal:
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".
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?
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 befile:
?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 havetpm
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