dhmsgs_proto_defs/ProtobufLAMessages.proto

// Design decision - could define structures within a structure as messages *within* a message and then refer to the nested msg in another msg as Msg1.nested_msg
// Or could define the nested message separately and use it within the message 1 as a type.
// *Think* that the first option effectively "exposes" the nested msg as a valid msg that can be set/get by the application. Want to "hide" this.
// The second method is easy to automatically generate from the C code and so am using it for now. TODO: Define a CPP class that hides the undesired getters/setters, as per the best practice at https://developers.google.com/protocol-buffers/docs/cpptutorial under "Protocol Buffers and O-O Design"
// TODO: Hide setters/getters for these fields in the generated .h file..?

// uint8_t, uint16_t for Protobuf - uint32, as per here - https://stackoverflow.com/questions/42295695/small-scalar-types-and-google-protocol-buffers
// TODO: Do I need to ensure that the value here is within the defined here? Seems not, as it comes from a trusted source.

// "Repeated" - can be repeated 0 or more times - however, arrays in C or CPP with fixed size that have all their elements defined - are a stricter version of this. (Protobuf doesn't let you define constant-sized arrays.)
// packed=true is necessary to ensure successive, efficient 'packing'

syntax = "proto3";
// LITE_RUNTIME supports serializetocodedstream - which is helpful to read/write multiple messages - https://groups.google.com/forum/#!topic/protobuf/MlUMUPp5WDc and https://developers.google.com/protocol-buffers/docs/techniques?csw=1#streaming

// Only have base classes for those structs in the composite structs that have more than 1 element - this causes a significant reduction in the size of the generated .cc and .h files.

message  protobuf_sgx_attributes_t {
  uint64 flags = 1;
  uint64 xfrm = 2;
}

message protobuf_sgx_ec256_public_t {
  repeated uint32 gx = 1 ;
  repeated uint32 gy = 2 ;
}

// Composite message types
// Tag numbers - first all the repeated ones (arrays) and then the  ones, as per the docs.
message protobuf_sgx_report_body_t {
  repeated uint32 cpu_svn = 1 ;
   uint32 misc_select = 9;
  repeated uint32 reserved1 = 2 ;
   protobuf_sgx_attributes_t attributes = 10;
  repeated uint32 mr_enclave = 3 ;
  repeated uint32 reserved2 = 4 ;
  repeated uint32 mr_signer = 5 ;
  repeated uint32 reserved3 = 6 ;
   uint32 isv_prod_id = 11;
   uint32 isv_svn = 12;
  repeated uint32 reserved4 = 7 ;
  repeated uint32 report_data = 8 ;
}

message protobuf_sgx_report_t {
   protobuf_sgx_report_body_t body = 1;
  repeated uint32 key_id = 2 ;
  repeated uint32 mac = 3 ;
}

message protobuf_sgx_target_info_t {
  repeated uint32 mr_enclave = 1 ;
   protobuf_sgx_attributes_t attributes = 4;
  repeated uint32 reserved1 = 2 ;
   uint32 misc_select = 5;
  repeated uint32 reserved2 = 3 ;
}

message protobuf_sgx_dh_msg1_t {
   protobuf_sgx_ec256_public_t g_a = 1;
   protobuf_sgx_target_info_t target = 2;
}

message protobuf_sgx_dh_msg2_t {
   protobuf_sgx_ec256_public_t  g_b = 1;
   protobuf_sgx_report_t        report = 2;
  repeated uint32 cmac = 3 ;
}

message protobuf_sgx_dh_msg3_body_t {
   protobuf_sgx_report_t report = 1;
  repeated uint32 additional_prop = 2;
}

message protobuf_sgx_dh_msg3_t {
   protobuf_sgx_dh_msg3_body_t msg3_body = 1;
  repeated uint32 cmac = 2 ;
}

// for post-LA key establishment and other msgs (in particular, between Apache and Decryptor)
message protobuf_post_LA_encrypted_msg_t {
   bytes msg = 1 ; 	
}