IETF Logo Mail Archive

Re: [Rats] should base architecture mandate a distributed structure for Endorsements

Laurence Lundblade <lgl@island-resort.com> Tue, 04 August 2020 20:07 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAE03A1168 for <rats@ietfa.amsl.com>; Tue, 4 Aug 2020 13:07:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgpjXuRL5hmn for <rats@ietfa.amsl.com>; Tue, 4 Aug 2020 13:07:36 -0700 (PDT)
Received: from p3plsmtpa09-10.prod.phx3.secureserver.net (p3plsmtpa09-10.prod.phx3.secureserver.net [173.201.193.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD5333A1158 for <rats@ietf.org>; Tue, 4 Aug 2020 13:07:36 -0700 (PDT)
Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 33DjkrhjRAJJp33DkkFXBy; Tue, 04 Aug 2020 13:07:36 -0700
X-CMAE-Analysis: v=2.3 cv=Sd6JicZu c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=l70xHGcnAAAA:8 a=4ks2tv--jYo28uDXHD0A:9 a=QEXdDO2ut3YA:10 a=NmqXcKuUeqDqKi5QXWUA:9 a=QW3tplsSD7MnHZjy:21 a=_W_S_7VecoQA:10 a=JtN_ecm89k2WOvw5-HMO:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <64EC2783-2E6A-49BE-901F-9A0B8581F9AA@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A9D5136D-3D81-4AD7-85AE-B0F20709A4BB"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 04 Aug 2020 13:07:35 -0700
In-Reply-To: <88357bf6-5fe0-ebd3-fd2a-4383223715f5@sit.fraunhofer.de>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, rats@ietf.org
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
References: <B1E7A6D0-4A08-494F-A065-9D1025A4E209@island-resort.com> <4445014C-A191-4885-BE67-5502EF3E551F@intel.com> <413326C7-E1BA-43A1-BAD0-015AC0B5AD0F@island-resort.com> <MWHPR11MB1439D21DA4B20ABCC97214F2E5720@MWHPR11MB1439.namprd11.prod.outlook.com> <2900.1596296932@localhost> <7A5BB0EB-BA4F-4210-87C0-E9F9C6C23979@island-resort.com> <88357bf6-5fe0-ebd3-fd2a-4383223715f5@sit.fraunhofer.de>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfLgLA5hsB0cCC/SkhlsgbNy6PiLwJiWMksZBKeOBPS1SemcCNiWfEi1uGCovIKq+0EU3tV8SMNTmaPsMYkTN0KdgBoeIgdpgv+UL/Lxj4N/pyjILYZKi 7vKOnFSG+vx3FK4u3cIkeDZgATaXU693DTLjpAka4/GNBj5pMJ1G92gND9Ht2laXDpu27w9LppKQAXgJLt6lecCritzVpyzes2Xl9IFU07RrAciQKyw6gx6a HmAmYUs45J91eBFnkWyKMQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/aoySoiRI2O_tug38VPVfEeskjk4>
Subject: Re: [Rats] should base architecture mandate a distributed structure for Endorsements
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2020 20:07:38 -0000

below.

> On Aug 3, 2020, at 10:44 PM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:
> 
> A single vital comment in-line:
> 
> On 01.08.20 21:37, Laurence Lundblade wrote:
>>> On Aug 1, 2020, at 8:48 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>>> 
>>> ...
>>> 
>>> There are other use cases in which the Verifier will be configured with all
>>> the information that it needs.  Is a configuration file, loaded by a trusted
>>> operator, a "secure statement"?
>>> I think so, and this is why we used this wording. (B)
>> My view is that the arrows in the diagram show the complete and exhaustive inputs of relevance to attestation.
> 
> Probably adjusting the expectations of the arrows in the diagrams wrt to "completeness" can mitigate this issue at it's root?

Not sure what you’re thinking. 

My main thought is that verification key material is one of the most important things in the architecture. It should be explicitly discussed in the architecture (like nonces) and it must be go over the arrow between the Endorser/Manufacturer and the Verifier.

LL

v2.23.0 | Report a Bug | By Email