[Teep] "SLA" on Attestion Results, or validity lifetime

[Michael Richardson <[e-mail]>]

https://github.com/ietf-rats-wg/architecture/issues/42

asks:
        TEEP and others needs to know what kind of SLA RATS can provide.

DaveThaler:
The related TEEP issue is ietf-teep/architecture#148 and an initial TEEP
architecture PR is at ietf-teep/architecture#153 which punts part of the
problem to the RATS architecture, since it refers to the RATS arch for more
discussion.

A key architectural question is whether an attestation result may/should/must
have a validity lifetime encoded in it (like DNS responses etc. have TTLs) or
not. That is, can the Verifier say that an attestation result it generates
has an expiration associated? (Physical passports and drivers licenses for
example do have an expiration associated, as do X.509 certificates.)

Or is the lifetime only implementable by the Relying Party based on other
information like a Timestamp in the attestation result and its own appraisal
policy for attestation results?

And is there any requirement that a Relying Party and an Attestation Server
need roughly synchronized clocks? (I suspect yes.)

Offhand, I think that it would be good to allow attestation results to
include an expiration timestamp. (Aside: assuming we want EATs to be usable
as attestation results, I think this also motivates adding an Expiry claim to
the EAT document.)

mingpeiwk commented 16 hours ago
          I concur that a validity period should be associated with an attestation
          result. This is a common best practice for various assertions, certificates
          etc. as Dave listed.

mcr commented 15 hours ago
          I don't think that the we need to have a lifetime in the
          Attestation Results. The Relying Party gets to decide if the
          results are fresh enough. We have two ways to prove freshness: some
          kind of pronouncement of time from "above" (maybe it's GPS, I don't
          know) such as imagined by TUDA, or some kind of nonce-based
          system.

          If the RP issues the nonce, it knows when it issued the nonce, so
          it knows how fresh the Attestation Results must be. It also knows when it
          first got those results.

          (Same thing applies RP->Verifier, and AttestationResults->Evidence)

MCR: I believe that in the TEEP case that everything is sufficiently "online"
     that freshness via nonces is probably better than freshness by
     synchronized clocks.  Other users may have different requirements, and
     thus https://datatracker.ietf.org/doc/draft-birkholz-rats-tuda/

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-