On Thu, 1 Apr 2021 at 15:36, Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote: > > Hello Richard, > > On 31.03.21 21:36, Richard Weinberger wrote: > > James, > > > > ----- Ursprüngliche Mail ----- > >> Von: "James Bottomley" <jejb@xxxxxxxxxxxxx> > >> Well, yes. For the TPM, there's a defined ASN.1 format for the keys: > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/tree/tpm2-asn.h > >> > >> and part of the design of the file is that it's distinguishable either > >> in DER or PEM (by the guards) format so any crypto application can know > >> it's dealing with a TPM key simply by inspecting the file. I think you > >> need the same thing for CAAM and any other format. > >> > >> We're encouraging new ASN.1 formats to be of the form > >> > >> SEQUENCE { > >> type OBJECT IDENTIFIER > >> ... key specific fields ... > >> } > >> > >> Where you choose a defined OID to represent the key and that means > >> every key even in DER form begins with a unique binary signature. > > > > I like this idea. > > Ahmad, what do you think? > > > > That way we could also get rid off the kernel parameter and all the fall back logic, > > given that we find a way to reliable detect TEE blobs too... > > Sounds good to me. Sumit, your thoughts on doing this for TEE as well? > AFAIU, ASN.1 formating should be independent of trusted keys backends which could be abstracted to trusted keys core layer so that every backend could be plugged in seamlessly. James, Would it be possible to achieve this? -Sumit > > > > Thanks, > > //richard > > > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
