uptane.github.io
uptane.github.io copied to clipboard
Handling failure to verify latest time
To my reading, sections 3.1.1.1 and 3.1.1.3 seem to offer diverging advice as to how a primary ECU should handle a failure to verify the latest time from an external time source. In 3.1.1.1, it says “If it [primary ECU] fails to meet this [verification] criteria, discard the response and continue the procedure without an updated time”. However, 3.1.1.3 says “If any check fails, the ECU SHOULD NOT overwrite its current attested time, but SHOULD jump to the last step …”.
To make things consistent, any of the following changes could be made:
- Section 3.1.1.1 could instruct the Primary ECU should jump to the last step to report the error, to match with what 3.1.1.3 says already
- Section 3.1.1.3 could instruct ECUs to continue without an updated time, to match with what 3.1.1.1 says already
- Section 3.1.1.3 could instruct only secondary ECUs to jump to the last step, to avoid conflicting with section 3.1.1.1
- Both sections (3.1.1.1 and 3.1.1.3) could allow both options
- Anything else that is consistent between the two sections
Any thoughts?
Thanks for the question!
Based on discussion in the Uptane Standards meeting, as the time source is not specified by Uptane, we will leave the choice of what counts as a "fatal" error" of the time source up to the implementation. This can be based on knowledge about the time source (such as reliability, whether there is a backup source of time, etc). We will update this in the text to clarify that if such a fatal error occurs, the update should not continue.
New text ideas:
- "If all steps are completed without fatal error..."
- "If the time checking process fails fatally..."
Hi, thanks for the response! I agree that a change in this direction would help disambiguate things. Regarding textual updates, is there anything you need from my end, i.e. drafts of changes? If so, just let me know, otherwise I'm happy to let you guys take it from here 😀
If you are able to draft some text or open a pull request, that'll help this move faster. Thanks!
I'm transferring this here, as we will archive the separate deployment-considerations repo soon.