Create an RFC to make capabilities negotiation extensible #21
Conversation
Signed-off-by: Miguel Young de la Sota <[email protected]>
|
|
||
| This proposal replaces "Device Capabilities" with an extensible negotiation | ||
| flow that allow arbitrary new capabilities to be exchanged, while respecting the | ||
| maximum 64-byte size of required messages. |
There was a problem hiding this comment.
I think I know what you mean here, but I just want to be sure it's clear that there not a maximum size of 64 bytes for required messages. Certain messages, like Get Certificate, will likely return messages larger than 64 bytes. The 64 byte value is the minimum required message size a device must support. Negotiate, but not other commands, need to fit within this 64 byte constraint since you can negotiate a larger message size with the device.
| } | ||
| ``` | ||
|
|
||
| The `reserved` byte must always be set to zero, and servers must reject |
There was a problem hiding this comment.
In the current spec, we generally refer to things as 'devices' rather than 'servers'. It comes mostly from the idea that RoTs are components within a server chassis or motherboard that communicate with each other.
There was a problem hiding this comment.
Oops. Yeah, I have a habit of using "client" and "server" here. Host and device makes more sense.
| - As a six-bit integer, encoded as a byte with the top two bits forming the | ||
| value `0b00`. | ||
| - As a fourteen-bit integer, encoded as two bytes, where the value is formed | ||
| as `contents[0] | (contents[1] << 6)`. The top two bits form the value |
There was a problem hiding this comment.
Wouldn't left-shifting contents[1] make the MSB of the second byte non-deterministic?
There was a problem hiding this comment.
The shift is taking place in 14-bit space (since it's a 14 bit integer). I've clarified this in the text.
| - "Mode", `0x00`. Six bit record. Required. | ||
| - Bits [1:0] are the device type. They are interpreted as in the Device | ||
| Capabilities message (AC-RoT, PA-RoT, etc.). | ||
| - Bits [3:2] are the bus role (i.e., can it act as a "client" or "server" on |
There was a problem hiding this comment.
It seems you are generally trying to move to client/server nomenclature. Maybe we should discuss and align on appropriate terminology. My only concern here is the overloading of the term 'server', since the main use-case for Cerberus is in server platforms.
There was a problem hiding this comment.
Let's stick to host/device; I have a habit of switching to client/server when chatting with folks who work on TLS, but that shouldn't leak into the spec.
I will note that I've intentionally avoided the master/slave nomenclature here.
| # Future Work | ||
|
|
||
| The encoding described a above leaves us with significant leeway to add even | ||
| more capabilities contents. The flags byte, for example, can be used to |
There was a problem hiding this comment.
Which is the flags byte? Does this refer to 'reserved'?
There was a problem hiding this comment.
Yup. Name changed while I was editing, oops.
|
|
||
| The encoding described a above leaves us with significant leeway to add even | ||
| more capabilities contents. The flags byte, for example, can be used to | ||
| indicate a continuation byte, if all the capabilities don't fit in one byte. |
There was a problem hiding this comment.
Do you mean one message? If we think could be a possibility, which it certainly could be from the way this is defined, we should probably think through this more carefully and put something in explicitly to cover that case from the beginning.
There was a problem hiding this comment.
Yeah, message, not byte. Oops.
One thing I've been thinking about is how much of this complexity is necessary if we believe in a version-varying format for this. I'm already burning a reserved byte there for future-compat, so perhaps it's not a big deal... let's discuss this tomorrow.
There are a few opens, namely: