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

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Mar 2020 11:13:06 -0500

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 4 Mar 2020 17:54:27 +0000

Hi Michael,

> as attestation results, I think this also motivates adding an Expiry claim to

Just to be sure: you are talking about the CWT/JWT exp Claim here, not a new
one, right?

In any case, I agree with you this looks like a reasonable thing to
have, but it also looks like something that is highly context dependent.
I'm not sure EAT is in a position to make hard promises to TEEP or
anyone else in this respect.  A MAY is probably the best we can do.

cheers
--

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.