Original text:
sources.  For local time sources, this primarily means that the clock must be monotonically increasing, including across power cycles, firmware updates, etc.  For remote time sources, the provided time <del> must be guaranteed to be correct to within some predetermined bounds, whenever the time source is accessible. </del>  The term Envelope is used to describe an encoding that allows the bundling of a manifest with related information elements that are not This element is OPTIONAL. <del> Implements: </del>  4. able to sign manifests, even if the keys for manifest signing are held in an HSM that is accessed by the server. <del> Mitigated by: </del>  4.2.17. for a device.  The last valid firmware should not have an expiration time.  Mitigates: Implemented by: 4.3.18.  Manifests SHOULD be verified prior to deployment.  This reduces problems that may arise with devices installing firmware images that damage devices unintentionally. Mitigates: <del> 4.3.19. </del>  For high risk deployments, such as large numbers of devices or critical function devices, manifests SHOULD be constructed in an Mitigates: <del> 4.3.20. </del>  Both the manifest and any data extracted from it MUST be held immutable between its authenticity verification (time of check) and

Reviewer comments:
Clarified several points: Remote secure clocks require authentication. This was assumed when using the "correctness guarantees" however that was not sufficiently clear. Risks associated with using a flawed clock for manifest expiry. Secure clock can be used for key expiry. Risk of flawed clock for key expiry is identical to not having key rotation.
Ben Kaduk wrote:
We might also discuss the risks when a device believes that it possesses a source of secure time but the timesource is actually flawed.

Revised text:
sources.  For local time sources, this primarily means that the clock must be monotonically increasing, including across power cycles, firmware updates, etc.  For remote time sources, the provided time  <ins> must be both authenticated and guaranteed to be correct to within some predetermined bounds, whenever the time source is accessible. </ins> The term Envelope is used to describe an encoding that allows the bundling of a manifest with related information elements that are not This element is OPTIONAL.  <ins> Implements: req-use-delegation, </ins> 4. able to sign manifests, even if the keys for manifest signing are held in an HSM that is accessed by the server.  <ins> Mitigated by: req-sec-key-protection, </ins> 4.2.17. for a device.  The last valid firmware should not have an expiration time. <ins> If a device has a flawed time source (either local or remote), an old update can be deployed as new. </ins> Mitigates: Implemented by: 4.3.18. <ins> Cryptographic keys for signing/authenticating manifests SHOULD be replaced from time to time.  Because it is difficult and risky to replace a Trust Anchor, keys used for signing updates SHOULD be delegates of that Trust Anchor. If key expiration is performed based on time, then a secure clock is needed.  If the time source used by a recipient to check for expiration is flawed, an old signing key can be used as current, which compounds threat-key-exposure. Mitigates: 4.3.19. </ins> Manifests SHOULD be verified prior to deployment.  This reduces problems that may arise with devices installing firmware images that damage devices unintentionally. Mitigates:  <ins> 4.3.20. </ins> For high risk deployments, such as large numbers of devices or critical function devices, manifests SHOULD be constructed in an Mitigates:  <ins> 4.3.21. </ins> Both the manifest and any data extracted from it MUST be held immutable between its authenticity verification (time of check) and