Add `CompositeEvidence`, `RuntimeData`, `TeeEvidence`

[tylerfanelli]

I'm currently integrating Trustee client support for the SVSM attestation proxy. Trustee has added a number of types that are expected to be serialized by the client, like CompositeEvidence, RuntimeData, and TeeEvidence.

With another consumer (i.e. NOT trustee/guest-components) of the KBS protocol in Trustee, it's absolutely crucial that all types and {de}serialization within the KBS protocol (and the KBS protocol itself) is stable. This crate should be used to accommodate that.

cc/ @fitzthum @Xynnn007 @mythi

[Xynnn007]

Agreed. Some details

Now CompositeEvidence is somehow a kbs-protocol conception. But TeeEvidence is alias name for serde_json::Value, so whether to re-export it deserves consideration. RuntimeData, I only found it in AS's API, I think it is not what you mean. What you mean might also be a serde_json::Value here.

[tylerfanelli]

Now CompositeEvidence is somehow a kbs-protocol conception.

Right, but Trustee's KBS attestation is expected to deserialize its tee-evidence field in that format irrespective of the backend AS being used, so it's essentially a part of the KBS protocol as far as Trustee is concerned.

But TeeEvidence is alias name for serde_json::Value, so whether to re-export it deserves consideration.

It's a part of CompositveEvidence, so it's also now essentially built into the protocol and should be deserializable from this crate IMO.

RuntimeData, I only found it in AS's API, I think it is not what you mean. What you mean might also be a serde_json::Value here.

Likewise with CompositeEvidence, RuntimeData is deserialized by Trustee irrespective of the backend AS being used. So its now basically a part of the protocol as far as trustee is concerned.

Side note: Trustee is the KBS server we're building around, so it makes sense to just move this crate to Trustee and use it to define the client/server protocol interface now. Do you agree? If somone invites me to the coco org I can move the crate.

[tylerfanelli]

Sorry, inadvertently closed the issue.

[Xynnn007]

Side note: Trustee is the KBS server we're building around, so it makes sense to just move this crate to Trustee and use it to define the client/server protocol interface now. Do you agree? If somone invites me to the coco org I can move the crate.

From my personal view, moving crates to trustee would make it much easier for maintainance for CoCo (Symmetrically, which is less easier for virtee because of the link relationship between crates). More important, I believe that you must be welcomed to join CoCo!

[tylerfanelli]

Side note: Trustee is the KBS server we're building around, so it makes sense to just move this crate to Trustee and use it to define the client/server protocol interface now. Do you agree? If somone invites me to the coco org I can move the crate.

From my personal view, moving crates to trustee would make it much easier for maintainance for CoCo (Symmetrically, which is less easier for virtee because of the link relationship between crates).

Completely agree, and since we're coalescing around Trustee's KBS, it makes the most sense.

More important, I believe that you must be welcomed to join CoCo!

Great! If this crate is in trustee, I think I need to be a part of the CoCo github org to be a maintainer/reviewer. Can you invite me to the org? We can then make this transfer.

[Xynnn007]

Great! If this crate is in trustee, I think I need to be a part of the CoCo github org to be a maintainer/reviewer. Can you invite me to the org? We can then make this transfer.

I do not have the permission, but I think @fitzthum would offer help : )

[mythi]

With another consumer (i.e. NOT trustee/guest-components) of the KBS protocol in Trustee

would you see any benefit of having kbs_protocol client code being available differently?

[fitzthum]

@tylerfanelli are you suggesting moving the repo itself into the coco org or moving the code of this crate into the Trustee repo?

[tylerfanelli]

With another consumer (i.e. NOT trustee/guest-components) of the KBS protocol in Trustee

would you see any benefit of having kbs_protocol client code being available differently?

I don't think so. I'm using a separate attestation service (not coco-as) so I just need a stable KBS+AS layer. I can modify the actual attestation evidence as necessary.

[tylerfanelli]

@tylerfanelli are you suggesting moving the repo itself into the coco org or moving the code of this crate into the Trustee repo?

Whichever you prefer. It'd likely make the most sense to just move the crate into the Trustee repo. I'm looking for all KBS protocol changes (and adjacent types like CompositeEvidence, etc) to have to go through this crate, since SVSM will now be a consumer/client of the Trustee KBS and we must now be aware of any changes.

[mythi]

It'd likely make the most sense to just move the crate into the Trustee repo.

it needs some thinking first to avoid circular dependencies between repositories.

[fitzthum]

it needs some thinking first to avoid circular dependencies between repositories.

Yeah good point. If we move this to a crate in the Trustee repo, bumping guest-components could be a bit tricky. We would need to change the types first, which would impact the Trustee repo immediately. This would be sort of nice because we wouldn't need an extra PR to Trustee, but it would likely make the Trustee tests fail because they reference a version of guest-components which hasn't picked up the types changes yet. UNLESSSS the KBS protocol were backwards compatible. Even so, I have a feeling that any benefits we get from being able to update Trustee more easily would be balanced out by having to do some extra stuff for the guest components.

So maybe a new repo is the way to go.

One more thing to consider is that if we really want to break down the circular dependencies between gc and Trustee, we might want to move the entire kbs-protocol crate out of gc and into a separate repo. We could potentially consolidate the types, the protocol spec (currently in the Trustee repo), and the implementation of the protocol itself. Moving the kbs-protocol outside of gc would take some thinking (for instance it depends on the attesters so maybe those would have to move too?), but could be a good idea in the long term.