Re: [Rats] About current RATS drafts

Henk Birkholz <> Fri, 01 November 2019 15:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A4B21201EA for <>; Fri, 1 Nov 2019 08:38:23 -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 xCwljggYmkrt for <>; Fri, 1 Nov 2019 08:38:20 -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 143A3120232 for <>; Fri, 1 Nov 2019 08:38:19 -0700 (PDT)
Received: from ( []) by (8.15.2/8.15.2/Debian-10) with ESMTPS id xA1FcGmc018726 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Fri, 1 Nov 2019 16:38:17 +0100
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.3.468.0; Fri, 1 Nov 2019 16:38:11 +0100
To: Laurence Lundblade <>
CC: H Y <>, <>
References: <> <> <> <>
From: Henk Birkholz <>
Message-ID: <>
Date: Fri, 1 Nov 2019 16:38:10 +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] About current RATS drafts
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: Fri, 01 Nov 2019 15:38:23 -0000

Hi Laurence,

I'll map that to the terminology that is still consistent between the 
initial architecture I-D and Dave's condensed architecture I-D. Also a 
question at the end.

> The input to the verifier may be software measurements (TPM or EAT format).

That is the Attestation Evidence (that was the only thing I meant when 
talking about the "two primary focuses".

> The output of the verifier might be a Boolean that the measurements were correct.

That is (the most simple, but most certainly viable) the Attestation Result.

> If the verifier knows that the device will never send an attestation is the boot and debug state are not locked down, then the verifier can add those claims.

I do not fully follow you here, I am afraid. Which Claims can be added 
by the Verifer to what at which time? :) I assume you mean that the 
Attestation Result can include implicit assertions based on the 
attestation Provenance - expressed as Claims. I am not really sure, what 
type of claims you are implying, though.

Viele Grüße,


On 01.11.19 16:24, Laurence Lundblade wrote:
> Hi Henk,
> good point.
> Yes, EAT has been focused on 1) below. However it seems we might expand 
> EAT to 2) especially considering that 2) is not constrained by the TPM. 
>   I’ve added an issue <> to 
> the EAT GitHub to track this possible work.
> Here’s two examples:
>     The input to the verifier may be software measurements (TPM or EAT
>     format). The output of the verifier might be a Boolean that the
>     measurements were correct.
>     Some implicit claims might be made explicit. For example, if the
>     verifier knows that the device will never send an attestation is the
>     boot and debug state are not locked down, then the verifier can
>     add those claims.
> LL
>> On Nov 1, 2019, at 7:57 AM, Henk Birkholz 
>> < 
>> <>> wrote:
>> Hi Laurence,
>> good point. There are basically two primary focuses here, I think:
>> 1.) Evidence that includes Trustworthy Claims about the Attester, and
>> 2.) Evidence that includes Claims about the Trustworthiness of the 
>> Attester.
>> In 1.) you can put trust into the Veracity of Evidence due to the 
>> attestation Provenance, in 2.) you are given the decision basis for 
>> assessing the Trustworthiness/Integrity of the attestation Provenance.
>> Laurence, please correct me if I am wrong, but the current EAT draft 
>> focuses on 1.). Is that correct?
>> Viele Grüße,
>> Henk
>> On 01.11.19 15:25, Laurence Lundblade wrote:
>>> Hello,
>>> A frame up that works for me is to think about 1) the claims, the 
>>> attestation format and its details and 2) the transport / conveyance 
>>> and its details.
>>> In the TPM/TCG world the claims and attestation format is locked down 
>>> by what TPM chips do today. It is a set of registers that hold hash 
>>> values used to measure software.  In the EAT world, which typically 
>>> implements on fully functional CPUs, the claims and attestation 
>>> format is not at all locked down and our work is to define it (the 
>>> eat draft).
>>> A lot of the network and router folks have been putting TPMs into 
>>> their routers and now need a way to get the TPM output off the router 
>>> to the network management center. This world runs off of Yang 
>>> protocols. The main interest there is a very specific Yang-based way 
>>> to move TPM output. This is the yang, tuda and pubsub drafts.
>>> The EAT use cases are more about TEE’s and lining up with 
>>> end-user-application-oriented uses like FIDO and the Android key 
>>> store. They make use of all the existing transports used by 
>>> application protocol (mainly HTTP) so there’s no worry about defining 
>>> transport.
>>> I think a few of us see EAT as the more general and flexible 
>>> attestation format that will eventually replace the TPM format. 
>>> Because EAT can use CBOR and COSE which are carefully designed for 
>>> constrained devices there is some hope that it can go into TPM-like HW.
>>> The architecture draft is trying to tie the two together in a sort of 
>>> unified field theory. Seems possible, but hard to me.
>>> LL
>>>> On Nov 1, 2019, at 5:08 AM, H Y < 
>>>> <> <>> 
>>>> wrote:
>>>> Hi all,
>>>> I'm Yuhei Hayashi, network security researcher of NTT in Japan. I
>>>> learned about the existence of RATS WG at IETF 105.
>>>> I'm interested in the work of RATS WG and I'm trying to understand it.
>>>> So, I'm firstly trying to understand which drafts contain the
>>>> standards listed in the charter.
>>>> I will attach the result of organizing it from my own point of view.
>>>> I'm glad if you confirm that my understanding is correct, if possible.
>>>> Thanks,
>>>> Yuhei
>>>> -- 
>>>> ----------------------------------
>>>> Yuuhei HAYASHI
>>>> <> 
>>>> <>
>>>> ----------------------------------
>>>> <RATS_drafts.pdf>_______________________________________________
>>>> RATS mailing list
>>>> <>
>>> _______________________________________________
>>> RATS mailing list
>>> <>