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

Benjamin Kaduk <kaduk@mit.edu> Fri, 26 October 2018 15:07 UTC

Return-Path: <kaduk@mit.edu>
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 F1CCC130DF4; Fri, 26 Oct 2018 08:07:52 -0700 (PDT)
X-Quarantine-ID: <NTSm2wVzyB8h>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 NTSm2wVzyB8h; Fri, 26 Oct 2018 08:07:51 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 C04C8127332; Fri, 26 Oct 2018 08:07:50 -0700 (PDT)
X-AuditID: 1209190f-a3dff70000000158-28-5bd32dc4da8d
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id C4.10.00344.5CD23DB5; Fri, 26 Oct 2018 11:07:49 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.14.7/8.9.2) with ESMTP id w9QF5RBh010190; Fri, 26 Oct 2018 11:05:29 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id w9QF5LSn012837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Oct 2018 11:05:24 -0400
Date: Fri, 26 Oct 2018 10:05:21 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Laurence Lundblade <lgl@island-resort.com>
Cc: "Eric Voit (evoit)" <evoit@cisco.com>, "Jeremy O'Donoghue" <jodonogh@qti.qualcomm.com>, "eat@ietf.org" <eat@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, Carl Wallace <carl@redhoundsoftware.com>, "rats@ietf.org" <rats@ietf.org>, "Smith, Ned" <ned.smith@intel.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <20181026150521.GM45914@kduck.kaduk.org>
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> <4B026885-9349-412C-8E47-A71BB866EDCC@island-resort.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4B026885-9349-412C-8E47-A71BB866EDCC@island-resort.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMKsWRmVeSWpSXmKPExsUixG6nontU93K0waPLyharF29isvjZt5fZ 4sXq1UwWDf/+slq0XzjAYvHjzEMmi55D/ewWJ3ecZ7VYtnwXuwOnx5TfG1k9liz5yeSxeM9L Jo+jy8s8Fk19xuixb8Zudo+WOXuYPToe3GAM4IjisklJzcksSy3St0vgyjiyaBtbwR6xiq27 DjI2MP4T7GLk5JAQMJFY1reYuYuRi0NIYA2TxKtlH1ghnI2MEj8Xr4dy7jJJbN37hx2khUVA VaLv9S02EJtNQEWiofsyUDsHh4iAnsTuPj6QemaB30wS5xu7wWqEBcIkdn3/wgpi8wKtW3Cj DWyOkMADZonfbVwQcUGJkzOfsIDYzALqEn/mXQKbySwgLbH8HwdEWF6ieetsZhCbU8BV4tzr P2AjRQWUJfb2HWKfwCg4C8mkWUgmzUKYNAvJpAWMLKsYZVNyq3RzEzNzilOTdYuTE/PyUot0 TfRyM0v0UlNKNzGC4opTkn8H45wG70OMAhyMSjy8E75djBZiTSwrrsw9xCjJwaQkyvtY43K0 EF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFeKxmgHG9KYmVValE+TEqag0VJnHdCy+JoIYH0xJLU 7NTUgtQimKwMB4eSBC8rMH0ICRalpqdWpGXmlCCkmTg4QYbzAA3/pAMyvLggMbc4Mx0if4pR UUqc1xIkIQCSyCjNg+sFpT2J7P01rxjFgV4R5vUGqeIBpky47ldAg5mABs9QuAAyuCQRISXV wOivdMxhyckuLYk/4tHM11YYpvYetPlsosrAdvqYV8y3tpZlxo/mCQtMz/c/dMhP977FXc4z /z4JinaH+XmsadfaqqyeVCYR17PIM/VK8WX/TXkXNh9vMSi8cGue7ddzpY4nHfYssjC/8faO 1+xnGxYt/Pvgh8uprUk7RFisdsU4Jvb2Oe5Wu6PEUpyRaKjFXFScCAASUldxVgMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/CLLsgi9pQ981lqA8EvVgBIybhvo>
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 15:07:53 -0000

On Fri, Oct 26, 2018 at 09:56:27PM +0700, Laurence Lundblade wrote:
> 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. 

I agree that the overall system design can include trusted elements feeding
information to the signer, in which case the decision about what gets
signed is made by the individual trusted elements and the signer itself
need not know the formats of the individual claims.  If that's the
architecture we want to use, we just need to be explicit about it.

-Ben