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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel