Re: [Rats] Use case -> architecture document

Henk Birkholz <> Sun, 03 November 2019 18:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68963120018 for <>; Sun, 3 Nov 2019 10:37:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eyy0D3TByhbG for <>; Sun, 3 Nov 2019 10:37:19 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A83DB12008C for <>; Sun, 3 Nov 2019 10:37:18 -0800 (PST)
Received: from ( []) by (8.15.2/8.15.2/Debian-10) with ESMTPS id xA3IbAG0020885 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Sun, 3 Nov 2019 19:37:11 +0100
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.3.468.0; Sun, 3 Nov 2019 19:37:05 +0100
To: =?UTF-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= <>, Dave Thaler <>
CC: "" <>
References: <> <> <> <> <> <> <> <> <> <>
From: Henk Birkholz <>
Message-ID: <>
Date: Sun, 3 Nov 2019 19:37:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.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] Use case -> architecture document
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: Sun, 03 Nov 2019 18:37:21 -0000

Hi Jürgen,

in the RATS WG we split that specific challenge/response interaction 
(there are others, but this is the best understood one) out into this 


An complementary approach was recently introduced here:


Both types of (and by inference - all) interaction adhere to the same 
"attestation principles" (which we are currently relabeled to 
"attestation characteristics" but this is more a matter of finding the 
most intuitive title here), which are included in one of the 
architecture documents.

I think you highlighted a good question that we should put to a call for 
consensus: Are attestation characteristics, such as freshness, 
provenance (often referred to as origination), or veracity defining (or 
vital) concepts for remote attestation procedures so that they belong 
into the architecture document?

Viele Grüße,


On 15.10.19 17:45, Schönwälder, Jürgen wrote:
> Henk's architecture discusses 'Attestation Principles' that are not in
> Dave's proposal. I guess the WG needs to decide whether to include
> them or not. Are these important for understanding or guiding the RATS
> work?
> I also like to mention that there are research papers where the remote
> attestation process is described more in the form of a challenge
> response interaction, where the verifier sends a specific challenge to
> a device and the device returns a response that is than evaluated by
> the verifier. An example is "compute a hash over certain memory areas
> within a certain time limit" and then the device returns the result
> and the verifier checks whether it is what is expected.  The time
> limit is used to control that an infected device can't reasonably
> forward the challenge to obtain an answer from an unaffected device
> that is then relayed back to the verifier. The question is whether the
> architecture includes models where a stimuli is used to trigger the
> production of a certain Evidence or whether this is left out of the
> architectural picture on purpose. For more details, see for example
> <> (you will find a preprint if you search).