Subject: [Rats] Time stamps in tokens

From: Laurence Lundblade <[email-masked]>
Date: Tue, 10 Mar 2020 13:26:40 -0700

The issue of time stamps came up in the architecture group. Some discussion is here in GitHub <https://github.com/ietf-rats-wg/architecture/issues/42>.

This is a rough proposal for changes to EAT to make it more sophisticated and flexible at handling time stamps. This is not actual normative text yet.

Creation time — This is the time that the value for a claim came to be, for example the time a measurement or a sample was taken. This value may be stored for a long time before the Attester collects it. Examples include a GPS sample taken before entering a basement, a SW measurement taken at boot or a SW integrity measurement taken by a run time integrity checker (RTIC).

Each claim, or even sub parts of a claim can have its own Creation Time. You could say Creation Time is roughly per-claim.

There is no generic means for time stamping a claim, instead the definition of each claim for which Creation Time is important should include a data item for a Creation Time.

EAT would add time a stamp to the location claim and for any measurement and integrity check claims. Most of the other claims don’t vary over time.

Issued At Time (collection/signing time) — This is the time that a token is created, the time when all the claims are collected and the token is signed. For simplicity, it is assumed that all the claims are collected at the same time and that is the same time that the token is signed.  Each submodule may have an Issued At Time. Though it is not expected to be common, this makes submodules a way to group claims that are collected together at a different time.

The Creation Time can be absolute or relative. If relative, it is to the Issued At Time and is filled in by the attester when collecting the claims values.

The Issued At Time is either absolute or absent, never relative (If we allow it to be relative, we have add the complexity of distinguishing the collection time from the signing time and assume the signing time is the conveyance time as we don’t want any claims that are not signed).

The Expiration and Not-Before Time claims typically only go in the Attestation Result, the output of the Verifier, but they may occur in Attestation Evidence too. Like the Issued At Time, they are per submodule and absolute. When they go in the Attestation Result, they represent some recommendation by the Verifier as to the validity period, typically how long until the token is no longer considered trustworthy. It is more meaningful for the Verifier to make this recommendation than for an Attester to claim this about itself.

 (A time-to-live/expire could be added as a relative expiration time if we want to accommodate Verifiers that don’t know what time it is).

Since Issued At, Expiration and Not-Before already exist in CWT, all that is needed is some explanatory text for them.

LL

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 10 Mar 2020 21:55:34 +0000

Hi Laurence,

On 10/03/2020, 20:27, "RATS on behalf of Laurence Lundblade"
<[email-masked] on behalf of [email-masked]> wrote:
> [SNIP]

Thanks.  A couple of fly-by thoughts:

- I don't understand the semantics of nbf in the context of attestation.
  How could someone produce attestation material that is not yet valid?

- Another thing that confuse me is the fact that nbf and exp are
  supposed to be per submodule -- which potentially creates funny
  situations where a token is not entirely processable because the
  validity ranges of some of its submodules are non-overlapping.

cheers, t
--

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.