Re: [Rats] FW: New Version Notification for draft-shaw-rats-rear-00.txt

Henk Birkholz <> Thu, 02 July 2020 14:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 86F093A0817 for <>; Thu, 2 Jul 2020 07:05:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bR30mX5eoWYj for <>; Thu, 2 Jul 2020 07:05:13 -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 16BC33A08AF for <>; Thu, 2 Jul 2020 07:05:08 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.75,304,1589234400"; d="scan'208";a="18826798"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jul 2020 16:05:05 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DdAwD16P1e/1lIDI1fHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqBdQYvbwNUMCwKhCeRE5ocgRADVQsBAwEBAQEBBgEBGAY?= =?us-ascii?q?PAgQBAYRHAoIcAiQ4EwIQAQEFAQEBAgEGBG2FWwyFbgEBAQECAQEBIQ8BBTY?= =?us-ascii?q?CAgUHCwkCEgYCAiYCAicgAg4GAQwGAgEBgyIBglwkC41/mwR2gTKEPgIOQUK?= =?us-ascii?q?DZIE6BoEOKotKgQ8PD4FMPyZrJw+CWj6CXAEBAgEBgSYBEgFNgmqCYASMa4I?= =?us-ascii?q?VBwoigwOGaZpnXCgHgVmBBoEHBAuHNYsphUoFCh2CczaIeoR1BieNWJFZihy?= =?us-ascii?q?RGFaCVgIEAgkCFYFqImZwTSQuIYJpUBcCDY4qF4ECAQEBhS2CMIVEQTECNQI?= =?us-ascii?q?GAQcBAQMJfI1RATFfAQE?=
X-IronPort-AV: E=Sophos;i="5.75,304,1589234400"; d="scan'208";a="116770282"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jul 2020 16:05:03 +0200
Received: from ( []) by (8.15.2/8.15.2/Debian-10) with ESMTPS id 062E52TF031209 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Thu, 2 Jul 2020 16:05:02 +0200
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 2 Jul 2020 16:04:57 +0200
To: Thomas Fossati <>, "" <>
References: <> <>
From: Henk Birkholz <>
Message-ID: <>
Date: Thu, 2 Jul 2020 16:04:56 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: []
Archived-At: <>
Subject: Re: [Rats] FW: New Version Notification for draft-shaw-rats-rear-00.txt
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, 02 Jul 2020 14:05:17 -0000

Hi Thomas,
hi authors,

please let me start with: I really like what this I-D is about; 
especially how everything is basically arranged around how to use 
timestamps and nonces in several specific interactions. The essence here 
is the qualified data conveyed via restful operations that are used to 
create Conceptual Messages, such as Evidence or Attestation Results.

The fact that all these different types of qualifying data are bound 
with each other via sequences of restful operations makes the 
relationship of the sequence diagrams rather complex and renders the use 
of the qualified data / handles hard to read. At the same time, I am 
uncertain how to avoid that, though.

You managed to get all the semantic relationships into the sequence 
diagrams themselves. I am quite impressed. But I could only decipher the 
notation while parsing them with the help of a little cheat sheet that I 
wrote down on a piece of paper.

This topic is intrinsically complex, so - as I already said - I am 
unable to provide an immediate proposal how to increase readability. The 
fact remains that this is a very useful -00 I-D. Suffice to say that I 
would rather have this content in this form than not at all!

Coincidentally, more generic versions of your diagrams with respect to 
the reference interaction models can be found in this editor's version:


These diagrams use simpler annotation, but therefore are also way more 
generic. They match with your more specific semantics, though, and I am 
very happy about that.

We also struggled a bit with the illustration of the processing of 
qualified data in TUDA and based on your new I-D we can now try to 
improve them.

Viele Grüße,


On 12.06.20 19:00, Thomas Fossati wrote:
> Hi, all,
> We have just submitted a new draft "RESTful attested resources" (details
> below).
> The main goal here is creating a mechanism to expose attested system
> state as RESTful resources (i.e., "things" that can be de-referenced by
> their URIs) together with a way to securely bind said system state with
> an EAT token.
> We define two REST interfaces: one to the Attester and one to the
> Verifier, with timestamp- and nonce-based freshness.  We show how these
> can be composed into the usual "background check", "passport" and
> "time-based unidirectional" patterns.  HTTP and CoAP instantiations are
> provided, together with the associated MIME machinery.  A discovery
> method is also discussed based on the CoRE Resource Directory.
> This proposal seems in scope with the RATS charter, in particular its
> "Standardize interoperable protocols to securely convey
> assertions/claims." bit.  We hope this provides a valid contribution on
> how the RATS architecture and basic protocol elements can be used in
> high level protocol(s), and would really appreciate any feedback with
> regards to its usefulness, correctness and completeness.
> cheers, thanks!
> On 12/06/2020, 17:48, "" <> wrote:
>> A new version of I-D, draft-shaw-rats-rear-00.txt
>> has been successfully submitted by Thomas Fossati and posted to the
>> IETF repository.
>> Name:draft-shaw-rats-rear
>> Revision:00
>> Title:Restful Attested Resources
>> Document date:2020-06-12
>> Group:Individual Submission
>> Pages:23
>> URL:  
>> Status:
>> Htmlized:
>> Htmlized:
>> Abstract:
>>     This memo describes a REST interface based on the RATS architecture
>>     that can be used to retrieve attested system state, for example the
>>     reading of a security critical sensor.  The objective is to present a
>>     common vocabulary of data formats and basic protocol transactions
>>     that can be pieced together into a cohesive interface that is capable
>>     of serving different attestation workflows.
> 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