Re: [PATCH v12 11/20] key_protector: Add TPM2 Key Protector

[James Bottomley]

On Fri, 2024-04-19 at 16:30 +0800, Gary Lin wrote:
>    TPMKey ::= SEQUENCE {
>      type        OBJECT IDENTIFIER
>      emptyAuth   [0] EXPLICIT BOOLEAN OPTIONAL
>      policy      [1] EXPLICIT SEQUENCE OF TPMPolicy OPTIONAL
>      secret      [2] EXPLICIT OCTET STRING OPTIONAL
>      authPolicy  [3] EXPLICIT SEQUENCE OF TPMAuthPolicy OPTIONAL

Now that you've got rsaParent [5] EXPLICIT BOOLEAN OPTIONAL, could you
use it?

Since none of this ever went upstream do the arguments really need the
old keyfile format?  No-one should have created one, so using the
tpm2key format going forwards and eliminating the additional policy
arguments should simplify the user facing piece.  Even if SUSE has
released something with the old format, since the new key file has a
more expressive policy it should be easy to convert to it to the
tpm2key format.

The other thing is this:

> +      .longarg  = "asymmetric",
> +      .shortarg = 'a',
> +      .flags    = 0,
> +      .arg      = NULL,
> +      .type     = ARG_TYPE_STRING,
> +      .doc      =
> +     N_("In SRK mode, the type of SRK: RSA (RSA2048), RSA3072, "
> +        "RSA4096, ECC (ECC_NIST_P256), ECC_NIST_P384, "
> +        "ECC_NIST_P521, and ECC_SM2_P256. (default: ECC)"),

The TCG has only defined two types of SRK templates for
interoperability: P-256 and RSA2048 (both with 128 bit AES symmetric
keys):

https://trustedcomputinggroup.org/resource/http-trustedcomputinggroup-org-wp-content-uploads-tcg-ek-credential-profile-v-2-5-r2_published-pdf/

The others are all non-standard and shouldn't be included (they'll just
cause interoperability issues for people who insist on trying out every
option and then complain about the problems this causes).

James