Refactor protobuf messages #198
Conversation
| authentication = 0; | ||
| attestation = 1; | ||
| }; | ||
|
|
||
| message trust_request_message { | ||
| optional string requesting_enclave_tag = 1; |
There was a problem hiding this comment.
why do we need this and the next one?
There was a problem hiding this comment.
I would not refactor it this way right now. The evidence packages can change, for example, there could be a cert chain for some of the platforms. Also, there not be one evidence package format even for a single platform. (i.e.- someone could specify rules in an alternative format even for the same platform).
I like the idea but could we talk before doing this?
Are these changes needed for some functional reason or just to beautify?
|
This refactoring will enable adding support for NVIDIA H100. The current way of sending evidence to the Certifier Service is very error-prone and I don't see why we should keep doing it like that:
My proposal is to fix this before adding more technical debt by following the current pattern for new platforms like NVIDIA. |
Introduce new protobuf messages which encapsulate various evidence packages which are being sent to the Certifier Service. Using separate message types for each platform is less error-prone and allows extensibility.
rgerganov
force-pushed
the
protobuf-refactor
branch
from
b44fc0f to
3a211ae
Compare
Introduce new protobuf messages which encapsulate various evidence packages which are being sent to the Certifier Service. Using separate message types for each platform is less error-prone and allows extensibility.