On Thu, 2021-04-01 at 18:50 +0530, Sumit Garg wrote: > 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? I'm not quite sure what you're asking. The saved format of the keys is particular to the underlying hardware. The ASN.1 wraps this so we have an identifier, some useful information to help load the key (like the policy systemements) and then the blobs the hardware expects. This makes the ASN.1 specific to the backend but having a distinguishing OID that allows anyone to tell which backend it needs from the file. So you can call the ASN.1 format that begins with the type OID, the "universal" format, but if you mean there should be a standard ASN.1 format for all keys that defines all the fields then that's not possible because the fields after type are very specific to the underlying hardware. James
