Re: [Rats] Age Claim in EAT

Laurence Lundblade <> Thu, 30 July 2020 19:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1A793A0BAB for <>; Thu, 30 Jul 2020 12:29:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Uv5Q1dqBK11L for <>; Thu, 30 Jul 2020 12:29:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BCA393A0B98 for <>; Thu, 30 Jul 2020 12:29:33 -0700 (PDT)
Received: from [] ([]) by :SMTPAUTH: with ESMTPA id 1EFAkPgO5kxIh1EFAkOkjY; Thu, 30 Jul 2020 12:29:32 -0700
X-CMAE-Analysis: v=2.3 cv=SPU8q9nH c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=0XtbOteLAAAA:20 a=48vgC7mUAAAA:8 a=Gu6Bvr1FBC0pGGtCSaIA:9 a=Vl5KeozEUxxqEmUB:21 a=DDoqwnbPaTKbGcyp:21 a=QEXdDO2ut3YA:10 a=xD0DdyzbBirqtujzj54A:9 a=OYDYWUbVYQmT748B:21 a=yXhaxGT5ovurwyWv:21 a=CIpUWA5r0H2WPRer:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22
From: Laurence Lundblade <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_37C70FCD-672A-4FEE-835B-1C39D4DB5D92"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 30 Jul 2020 12:29:31 -0700
In-Reply-To: <>
Cc: Hannes Tschofenig <>, "" <>
To: Henk Birkholz <>
References: <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfB0QPGlICqIKvAkO8NU3szv551XVyNkTkx09n9XPsg4rAgNdUnOEwyy4Bfo5KgxfK45EsnxbUbLMb0s7SX53AOuTA0igrHavw5whw7uJx316fzUUx00P 9M8uLYbW5vOSp/wfGj8MwOWWjvALnXiOfW/q9fwatTVR4r6H45sAM4mE9rQrhtJCjnsXpan/ZxNXlCg6EyHsDGnELEoQXgJaUTdvjwQ3C/aLn+YUHLwqhbKn pOqUgk3PQ8hpaj5BGGGCFQ==
Archived-At: <>
Subject: Re: [Rats] Age Claim in EAT
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Jul 2020 19:29:36 -0000

In concept, age is the difference between time(VG) and time(EG) as described in RATS Architecture Appendix A.

I think time(EG) is when the token is signed (or otherwise cryptographically protected). I’m surprised that Appendix A doesn’t define it as that important moment. Claims can change after time(EG).

After Eric created the timing diagrams for architecture I re-thought the age claim. I don’t think it is a general independent claim, but rather is an attribute of individual claims, for example the age of a location or of a SW measurement.  PR #59 <> removes it as a top-level claim and adds an age item to the location claim.

There was some discussion between these two options:
  - Define a general way to add attributes like age (or time stamp) to any claim — A general claim decoration mechanism
  - Add an age (or time stamp) field to claims that need it

I’ve tended away from general attributes to keep code size and complexity down.

But what I really want to know is which manufacturer Endorses Henk, what is in his Endorsement and whether it is signed by a public key pair or a symmetric key. :-)


> On Jul 29, 2020, at 2:11 AM, Henk Birkholz <> wrote:
> Hi Hannes,
> in the scope of Evidence:
> Signing a CWT structure is creating an EAT. This event is defined as time(EG) here:
> "Creating a token" would mean "Evidence Generation", for example.
> Age also is a time interval based on a time unit (units that apply to Henk are years, I claim that Henk's age is 21, of course. Trust in Henk's Claims can be established via Endorsements). Age is a time interval expressed as a duration. That means that the beginning of that time interval is set as zero (an epoch) and then counts the time units.
> The semantics of age in EAT are:
> the epoch is time(EG) and the unit is seconds.
> This only works, if time sources for relative time-counters are available, of course.
> Collection of Claims - time(CC) was proposed to the architecture, but did not find consensus yet (we are working on time(AA), though, the time at which the Attester becomes aware of a changes value in the Target Environment right now).
> But! there is time(VG), the Value Generation. This time can often only be inferred or approximated (in contrast to time(AA)), but it is the best we have defined right now in the context of:
>> If that's the case, I wonder whether it would also make sense to take into account that different information may be collected at a different point in time and hence the age indication would better go (somehow) with specific claims where the time difference between the collection of the data and the signature generation matters.
> As a note: We have not talked at all before about the common concept of "latches" or stage transitions... this is an important concept that does capture the "this event has happened" (before/after a defined event) and represents strong security implications that are not included in the RATS architecture today. Would that maybe help in your context?
> Viele Grüße,
> Henk
> On 29.07.20 10:37, Hannes Tschofenig wrote:
>> Hi Laurence, Hi all,
>> How does the age claim work?
>> The spec says "represents the number of seconds that have elapsed since the token was created".
>> By creating a token you also protect the claims with a signature and hence you cannot change the content of the claims anymore (without breaking the signature).
>> Hence, here "creating a token" must mean something different. I suspect it means when certain values have been collected from the device and before the token with the signature was put together. Correct?
>> If that's the case, I wonder whether it would also make sense to take into account that different information may be collected at a different point in time and hence the age indication would better go (somehow) with specific claims where the time difference between the collection of the data and the signature generation matters. I also wonder whether the number of seconds matter and whether you really want to communicate something more abstract, such as "I created a hash over the firmware during boot time" rather than "I created the hash over the firmware in real-time when I was asked".
>> Ciao
>> Hannes
>> 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.
>> _______________________________________________
>> RATS mailing list
> _______________________________________________
> RATS mailing list