Change:
Signed-off-by: Dave Thaler
At the IETF 110 meeting, Brendan Moran asked why local clocks are a problem since even MCUs have them. Currently we have text in the doc like... in the nonce section: in the handles section: I answered this by saying in the TEE use case for example, attesting the TEE needs a trusted clock, and having a trusted clock is not common. Brendan suggested clarifying the clock text.
Isn't it synchronized clocks that are the requirement? When you say "trusted clocks", do you mean, I can trust that they are securely synchronized? (Or that I can trust that Cesium still has that frequency, and that the laws of physics haven't been altered?)
I mean a clock for which code outside the TEE cannot tamper with. Whether it's synchronized or not is not about whether the clock itself is trusted. If a TEE wants to know how much time has passed since a previous event, and it has to ask the REE, and the REE can lie, then that clock is not trusted by the TEE.
Add text to TEE section about how it needs a local clock, and then add to the example involving nonces.

Discussion:
requires additional Claims about the signer's time synchronization mechanism. <ins> In some use cases, however, a trustworthy clock might not be available.  For example, in many Trusted Execution Environments (TEEs) today, a clock is only available outside the TEE and so cannot be trusted by the TEE. </ins> 10.2. A second approach places the onus of timekeeping solely on the Verifier (for Evidence) or the Relying Party (for Attestation Results), and might be suitable, for example, in case the Attester <del> does not have a reliable clock or time synchronization is otherwise impaired.  In this approach, a non-predictable nonce is sent by the appraising entity, and the nonce is then signed and included along with the Claims in the Evidence or Attestation Result.  After checking that the sent and received nonces are the same, the </del> <ins> does not have a trustworthy clock or time synchronization is otherwise impaired.  In this approach, a non-predictable nonce is sent by the appraising entity, and the nonce is then signed and included along with the Claims in the Evidence or Attestation Result. After checking that the sent and received nonces are the same, the </ins> appraising entity knows that the Claims were signed after the nonce was generated.  This allows associating a "rough" epoch to the Evidence or Attestation Result.  In this case the epoch is said to be

monotonically increasing integers. Like the nonce approach, this allows associating a "rough" epoch <del> without requiring a reliable clock or time synchronization in order to generate or appraise the freshness of Evidence or Attestation Results.  Only the Handle Distributor requires access to a clock so it can periodically send new epoch handles. </del> <ins> without requiring a trustworthy clock or time synchronization in order to generate or appraise the freshness of Evidence or Attestation Results.  Only the Handle Distributor requires access to a clock so it can periodically send new epoch handles. </ins> The most recent handle is included in the produced Evidence or Attestation Results, and the appraising entity can compare the handle