Re: [Rats] Same claim in Evidence and Results (was Re: Second attempt at early allocation of CWT Labels (PR #152))

Laurence Lundblade <lgl@island-resort.com> Wed, 23 February 2022 20:43 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 D6DC43A0C70 for <rats@ietfa.amsl.com>; Wed, 23 Feb 2022 12:43:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Level:
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 OOXWZ4mpWznC for <rats@ietfa.amsl.com>; Wed, 23 Feb 2022 12:43:37 -0800 (PST)
Received: from p3plsmtpa09-03.prod.phx3.secureserver.net (p3plsmtpa09-03.prod.phx3.secureserver.net [173.201.193.232]) (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 76C983A0C9A for <rats@ietf.org>; Wed, 23 Feb 2022 12:43:37 -0800 (PST)
Received: from [192.168.1.4] ([75.80.148.139]) by :SMTPAUTH: with ESMTPA id MyU4n8Suv3v0kMyU4nRtKO; Wed, 23 Feb 2022 13:43:36 -0700
X-CMAE-Analysis: v=2.4 cv=V4m4bcri c=1 sm=1 tr=0 ts=62169c78 a=qS/Wyu6Nw1Yro6yF1S+Djg==:117 a=qS/Wyu6Nw1Yro6yF1S+Djg==:17 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=K6EGIJCdAAAA:8 a=VlthXxjwiTNazAPPJ2AA:9 a=QEXdDO2ut3YA:10 a=b50fPeLvB4pxTmh23_4A:9 a=GJUAU__LWVRCO3Hm:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=L6pVIi0Kn1GYQfi8-iRI:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <EC701CF2-2FC4-4299-8F3E-850CA5370A0C@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_52A99F11-4991-4A5B-9727-C8BE8F726E41"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Wed, 23 Feb 2022 12:43:36 -0800
In-Reply-To: <BL0PR11MB3122F140CCF9C13BB6D1D888A13B9@BL0PR11MB3122.namprd11.prod.outlook.com>
Cc: "Smith, Ned" <ned.smith@intel.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "rats@ietf.org" <rats@ietf.org>
To: "Eric Voit (evoit)" <evoit@cisco.com>
References: <AM6PR08MB43254A236E44B49C1DCD9F8C8E369@AM6PR08MB4325.eurprd08.prod.outlook.com> <4706A62A-DA9F-4FA7-9E65-B27748D3F408@island-resort.com> <c2ea51c0-baeb-14cf-1d32-40b2995bd1ce@sit.fraunhofer.de> <4DABED4B-01F0-4678-8974-DC914BC170C5@island-resort.com> <e8b0895b-e3d9-0e33-e4a2-7d5e8b5ecc5e@sit.fraunhofer.de> <F1D075F6-1704-4B04-B127-9BB590C38004@intel.com> <a2c808b6-e8e9-ff73-b834-8772c5d0c365@sit.fraunhofer.de> <543A724D-C060-43AC-82C6-489D57A898D2@island-resort.com> <C50E82F7-B9FE-48F3-9BF2-2BC05B2A9D51@intel.com> <38794864-746D-43B2-A707-CB992AC197C2@island-resort.com> <61D2495E-E070-4C26-AF02-BE2ABCAAE897@intel.com> <E42B0CEB-2778-4AAF-ABCB-CCDC86286C94@island-resort.com> <5173ED99-D220-4D1A-9E26-7DCA39180A7D@intel.com> <ae5bb667-79f8-469e-09de-12df104d697f@sit.fraunhofer.de> <F5868DD0-D8BC-41EE-9DE8-9E3608F5137E@island-resort.com> <7CFE7304-4F9B-47D2-A899-29AFBF6FD82A@intel.com> <BL0PR11MB3122F140CCF9C13BB6D1D888A13B9@BL0PR11MB3122.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.17)
X-CMAE-Envelope: MS4xfDX+vGfQ3OFmpkSf/rfi1RTOGQ4fgCJ3m9O41OGeFh/mA1HJzYhEiJRqRvCucvW6FaBKjpwDGWb0Wbr0zJAo4wjYW6zCFRpGqtj7h4erAwlpXx2TrICd Vt/HgeY+slyT0kiPvmcGGMsZIcLHl5lxn0sFVVwQ8nyK2bR9p1PPS2ueHy18JCM/kaEkPV3LPso9ArdifzpcXZ9P10NHHU9+I39YKn5LEoLE6v4svGdU393P 4FMRkf4yz9qvxOMoh+L3fkrvw6BICik+nl+7wfLVIhuE9Yk07EHm/5y3WgC9qWR8
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/ebcS9906xW6nL31AjAkcHYZUgNU>
Subject: Re: [Rats] Same claim in Evidence and Results (was Re: Second attempt at early allocation of CWT Labels (PR #152))
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: Wed, 23 Feb 2022 20:43:52 -0000

> On Feb 22, 2022, at 1:00 PM, Eric Voit (evoit) <evoit@cisco.com> wrote:
> 
> Thanks Ned for your last two emails.   
>  
> I have been trying to track the overall conversation across forks.

I fork discussions to try to keep focused on the topic at hand so the topic at hand can close out.


>    I see your comments/questions on the UEID thread as coupled to the thoughts below.  (I.e., "Since scope is defined by the entity that asserts the claims, it would be better to describe claims using terminology that doesn’t assume scope IMHO.”)

Not completely sure, but I think I agree too.


> I agree with this sentiment.  For me this set of threads keeps coming back to establishing claim context to the Relying Party.   If the Policy for Attestation Results doesn't simply and unambiguously know the identity/source of a claim, the architectural role making the claim, and the freshness, then we are wasting our time here.   
>  
> So we need to minimize Relying Party policy language ambiguity.

I don’t quite understand this comment. Maybe my last few paragraphs address this? Maybe my answer is that creating broad general unambiguous RP policy language is a rat hole we don’t want to address in the IETF?


>  For me, I like separating the names of claims which might come from different architectural roles.   Things are easier for Policy programming on the Relying Party this way.
> And we won't suddenly find a claim from a Verifier which now can also come from an Attester.   

Using string labels, would you want something like this?

   “evidence.location”
   “results.location”
   “evidence.ueid”
   “results.ueid"

to separate the location and UEID claims in evidence from results? 

Then maybe when “evidence.location” occurs in an attestation results token you know it was passed through?

In this idea, the structure (e.g., the CDDL) for evidence.location and results.location would be identical.

I’m pretty sure I’m not in favor of this. I’m just given an example to try to understand.


Where this rat holes for me is that the behaviors of the Attester and the Verifier are so widely varying here that it seems not possible to pin them down in an IETF standard. Instead you as an RP must understand on a case by case basis what the Attester and Verifier are doing to know how to trust it. For example,
  
 — The location evidence could come from a US satellite, a Russian satellite, WiFi location maps created by Google, Cellular triangulation from Verizon and/or combinations of the above
 — The Verifier could just verify the signature and pass it on, could cross check the location against the IP address based location service, could ask the carrier for triangulation based on the IMEI,...

There’s no way we here in RATS can sort this variation in trustworthiness for location, nor for most other claims. Maybe there are a few claims we can lock this down for, but in general we shouldn’t even try.

As an RP you have to go read the marketing description, service agreements and such for a verifier service to know what it is going to do for you, not the IETF standard.

LL




>  
> There are alternatives to doing this with namespaces.  But we no proposals going down this path yet.
> 
> Eric
>  
> > -----Original Message-----
> > From: RATS <rats-bounces@ietf.org <mailto:rats-bounces@ietf.org>> On Behalf Of Smith, Ned
> > Sent: Tuesday, February 22, 2022 3:31 PM
> > To: Laurence Lundblade <lgl@island-resort.com <mailto:lgl@island-resort.com>>; Henk Birkholz
> > <henk.birkholz@sit.fraunhofer.de <mailto:henk.birkholz@sit.fraunhofer.de>>
> > Cc: rats@ietf.org <mailto:rats@ietf.org>
> > Subject: Re: [Rats] Same claim in Evidence and Results (was Re: Second attempt
> > at early allocation of CWT Labels (PR #152))
> >
> > I asked for clarification about what attestation roles' perspectives were
> > assumed when describing the various claims. This was because there is language
> > that suggests Endorser / RVP roles were considered. There is language that
> > suggests RP, Verifier and Attester roles are considered too. But it isn't clear that
> > all roles are considered for all claims.
> >
> > I suggested that if the goal was not to consider all roles for all claims, that the
> > claims be described based on a least common denominator assumption. That is,
> > only wording that is true for all roles would be included. It is a bit of a trick
> > question in that you have to consider all roles in order to know what attributes
> > will be common. It also means anything that is specific to a role or nuanced
> > would not be included so as to avoid special case descriptions.
> >
> > That means, terminology that is aimed at manufacturers, relying party, verifier,
> > attester should be removed or clearly identified as informative. My guess is the
> > result will be that the CDDL most closely captures normative expression and
> > most everything else is informative.
> >
> > On 2/22/22, 11:51 AM, "Laurence Lundblade" <lgl@island-resort.com <mailto:lgl@island-resort.com>> wrote:
> >
> >     Absolutely do not want to expand the EAT doc to cover Endorsement and
> > Reference Values in any way, but maybe another draft might make use of some
> > stuff that is in EAT.
> >
> >     Ned suggested it, not me. :-)
> >
> >     LL
> >
> >
> >     > On Feb 22, 2022, at 11:19 AM, Henk Birkholz
> > <henk.birkholz@sit.fraunhofer.de <mailto:henk.birkholz@sit.fraunhofer.de>> wrote:
> >     >
> >     > You are kidding, right?
> >     >
> >     > On 22.02.22 20:12, Smith, Ned wrote:
> >     >> Maybe that’s a good idea. Maybe it’s not. Not sure yet. :-)
> >
> >
> > _______________________________________________
> > RATS mailing list
> > RATS@ietf.org <mailto:RATS@ietf.org>
> > https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>