Re: [Rats] Verifier Input instead of Endorsement?

Laurence Lundblade <lgl@island-resort.com> Tue, 07 July 2020 18:33 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 403623A12EC for <rats@ietfa.amsl.com>; Tue, 7 Jul 2020 11:33:09 -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 drNYQO-jJmNL for <rats@ietfa.amsl.com>; Tue, 7 Jul 2020 11:33:05 -0700 (PDT)
Received: from p3plsmtpa06-04.prod.phx3.secureserver.net (p3plsmtpa06-04.prod.phx3.secureserver.net [173.201.192.105]) (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 3F49A3A12E7 for <rats@ietf.org>; Tue, 7 Jul 2020 11:33:05 -0700 (PDT)
Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id ssOuj0MjSM35XssOujkBbY; Tue, 07 Jul 2020 11:33:04 -0700
X-CMAE-Analysis: v=2.3 cv=CPNUoijD c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=l70xHGcnAAAA:8 a=K6EGIJCdAAAA:8 a=48vgC7mUAAAA:8 a=ofYvtE0aFZij48KlY58A:9 a=CiRLc6Zg4CwvyvVC:21 a=_m-u16Nmaq-ETrO8:21 a=QEXdDO2ut3YA:10 a=XFnbsQTGpD2PEx90iHUA:9 a=zr1vfRI-dJudO5yM:21 a=2k5Q7PAH-wLEBB1p:21 a=ASXVY3NQGGO-thxP:21 a=_W_S_7VecoQA:10 a=JtN_ecm89k2WOvw5-HMO:22 a=L6pVIi0Kn1GYQfi8-iRI:22 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <B95C972D-5EED-48FD-8F00-B1C52932B5B9@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_901EE0F4-2C75-4D51-B96F-A93283B947D4"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 07 Jul 2020 11:33:02 -0700
In-Reply-To: <0a747f8c-81eb-2c03-46d3-73977faee457@sit.fraunhofer.de>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "rats@ietf.org" <rats@ietf.org>
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
References: <878E068C-DAFD-4441-94F7-BA79CAF7FED6@island-resort.com> <BL0PR2101MB10279501A4ECA5BB7B6AED63A36F0@BL0PR2101MB1027.namprd21.prod.outlook.com> <BF5071AC-0C8D-4B26-8330-8589736B6EF5@island-resort.com> <af8e64b9-41b3-f42a-183d-1c9544fc1d7d@sit.fraunhofer.de> <C4D6DCB6-F0D9-4858-823C-7B045005B48C@island-resort.com> <13132.1593723461@localhost> <6091010E-3F7D-4B45-9B8E-9D954CE03C43@island-resort.com> <24201.1593904708@localhost> <59471994-1797-42CE-AC6F-34F07315ADFB@island-resort.com> <0a747f8c-81eb-2c03-46d3-73977faee457@sit.fraunhofer.de>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfCWjJTsUbojarUyfiHgWQauft9iqTgVxCmRRocFSjokmXyFTKNZXmNtCU3ubCVFc6SPt9voReKAmbrxDzyWe9pKvWq+ZEPdOJAH38StK0JlcOyiEb/L6 B3tlSu7nm9qsqXUOk1mdEpZ0ccvCYgC9ylmr3sZF+Re1S8NKRy4E+fvcrZDjLtKdA+aa1KpgHl/vII4aaxKjW8HXbmezSFF11TCggJ+4Xf+pPi134HDKgDxV x/YUa5qOrTDBdg3OWFnijQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/ekALukJs4Ufxv5PwDMPoIVspBO0>
Subject: Re: [Rats] Verifier Input instead of Endorsement?
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, 07 Jul 2020 18:33:09 -0000


> On Jul 7, 2020, at 8:29 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:
> 
> Hi Laurence,
> 
> at first, I thought I get your line of thought, but now I am confused again. Sorry! Comments in-line.
> 
> On 07.07.20 16:51, Laurence Lundblade wrote:
>>> On Jul 4, 2020, at 4:18 PM, Michael Richardson <mcr+ietf@sandelman.ca <mailto:mcr+ietf@sandelman.ca> <mailto:mcr+ietf@sandelman.ca <mailto:mcr+ietf@sandelman.ca>>> wrote:
>>> 
>>> 
>>> Laurence Lundblade <lgl@island-resort.com <mailto:lgl@island-resort.com> <mailto:lgl@island-resort.com <mailto:lgl@island-resort.com>>> wrote:
>>>>> Laurence Lundblade <lgl@island-resort.com <mailto:lgl@island-resort.com> <mailto:lgl@island-resort.com <mailto:lgl@island-resort.com>>> wrote:
>>>>>> The problem with Endorser is that they produce Endorsements and I think there are problems with Endorsements:
>>>>> 
>>>>>> - In Berlin you told me they don’t have keys in them. So then how do
>>>>>> keys get into the Verifier?
>>>>> 
>>>>> Well, first, I thought we agreed that the arcs above Verifier were out of
>>>>> scope for the architecture.  The WG might recharter to include that, but I
>>>>> thought we agreed that the concerns were seperable.  HOWEVER...
>>> 
>>>> If that’s the approach, then Endorsements should be removed from the
>>>> document, both in the text and diagram.
>>> 
>>> That makes no sense to me.
>>> 
>>> It is perfectly reasonable to define something just well enough in order to make it
>>> clear what is out of scope for standardization.
>>> 
>>> We can come up with many different ways to standardize Endorsements (or
>>> Verifier Inputs), and it shouldn't matter at all to the protocol between
>>> Attester and Verifier.
>>> 
>>> That's what makes it seperable.
>>> Do you agree?
>> Sorry, didn’t say that right.
>> If we’re going to minimize description of what is above the Verifier, then the term “Endorsement” should be replaced with a more general term like “Verifier Input” or “Attester Trust Criteria” or other.
>> I think there are three problems with the term “Endorsement":
>> - It implies a specific style of input (a signed document) that is too narrow for a general architecture
> 
> If that is what a reader gets from the document we have to do better. An endorsement does not have to be signed in the way that a UCCS does not have to be signed. It has to be tamper-evident though, because the Verifier relies on its integrity. That's the point and I think that is not too narrow.

If you want to define an Endorsement as a *protocol*, not just a signed/unsigned document, then the term might work.

Endorsement Protocol:
 - A one-time transfer or a multiple requests/responses for each and every Verification or anything in between
 - Must provide integrity
 - May have to provide confidentiality, particularly for symmetric keys


>> - It is ambiguous and/or not clear it is even correct. The room in Berlin of experts agreed that Endorsement can’t have keys in them, but there must be a key input to the Verifier.
> 
> Well, my recollection of that room of experts does not include any opinions on key material for Endorsements as defined for IETF RATS. The TCG defines (I just looked that up) four specific terms around and "Endorsement Key", so I am relatively sure that key material is involved in all cases, as these are the only terms that make use of the phrase endorsement.

My slide in Berlin said “Endorsements have key material”. You that wasn’t right. I said “sorry for my mistake”. The room tacitly agreed with you.

This says to me that at least one of these is true:
 - There is some pre conceived idea for what Endorsements are, seemingly from the the TCG world
 - There is confusion about what Endorsements are (you said no keys in Berlin, now you say there are keys)
 - RATS architecture is not clear about how verification key material gets to the Verifier.

I don’t mind being wrong here. My trouble is the lack of clarity, common understanding and gap in the RATS architecture.

> 
>> - It is TCG-specific. The term is not used in FIDO, Android and TEE-based projects that I’ve worked on.
> 
> And this confuses me. I'll do a self-quote here: "Endorsements as defined for IETF RATS". We are defining that term here in the RATS architecture. The TCG does not define it in any document that I could google just now. Maybe I have missed something there. But that is beside the point anyways. The point is that we are defining it here.

Seems to me there are semantics associated with the term “Endorsement” from the TCG and that seems to be of a relatively static document that is transferred once. It seems like adopting a definition in RATS that is beyond that is confusing (e.g., confusion between now and Berlin).  If we must use the term Endorsement, then I think it should Endorsement Protocol to separate from the previous.

I still think this is simple and could work:

Verifier Input

Inputs used by the Verifier to establish trust in Attester, evaluate Attestation Evidence and produce Attestation results. It may include cryptographic keys, known-good/reference values, static implicit claims and policy configuration.

LL



> 
> 
> Viele Grüße,
> 
> Henk
> 
>> Some text like this?
>>    Verifier Input
>>    Inputs used by the Verifier to establish trust in Attester, evaluate
>>    Attestation Evidence and produce Attestation results. It may include
>>    cryptographic keys, known-good/reference values, static implicit
>>    claims and policy configuration.
>> LL
>> _______________________________________________
>> RATS mailing list
>> RATS@ietf.org <mailto:RATS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org <mailto:RATS@ietf.org>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>