Re: [tpm2] Conflicting TPM2 engines and storage formats

[Fuchs, Andreas <andreas.fuchs at sit.fraunhofer.de>]

[-- Attachment #1: Type: text/plain, Size: 4481 bytes --]

@James: Looking over this, I was wondering, why is the publicKey optional ?
I think the TPM won't load the private key without the public key, or will it ?

Thanks,
Andreas
________________________________
From: Fuchs, Andreas
Sent: Friday, October 05, 2018 12:19
To: Nikos Mavrogiannopoulos; David Woodhouse
Cc: James Bottomley; tpm2(a)lists.01.org
Subject: RE: [tpm2] Conflicting TPM2 engines and storage formats

That's a good point actually.

However, TSS2 FAPI will not use the "weird" UUIDs for keys anymore, but path-like strings.

See https://trustedcomputinggroup.org/wp-content/uploads/TSS-Feature-API-version-.12_Review.pdf
page 16 (examples) and all of section 4 for explanation.
Note that that was a very early version and has been revised since then, but the general concept still sticks.

Thus, the URI-Scheme will have to change anyways.

The biggest point for the URI-Scheme IMHO was that it allowed system vs user keys, which was otherwise not possible. The path-scheme of FAPI now already encodes this from TSS side.

My personal idea was:
- prefixes 0x81 (persistent) and 0x01 (NV-Space) will point to TPM-internal (as applicable one or the other)
- If not it looks for a FAPI keystore path
- If not it looks if a file of this name exists

We could of course prefix all of it, but question is, whether it's worth it ?

What do people think ?

Cheers,
Andreas

________________________________
From: Nikos Mavrogiannopoulos [n.mavrogiannopoulos(a)gmail.com]
Sent: Friday, October 05, 2018 11:54
To: David Woodhouse
Cc: Fuchs, Andreas; James Bottomley; tpm2(a)lists.01.org
Subject: Re: [tpm2] Conflicting TPM2 engines and storage formats

It would certainly be good to have a standard, unambiguous way to reference items in a TPM rather than just hex numbers. We were are that situation with HSMs 5 years ago, and the switch to pkcs11: URIs helped improve software interfaces greatly (in apache today you specify a file or a smart card object interchangeably). The tpmuri scheme that David pointed could be a good starting point.

regards,
Nikos

On Thu, Oct 4, 2018 at 6:17 PM David Woodhouse <dwmw2(a)infradead.org<mailto:dwmw2(a)infradead.org>> wrote:

FWIW I have the GnuTLS code also working, including with EC keys (and I
think I know how to tell GnuTLS not to ask me to do SHA512). I should
be able to adjust it to conform to whatever consensus we reach.

cf. https://tools.ietf.org/html/draft-mavrogiannopoulos-tpmuri-01


On Thu, 2018-10-04 at 16:04 +0000, Fuchs, Andreas wrote:
> Should we try to setup a wiki or markdown to start converging into a single form ?
> I think we can also easily set NODA for the primary, because they have to auth value anyways.
>
> @James: how do you handle the key-ids ? Allways assume them to be files ?
> I have a PR for persistent TPM keys, where all key ids starting with 0x are interpreted as TPM keys.
> For the future I'll also want to reference FAPI keys (path-like format).
> Thus, any clues on how to handle things consistently here ?
>
> tpm2-tss-engine will propably not support policies from your format then, but wait until FAPI (with integrated policy engine) is available.
> ________________________________________
> From: David Woodhouse [dwmw2(a)infradead.org<mailto:dwmw2(a)infradead.org>]
> Sent: Wednesday, October 03, 2018 22:47
> To: James Bottomley; Fuchs, Andreas; tpm2(a)lists.01.org<mailto:tpm2(a)lists.01.org>; Nikos Mavrogiannopoulos
> Subject: Re: [tpm2] Conflicting TPM2 engines and storage formats
>
> On Wed, 2018-10-03 at 11:35 +0100, David Woodhouse wrote:
> >
> >
> > Full patch below, for reference. Don't heckle too hard; it exists
> > mostly to document the current incompatibilities. I'll let the two of
> > you come to an agreement on the correct way to resolve them, while I
> > throw together some GnuTLS code to use the same PEM files.
>
> OK... OpenConnect now supports both OpenSSL engines, and I've thrown
> together some GnuTLS code cribbing from tpm2-tss-engine, implementing a
> gnutls_privkey_t with some caveats (RSA only, PKCS#1 padding only,
> no auth, no policy, only the default parent, ...).
>
> http://git.infradead.org/users/dwmw2/openconnect.git/blob/tpm2:/gnutls_tpm2_esys.c
> http://git.infradead.org/users/dwmw2/openconnect.git/blob/tpm2:/gnutls_tpm2.c
>
> I'd love *not* to have to fix all those caveats, and for this to live
> in a library somewhere instead. :)


[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 7039 bytes --]