fido-alliance / fdo-sim Goto Github PK

Commmands run to termination synchronously with the ServiceInfo processing. I.e., no new ServiceInfo input is processed between the time that command:execute is processed and when that command finishes with command:exitcode. The message command:sig applies to the currently executing command.

This paragraph looks contradicting to me, on the one hand the Device should stop processing ServiceInfo inputs once command:execute has been received until command:exitcode, but we also allow a command:sig to be processed.

Create naming conventions for FSIMs including versioning.

Does every implementation of FDO.CSR have to implement every option?
Suggest subsetting for simpler devices and implementations.

Are all the features of the fdo.download fsim mandatory to implement?

IMHO it would be important to mandate the order of the message exchange since otherwise you might get unexpected behavior. I think a state machine would be appropriate here.
For example, is it allowed to do a sequence of

[fdo.download.active, True]
[fdo.download.name, "foo1"]
[fdo.download.length, 700]
[fdo.download.data, (bstr)590200...]
[fdo.download.done, 700]
[fdo.download.name, "foo2"]
[fdo.download.length, 200]
[fdo.download.data, (bstr)590200...]
[fdo.download.done, 200]

Why does the device needs to confirm that the module is available after the file transfer has been completed.

This example is incorrect:
"
[fdo.download.data, 188]
"

It should say
"
[fdo.download.data, (bstr)1345...]
"
with the remark in the description that those are the last 188 bytes.

Is it possible to put these three messages into a single packet for delivery?

[fdo.download.active, True]
[fdo.download.name, "foo1"]
[fdo.download.length, 700]

Is there an exchange to learn about the FSIMs supported by the other party?

Wouldn't it be useful to add a message that sets the file path? This would help with storing files in a relative filepath.

There are no error messages defined in this fsim. What happens, for example, if a message "[fdo.download.name, '/etc/passwd']" leads to an access denied. Or, what happens if the device receiving "[fdo.download.length, 700]" wants to indicate that it does not have enough storage space left?

What happens if the command processor (sh, ...) is not available on a given device? What error would be returned?
When wrong arguments are used, then an error response is available.

Is it possible to submit an entire script to the device or is it necessary to issue command-by-command?

WGET can use HTTPS:, this implies there is a way to edit/update trust anchors on the device
CSR can add trust anchors, but not remove or edit them.

The spec states:
https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-PS-v1.1-20220419/FIDO-Device-Onboard-PS-v1.1-20220419.html#ServiceInfo

The ServiceInfo key is the module name and the message name, separated by a colon.
…
ServiceInfo uses key-value pairs. A ServiceInfo key is a module name and a message name:
moduleName:messageName

In the following fsim all the messages are defined with just “.” and no “:” (except for fdo.command which correctly uses a “:”)

fdo-sim/fsim-repository/fdo.command.md (correct)

• ['fdo.command:active', True] Module is active
• ['fdo.command:command', 'sh'] Indicates shell to use
• ['fdo.command:return_stdout, True] send stdout in reverse message
• ['fdo.command:return_stderr, False] do not send stderr (swallow it)
• ['fdo.command:may_fail', True] failure of command does not cause TO2 to fail
• ['fdo.command:args', bstr .cbor *1] request (short) list of file systems. Invokes command.
• ['fdo.commmand:execute, bstr .cbor Null] Invoke command
  ['fdo.command:stdout', *2] - stdout from invoked command 1
  ['fdo.command:stdout', *3] - more stdout from invoked command 1
  ['fdo.command:exitcode', 0] -

All other fsims don’t use the : convention but instead just contain “dots”. I think this is because we said the module would match Java namespace conventions. However, we now don’t have a way to parse the modulename from the message being received.

fdo-sim/fsim-repository/fdo.csr.md (no “:” but “.” instead)

Direction Key Name Value Meaning
o <-> d fdo.csr.active bool Instructs the device to activate or deactivate the module
o <-- d fdo.csr.cacerts-req uint Request to obtain CA certificates
o --> d fdo.csr.cacerts-res tstr CA certificates
o <-- d fdo.csr.simpleenroll-req tstr Certificate enrollment request
o --> d fdo.csr.simpleenroll-res tstr Enrollments of clients
o <-- d fdo.csr.simplereenroll-req tstr Request to re-enroll a client
o --> d fdo.csr.simplereenroll-res tstr Re-enrollment response
o <-- d fdo.csr.serverkeygen-req tstr Request for server-side key generation
o --> d fdo.csr.serverkeygen-res tstr Certificate and private key
o <-- d fdo.csr.csrattrs-req uint Request for CSR attributes
o --> d fdo.csr.csrattrs-res tstr CSR attributes
o --> d fdo.csr.error uint Error Indication

Ensure consistency in document

Define the process for submissions from internal and external parties. Including legal agreement(s), review, and approval.

Is there an expectation to use TLS with wget (HTTPS rather than HTTP)? If so, where would the trust anchors come from or what trust anchors would be used to verify the server certificate? Would there be client authentication, and if so, would it be necessary to specify something in the fsim modules?