Re: [Rats] Use case -> architecture document

Henk Birkholz <> Wed, 16 October 2019 15:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D068312095E for <>; Wed, 16 Oct 2019 08:07:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 8nmCixGx4uTd for <>; Wed, 16 Oct 2019 08:07:09 -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 E3F35120935 for <>; Wed, 16 Oct 2019 08:07:08 -0700 (PDT)
Received: from ( []) by (8.15.2/8.15.2/Debian-10) with ESMTPS id x9GF74Zg009943 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Wed, 16 Oct 2019 17:07:05 +0200
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.3.468.0; Wed, 16 Oct 2019 17:06:59 +0200
To: Kathleen Moriarty <>, Michael Richardson <>
CC: "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Henk Birkholz <>
Message-ID: <>
Date: Wed, 16 Oct 2019 17:06:55 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.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] 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: Wed, 16 Oct 2019 15:07:20 -0000

Hi Kathleen,
hi list,

there was an interesting follow-up on discussion how RFC4949 data origin 
authentication ("The corroboration that the source of data received is 
as claimed."), attestation provenance & device identity are strongly 
intertwined, but mean different things in the context of RATS (well, 
actually the example this was discussed on was a subset of RATS: the RIV 

Another good example coming out of that discussion were the subtle 
difference between the RFC4949 term "fresh" ("Recently generated; not 
replayed from some earlier interaction of the protocol") evidence and 
the "freshness of evidence" (in contrast to "recentness of claim _and_ 
evidence creation"), which also mean quite different things.

Last example I want to provide as food of though from that discussion is 
"proof of possession" vs "proof of availability at a specific point in 
time" This differentiation is a quite important for DICE-based remote 
attestation procedures, where the persistence of an alias key and 
corresponding certificates for attestation can be significantly shorter 
than, e.g. an associated DevID [1]. The point being, the semantics 
around the terms are vital, but unfortunate also easily conflated, if 
not worded with precision in a bigger context.

The conclusion was to be very carefully about not conflating different 
things for the sake of simplicity, I think.

Viele Grüße,



On 16.10.19 16:35, Kathleen Moriarty wrote:
> origin authentication