Re: [EAT] [Rats] Attestation BoF charter updates? - Program of Work section

Laurence Lundblade <lgl@island-resort.com> Fri, 26 October 2018 14:56 UTC

Return-Path: <lgl@island-resort.com>
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 E83BA130E10 for <eat@ietfa.amsl.com>; Fri, 26 Oct 2018 07:56:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 3DbYiuOdxtTn for <eat@ietfa.amsl.com>; Fri, 26 Oct 2018 07:56:33 -0700 (PDT)
Received: from p3plsmtpa09-02.prod.phx3.secureserver.net (p3plsmtpa09-02.prod.phx3.secureserver.net [173.201.193.231]) (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 536EC130E09 for <eat@ietf.org>; Fri, 26 Oct 2018 07:56:33 -0700 (PDT)
Received: from 2405-9800-ba10.44.pool1.tls1b-bcr02.myaisfibre.com ([184.22.80.254]) by :SMTPAUTH: with ESMTPSA id G3XHgUi4O0XzPG3XJgBw1U; Fri, 26 Oct 2018 07:56:32 -0700
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Laurence Lundblade <lgl@island-resort.com>
In-Reply-To: <20181026143033.GK45914@kduck.kaduk.org>
Date: Fri, 26 Oct 2018 21:56:27 +0700
Cc: "Eric Voit (evoit)" <evoit@cisco.com>, Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>, "eat@ietf.org" <eat@ietf.org>, "rats@ietf.org" <rats@ietf.org>, Carl Wallace <carl@redhoundsoftware.com>, Michael Richardson <mcr+ietf@sandelman.ca>, "Smith, Ned" <ned.smith@intel.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4B026885-9349-412C-8E47-A71BB866EDCC@island-resort.com>
References: <0199DB00-E76E-4664-BE02-E2AF4F4B6AEC@intel.com> <526BB5AC-60A8-4CD3-95F4-39F210E4D2FB@island-resort.com> <D7F73FD8.C4179%carl@redhoundsoftware.com> <662EFF28-BC29-4C1F-BB00-086D449D6F0A@island-resort.com> <D7F74EE1.C41A5%carl@redhoundsoftware.com> <AF8EF7CD-9024-4BD6-B6B7-03327F9EA0F9@intel.com> <4E928A1C-F207-4661-B176-0DADF12EF705@island-resort.com> <20181026143033.GK45914@kduck.kaduk.org>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: Apple Mail (2.3445.9.1)
X-CMAE-Envelope: MS4wfAS5sAcpFrE0WYDZA2Ykcstmw/KHcAhujTGqUgN8WPrw3BReysRXjTurTSYHmIQ0H2jquPYQfgOawA96bxFC0Mp7l6xSY7mhAoaPux6d5x1wfLzQ+h4q Bl+hgNWS7xuqbjyhdnZCT5ttFT+OUBJOBAZvzUqHeQBtEZlbNxQIrytsddMvwzpvzXINm56tve5WyjSBO2M03NGuni/+sNF/T1FUOdKzHDj0KrRv0QJIM+1n P30Ih+8qIea2MJLI6QxsYt/C8OT40nyonw484co03AFiYXkMgP8HwUtbVjbIag9TDvevD2NdroS7xfivbvliqjTHbz/G7Vnf0wzZtyQDRN3fPU3RijHrZLCu L/VcY9m2Us4CFd9UsJHeihHyv/3M7w9x7xhH9qGh3aTzvf6WZS3GG3LVBOgh393ajHKUy8aLgMcaxfjZSVwk/AKB3PFIoEhHvcdzVxGwusDmTwHKkv0=
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/70j3WhsXGXJlyDL6Xiv3qK_jAWM>
Subject: Re: [EAT] [Rats] Attestation BoF charter updates? - Program of Work section
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: Fri, 26 Oct 2018 14:56:35 -0000

See end...

> On Oct 26, 2018, at 9:30 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> On Fri, Oct 26, 2018 at 12:12:58PM +0700, Laurence Lundblade wrote:
>> (This isn’t really charter bashing anymore; think we’re mostly done with that)
>> 
>> I’ll put this in the form of a proposal:
>> 
>> A set of claims about a device is aggregated into a 'token' (this is the term used in CWT/JWT) or ‘document'. That token/document will be signed.  We will support only two formats for the token/document.
>> 
>> CWT: Claims are mainly in CBOR format, but we can stuff other things like commonly used ASN.1, XML, JSON...  structures into an individual claim if necessary. Signing is COSE format, though COSE headers might carry X.509 certs to help identify and chain up to the verification key.
>> 
>> JWT: Claims are mainly in JSON format, but we can stuff other things like commonly used ASN.1, XML, CBOR… structures into an individual claim if necessary. Signing is JOSE format, though JOSE headers might carry X.509 certs to help identify and chain up to the verification key.
> 
> There is perhaps something of a philosophical question about stuffing
> ASN.1, XML, etc. structures into individual claims, in that "can you really
> trust the signer to vouch for what it's signing if the signed contents are
> in a format unknown to the signer?"  There are certainly ways to delegate
> or chain trust so that the answer to the question is "yes", but I do not
> think we should ignore the question entirely.

I don’t think the format matters in this case. The basis for the signer trusting what it signs is not dependent on the format. Some one feeding bad data to the signer could just as well feed it in the format the signer typically uses.

What matters is the SW architecture and implementation on the device. In a simple set up the signer might be in the kernel and only sign data that also came from the kernel. Or it could be in TrustZone or an embedded Secure Element and only sign data that came from the same. In something more complicated the signer could be in the kernel and accept data from user mode processes, but mark it specially (this is what the submods claims is for in EAT).  The nonce from the relying party always comes from far away, but it is special and it doesn’t matter. If a MiTM changes the nonce, the relying party will know. 

LL