All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fuchs, Andreas <andreas.fuchs at sit.fraunhofer.de>
To: tpm2@lists.01.org
Subject: Re: [tpm2] Conflicting TPM2 engines and storage formats
Date: Thu, 11 Oct 2018 15:41:08 +0000	[thread overview]
Message-ID: <9F48E1A823B03B4790B7E6E69430724D014734482C@exch2010c.sit.fraunhofer.de> (raw)
In-Reply-To: 7c3d5a4ac2f51f301164ba2ddefff643d5a8ce1b.camel@infradead.org

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

Hi David,

thanks for the summary. I agree with all of them. Some more things to agree on:

Primarykeys.publicArea:
-  .type = TPM2_ALG_ECC, .nameAlg = TPM2_ALG_SHA256
- .objectAttributes = (TPMA_OBJECT_USERWITHAUTH | TPMA_OBJECT_RESTRICTED | TPMA_OBJECT_DECRYPT | TPMA_OBJECT_FIXEDTPM | TPMA_OBJECT_FIXEDPARENT | TPMA_OBJECT_SENSITIVEDATAORIGIN)

For the On-Disk-Format:
We need to keep a placeholder for the (optional) policy I think.
If we want to allow different formats in the future, we need to add some
idetifier for the format type in there as well.

Would you both agree ?

Regarding the engine naming:
Won't we run into a naming problem with the engine names if we name them similarly ?

P.S. The reason I did not call the engine "openssl-something-engine" is that this
is prohibited by the OpenSSL code license, unless openssl-core@ agrees, but
they never answered... ;-)

Cheers,
Andreas

________________________________________
From: David Woodhouse [dwmw2(a)infradead.org]
Sent: Monday, October 08, 2018 12:15
To: James Bottomley; Fuchs, Andreas; tpm2(a)lists.01.org; Nikos Mavrogiannopoulos
Subject: Re: [tpm2] Conflicting TPM2 engines and storage formats


It would be good to reach a conclusion on what the PEM format should
be, so that I can push this to the OpenConnect master branch in
preparation for a release.

Let me attempt to summarise some of the discussions and create a
definition / TODO list.

 • We all change to use all three of NODA/FIXEDTPM/FIXEDPARENT
   objectAttributes for creating the primary key.

 • PEM file tag changes to 'BEGIN TSS2 PRIVATE KEY'. James can continue
   to use the old objectAttributes when loading files with the old PEM
   tag for compatibility reasons, if he wants to.

 • Drop the TPMv1.2 compatibility via '12Key' and the 'importableKey'
   object types, which in fact means we can drop the 'type' field from
   the ASN.1 definition altogether.

 • Make the pubkey field non-optional.

 • Ignore policy for now; we can define that later. We won't use the
   [3] EXPLICIT tag for anything incompatible with James's existing
   definition, and if we settle on something else we'll use a different
   explicit tag.

 • We produce a draft specifying the ASN.1 format and tpmkey: URI
   scheme.


That's probably enough for me to do a release of the GnuTLS code. On
the OpenSSL side I also recommend that:

 • Both engines should use the same engine name so that applications
   which match the PEM tag and load an engine don't have to try both.

 • Both engines should register the ASN.1 parser so that keys can be
   used transparently by applications without having to explicitly
   reference the engine at all (see
   https://github.com/openssl/openssl/issues/7354 )



             reply	other threads:[~2018-10-11 15:41 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-11 15:41 Fuchs, Andreas [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-10-12 15:54 [tpm2] Conflicting TPM2 engines and storage formats Fuchs, Andreas
2018-10-12 15:19 David Woodhouse
2018-10-12  9:16 Fuchs, Andreas
2018-10-12  6:08 David Woodhouse
2018-10-12  5:55 David Woodhouse
2018-10-11 22:25 David Woodhouse
2018-10-11 20:15 David Woodhouse
2018-10-11 18:48 David Woodhouse
2018-10-11 18:40 David Woodhouse
2018-10-11 18:31 David Woodhouse
2018-10-11 18:07 David Woodhouse
2018-10-11 17:34 David Woodhouse
2018-10-08 10:15 David Woodhouse
2018-10-05 15:46 David Woodhouse
2018-10-05 15:34 Fuchs, Andreas
2018-10-05 15:31 David Woodhouse
2018-10-05 15:24 Fuchs, Andreas
2018-10-05 15:22 Fuchs, Andreas
2018-10-05 14:59 David Woodhouse
2018-10-05 14:36 Fuchs, Andreas
2018-10-05 11:59 David Woodhouse
2018-10-05 10:27 David Woodhouse
2018-10-05 10:19 Fuchs, Andreas
2018-10-05  9:44 Fuchs, Andreas
2018-10-04 16:17 David Woodhouse
2018-10-04 16:04 Fuchs, Andreas
2018-10-04 10:58 Roberts, William C
2018-10-03 20:47 David Woodhouse
2018-10-03 11:06 David Woodhouse
2018-10-03 10:47 David Woodhouse
2018-10-03 10:35 David Woodhouse
2018-10-02 18:58 David Woodhouse
2018-10-02 17:21 Fuchs, Andreas
2018-10-02 17:18 Fuchs, Andreas
2018-10-02 16:38 David Woodhouse
2018-10-02 16:20 Fuchs, Andreas
2018-10-01 20:10 David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9F48E1A823B03B4790B7E6E69430724D014734482C@exch2010c.sit.fraunhofer.de \
    --to=tpm2@lists.01.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.