Re: [EAT] Device Identity (was Re: [EXTERNAL] Re: [Rats] Attestation BoF charter updates?)

Carsten Bormann <cabo@tzi.org> Mon, 22 October 2018 11:46 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: eat@ietfa.amsl.com
Delivered-To: eat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A810A130E17; Mon, 22 Oct 2018 04:46:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 RxAyYbtNCZWm; Mon, 22 Oct 2018 04:46:12 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 951EF130E30; Mon, 22 Oct 2018 04:46:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w9MBk12a024192; Mon, 22 Oct 2018 13:46:06 +0200 (CEST)
Received: from [192.168.217.102] (p54A6CA9F.dip0.t-ipconnect.de [84.166.202.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42dvqF2d44z1Bqf; Mon, 22 Oct 2018 13:46:01 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <92abc587-6657-dcad-1222-611d5e8b78af@free.fr>
Date: Mon, 22 Oct 2018 13:46:00 +0200
Cc: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Laurence Lundblade <lgl@island-resort.com>, "rats@ietf.org" <rats@ietf.org>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>, Guy Fedorkow <gfedorkow@juniper.net>, "Smith, Ned" <ned.smith@intel.com>, Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>, "eat@ietf.org" <eat@ietf.org>
X-Mao-Original-Outgoing-Id: 561901558.288903-8225da9f9962033a1f11862f6477cd0c
Content-Transfer-Encoding: quoted-printable
Message-Id: <BD635D3D-CE09-4FB0-85E1-50FD4B0444C2@tzi.org>
References: <5D773C02-5083-4B10-A705-782E28FD8ADB@island-resort.com> <f84515dd-2e1a-7e66-7c23-b16f8f425d2a@sit.fraunhofer.de> <D7E5069D.C2E65%carl@redhoundsoftware.com> <c72a3b6c-88f2-d452-96be-947a4be1d9c8@free.fr> <73EF502E-B68C-4106-8311-4897B4F2DF8C@qti.qualcomm.com> <b6c9ff4a-cc35-8175-3294-4e6ec366409f@sit.fraunhofer.de> <615BB1D3-29E3-468B-B988-84852F47742C@intel.com> <VI1PR0801MB211230882A5B0D594D66DCFDFAFD0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <71A01CDA-380F-4A57-B601-02F9A2699471@intel.com> <6f28e6a4-1930-84b2-1399-8aed75e3a6b4@sit.fraunhofer.de> <FB52EAA1-21F9-4792-B6A2-B58BBFBB53D6@island-resort.com> <BN7PR05MB4097DAA623B0F77573982910BAFF0@BN7PR05MB4097.namprd05.prod.outlook.com> <04976C31-F18C-4F99-847D-110641DCDE80@island-resort.com> <9c73f9b7-9129-c273-254e-465f92ab3650@sit.fraunhofer.de> <09818298-9FE1-430A-8045-A9A7E76ED64C@island-resort.com> <aaf49ef2-d161-aa9d-7b8a-fd852c5806c4@sit.fraunhofer.de> <92abc587-6657-dcad-1222-611d5e8b78af@free.fr>
To: Denis <denis.ietf@free.fr>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/3xpeA-Lt7aTtO7sCZnBcz1oGY7g>
Subject: Re: [EAT] Device Identity (was Re: [EXTERNAL] Re: [Rats] Attestation BoF charter updates?)
X-BeenThere: eat@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EAT - Entity Attestation Token <eat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eat>, <mailto:eat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eat/>
List-Post: <mailto:eat@ietf.org>
List-Help: <mailto:eat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eat>, <mailto:eat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Oct 2018 11:46:22 -0000

On Oct 22, 2018, at 12:01, Denis <denis.ietf@free.fr> wrote:
> 
> The wording "identity document" should not be used in the charter, since the most important characteristic when using attestations is to be able to know 
> the characteristics of a device, i.e. that it operates as expected, does what is required and does not do other (bad) things. Knowing the identity of a device 
> (e.g. the name of its manufacturer and a unique serial number given by that manufacturer) may certainly be useful in some cases, but it is not always necessary, 
> nor desirable (e.g. because of privacy issues).

Henk forecasted that I would say “the usual identity confusion” earlier…

This is indeed the usual identity confusion.

RFC 4949 says:

   $ identity
      (I) The collective aspect of a set of attribute values (i.e., a
      set of characteristics) by which a system user or other system
      entity is recognizable or known. (See: authenticate, registration.
      Compare: identifier.)

In other words: A set of claims.

When I buy cigarettes from a vending machine in Germany (I don’t, so please excuse inaccuracies), it needs an identity document with exactly one claim on it:  age ≥ 18 years.  For a cash buyer, that is the entire identity the vending machine cares about.  (Obviously, the asserter of that claim needs to be authorized to do so by the operator of a vending machine — that set of authorizations is probably something that is honed by a procession of court cases.)

Since even the identity of the entity authorized to make a claim may be subject to privacy, the actual identity may be mixed together through a number of verification services.  It is useful to have a protocol that can be used to convey identities through such a mixer; the actual relying party may not need to understand much about what is happening as long as it trusts the verification services.  Or, in the above example, the vending machine may use a claim from a bank card that I’m ≥ 18yo, without understanding how the bank came to that conclusion.

Maybe we should replace the term “identity” with “set of claims useful for recognizing something or somebody”, hmm, SOCUFRSOS?  “Identity” might be easier to say.

I’m not sure I understand the part about SEQUENCE — I don’t see any (ordered) sequences in the rest of your message.
What I do see is claims that have different kinds; and that is of course important.  It is also sometimes important that we can have multiple claims of the same kind, something that JWTs are not very good at yet (we could fix that in CWT).

Grüße, Carsten