[Rats] Time stamps in tokens

[Laurence Lundblade <[e-mail]>]

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