Define context formats

[kathrynfejer]

In relation to discussion on #78:

In the client code of the handshake, we have initialize_{daa, certs, tcti}. Each of these must read in multiple pieces of information either from files(software DAA) or from the TPM's nvram. Could we create three different "contexts" or "certificates", so that we only need to read in 1 piece of data and then parse those? Those three being a group_context, a TLS root_cert and a xtt root_cert.

[zanebeckwith]

Regarding root certificates:

Yes, this should (now) be as simple as:

• Updating xtt_initialize_server_root_certificate_context_ecdsap256 to take just a xtt_root_certificate, rather than the root id and pub key separately
  • To maintain backward-compatibility, we can leave the old version, taking the two separate pieces, too
• Once that's done, we should remove the initialize_certs and lookup_certificate functions from client.c, and remove the global root ID and root cert. Instead, just read in the root cert and use it to initialize a root context (which lives in run_client, not as a global), and simply pass it directly to xtt_handshake_client_build_idclientattest without having to "look it up" (which we never actually were doing anyhow).

In the longer term, we can discuss if we want to transition our root cert format away from the current binary concatenation form, to just using a static x.509 (like we're doing with the client certs, except in this case parsing a cert, rather than building it).

[drbild]

In the longer term, we can discuss if we want to transition our root cert format away from the current binary concatenation form, to just using a static x.509 (like we're doing with the client certs, except in this case parsing a cert, rather than building it).

I think we should have a discussion about this soon (maybe later this week). We might not act on that immediately, but should at least decide on the file formats that we want.

[zanebeckwith]

Regarding the discussion on root cert formats, see the discussion in issue #67