Update V3-Software_Platform_Requirements.md

[kanetil]

Some small changes in the text (authentication vs encryption etc.). some more points to think about:

1. The document should be focused on IoT which is Single-use/single-device, and maybe add that in the preamble. Automotive (which is IoT) needs a lot more than this scope
2. 3.1.5 depends on 4.2.4, structure-wise maybe it's best to reference, but that's a format decision
3. my change to 3.1.5 is to explicitly highlight before each execution step. A common mistake in IoT we’ve seen. TOCTOU is a real threat in bootloaders
4. 5.2.2 nothing about using latest versions / stable releases and on-going patches. I believe it's important to verify
5. 3.2.2 I have a problem with the wording for the misuse case of adding an interface (e.g. adding a Ethernet USB dongle mounted by the OS). will think about it a bit more
6. 3.4.3 maybe add reference to existing frameworks? will make the verification much simpler

[kanetil]

The document should be focused on IoT which is Single-use/single-device, and maybe add that in the preamble. Automotive (which is IoT) needs a lot more than this scope. -> We would be very interested in some more feedback on how we can make the ISVS more representative to the automotive use-case. Is this something you can elaborate on? ----> The main difference is that automotive is a "System of Systems", including internal networks, cross-component dependencies, isolated environments and components - all working under one physical boundary in a safety-critical environment with complex supply chain structure and highly regulated ecosystem. those constraints don't appear in most single-use devices and as an example this document does not touch "internal network segmentation", "single component replacement", "proxied communications" and similar issues. I really think it's too big to include here but will be happy to have a deeper discussion.

3.2.2 I have a problem with the wording for the misuse case of adding an interface (e.g. adding a Ethernet USB dongle mounted by the OS). will think about it a bit more -> Care to elaborate? ---> If I physically connect an Ethernet USB dongle to most linux based systems, it will add a new interface automatically. if the system is not configured correctly, this interface will not be protected, especially if ETH interface was not expected on the system to begin with - and it will be exposed after that connection. so this requirement will not cover this misuse case as there is no "current" network service exposed (before I connect the dongle). maybe rephrase to "Verify that all network services possible or exposed...". hope it's clearer now.

will review the reference numbers in a separate comment

[kanetil]

Reference numbers could not be verified, odd. I saw that most of the things I referenced are handled already, so that's ok anyway.

with regards to 3.4.3 example frameworks - TUF is probably one worth referencing (UPTANE if we were automotive specific), but outside of automotive is not my domain for that.

[cbassem]

Thank you for following up on the above comments. As this PR is getting rather big I propose to split it up into a PR and separate issues which will make it easier to manage.

The below changes can be merged directly. As such, I propose to either change this PR or to create a new PR for the below changes.

• The change to 3.1.5: explicitly highlight before each execution step.
• The change to 3.1.4: "... e.g. Secure/trusted boot with a hardware root of trust"

I feel that the following topics require a separate discussion which is better suited for a GitHub issue.

• Issue to discuss the differences with the automotive use-case. I.e. single use vs "system of systems" and The concern with 3.1.7 and 3.2.5 can be addressed here.
• Issue concerning 3.4.3. TUF is a good reference, I believe it's worth cross checking the requirements in TUF with the ones we already have in the ISVS. UPTANE is perhaps too sector / use-case specific for the ISVS at this point. In any case, worth cross-checking as well.
• Issue for 3.2.2 we will need to put some more thought into this one.

I believe this covers all of the feedback. Do you want to create the PR/issues for these or do you want me to go head and pick this up?