lib: Serialize TeePubKey to EAR map

[tylerfanelli]

Often, TeePubKeys are serialized to JSON format. The rust ear library provides equivalent types for representing data, including an EAR map. Allow for serialization of a TeePubKey to an EAR map and ensure that this map can be deserialized as a JSON object in return.

@Xynnn007 this fixes the producer problem mentioned here.

[Xynnn007]

The code look good to me. As it brings in a new dep, could you give a/some examples for how it is used?

[tylerfanelli]

Essentially, it's useful for when a user wants to serialize a TEE pubkey within an EAR token. With this, they can do the following:

let tee_pubkey = TeePubKey::RSA {
    alg: "test".to_string(),
    k_mod: "test".to_string(),
    k_exp: "test".to_string(),
};

let mut extensions = Extensions::new();                                                                                                                                                                                                         

extensions                                                             
    .register("tee-pubkey", 4, RawValueKind::Map)                                                                                                      
    .context("unable to register token TEE public key")?;                                                                                              

extensions                                                             
    .set_by_name("tee-pubkey", tee_pubkey.into())                                                                                                      
    .context("unable to set token TEE public key")?;                                                                                                   

let token = Ear {                                                      
    profile: "tag:github.com,2023:veraison/ear".to_string(),                                                                                           
    iat: OffsetDateTime::now_utc().unix_timestamp(),                                                                                                   
    vid: VerifierID {                                                  
        build: "test".to_string(),                                                                                                         
        developer: "test".to_string(),                                                                                                 
    },                                                                 
    raw_evidence: None,                                                                
    nonce: None,                                                       
    submods: BTreeMap::from([("test".to_string(), Appraisal::new())]),                                                                                 
    extensions,                                                        
};                                                                     

And when a consumer receives the token, they can deserialize the EAR map's tee-pubkey extension (containing the TeePubKey serialization) back to a JSON object for encrypting secrets. This includes Trustee's secret backend, which deserializes the TEE pubkey from JSON.

[Xynnn007]

@tylerfanelli Thanks for the example! I think it makes sense.

btw we are now embedding keys into submods than extension in AS. This pr provides a new design and we can think of it. cc @fitzthum

[tylerfanelli]

@Xynnn007 Sorry, realized I had to hide the dependency behind the std feature as it currently doesn't support alloc. Can you re-review?

[fitzthum]

LGTM

EAR has a Key Attestation extension in the appraisal, but it is for veraison (and will be serialized with veraison in the key). I'm not against adding something like this for CoCo to more easily identify the Tee Pubkey. That said the current approach does nicely capture the idea that the Tee Pubkey depends on the report data.

Either way this PR looks fine

[tylerfanelli]

EAR has a Key Attestation extension in the appraisal, but it is for veraison (and will be serialized with veraison in the key). I'm not against adding something like this for CoCo to more easily identify the Tee Pubkey. That said the current approach does nicely capture the idea that the Tee Pubkey depends on the report data.

I'm not sure if I'm in total agreement that the TEE pubkey needs to depend on report data. Report data is already (usually) included in the token's claims. The TEE pubkey is just something to encrypt secrets with to whoever presents the token. IMO there isn't much value in coupling them further.