Re: [Rats] Attestation key material in architecture document

Henk Birkholz <> Thu, 30 July 2020 10:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5B9BA3A105E for <>; Thu, 30 Jul 2020 03:31:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, 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 Ii7tqlHpfAuA for <>; Thu, 30 Jul 2020 03:31:23 -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 6A3DB3A105C for <>; Thu, 30 Jul 2020 03:31:22 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.75,414,1589234400"; d="scan'208";a="19372069"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jul 2020 12:31:19 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BaCQAVoCJf/1lIDI1ggQmBTIIobwN?= =?us-ascii?q?UMCwKhCuRGJwNCwEDAQEBAQEGAQEYCwoCBAEBhEwCgikCJDgTAhABAQUBAQE?= =?us-ascii?q?CAQYEbYVcDEMBEAGFHAEBAQMBAQEhDwEFNhALCQIOBAYCAiYCAicgAg4GAQw?= =?us-ascii?q?GAgEBgyIBglwkC5MSmwR2gTKFUoM7gToGgQ4qAYZNhHyBNA8PgUw/gREnD4I?= =?us-ascii?q?sLj6CXAEBhHWCPiIEkAWCaaJwKQeBWoEIgQgEC4dEkRgFCh6RRQaOKZIfijO?= =?us-ascii?q?UbAIEAgkCFYFqI4FXTSRPgmlQFwINkhCFFIVEQTE3AgYBBwEBAwl8iBiGaAG?= =?us-ascii?q?BEAEB?=
X-IronPort-AV: E=Sophos;i="5.75,414,1589234400"; d="scan'208";a="31814978"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jul 2020 12:31:17 +0200
Received: from ( []) by (8.15.2/8.15.2/Debian-10) with ESMTPS id 06UAVHcD013326 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Thu, 30 Jul 2020 12:31:17 +0200
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 30 Jul 2020 12:31:12 +0200
To: Laurence Lundblade <>, <>
References: <>
From: Henk Birkholz <>
Message-ID: <>
Date: Thu, 30 Jul 2020 12:31:10 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] Attestation key material in 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: Thu, 30 Jul 2020 10:31:27 -0000

Hi Laurence,

I updated issue #65 for you:


This will make it easier for the editors to address your two alternative 
proposals. I think it would help, if you are present when we discuss this.

MCR: do we plan for an editor's meeting next Tue?

Viele Grüße,


On 29.07.20 22:14, Laurence Lundblade wrote:
> I presented this slide below the IETF 108 RATS meeting today. I believe 
> it is critical that the RATS architecture allow for all uses case in the 
> slide.
> In particular RATS architecture must allow for symmetric keys. TPMs and 
> public-key based crypto is too expensive for low-cost, large-scale IoT. 
> There are real use cases supported my multiple companies using symmetric 
> keys. Symmetric keys can be made secure at the verifier — we secure keys 
> for TLS at servers all the time using HSMs and such.
> I do NOT want to put this taxonomy into the RATS architecture document. 
> I don’t think that is necessary. I created the taxonomy as background 
> information and as illustrative examples of real world designs.
> I think there are options for adjusting the architecture document to 
> accommodate this.
>     Option 1) Expand the notion of an Endorsement quite a lot.
>     Endorsements are not longer just static documents like X.509 certs
>     and/or COSE/CMS signed blobs. They are anything that conveys the
>     attestation key material into the Verifier or allows Verification of
>     the attester. They must support confidentiality.
>     Option 2) Replace the term “Endorsement” with something like
>     “Verifier Input” or “Attester Trust Criteria” in the architecture
>     document as the means by which key material goes into the Verifier.
>     Endorsements still exist, but are just one type of Verifier Input or
>     Attester Trust Criteria just like EAT is one kind of Attestation
>     Evidence.
> I have a slight preference for Option 2). I’m interested in opinions of 
> which option to choose.
> This is issue #65 
> <>, opened in 
> GitHub four months ago. It is not a last-minute/new issue. I believe it 
> is in scope with the RATS charter as the charter explicitly mentions 
> attestation key material in the Program of Work.
> LL
> My main point of this taxonomy was to affect the RATS architecture 
> document. There was discussion today of it being a separate document 
> perhaps outside of RATS. I’m happy for that to happen, but I don’t want 
> to write it because I have enough RATS/EAT work to do. I’m very happy if 
> other folks want to pick it up and use in other documents :-).
> _______________________________________________
> RATS mailing list