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

Benjamin Kaduk <kaduk@mit.edu> Fri, 26 October 2018 14:30 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 F2115130DF3; Fri, 26 Oct 2018 07:30:51 -0700 (PDT)
X-Quarantine-ID: <sCkxkNLXXnU0>
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 sCkxkNLXXnU0; Fri, 26 Oct 2018 07:30:50 -0700 (PDT)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 63D48130DEF; Fri, 26 Oct 2018 07:30:50 -0700 (PDT)
X-AuditID: 12074423-239ff7000000408f-49-5bd32516740f
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-6.mit.edu (Symantec Messaging Gateway) with SMTP id 7E.59.16527.71523DB5; Fri, 26 Oct 2018 10:30:48 -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 w9QEUeHg007444; Fri, 26 Oct 2018 10:30:42 -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 w9QEUXkn031526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Oct 2018 10:30:36 -0400
Date: Fri, 26 Oct 2018 09:30:33 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Laurence Lundblade <lgl@island-resort.com>
Cc: "Smith, Ned" <ned.smith@intel.com>, "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>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <20181026143033.GK45914@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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4E928A1C-F207-4661-B176-0DADF12EF705@island-resort.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEKsWRmVeSWpSXmKPExsUixG6noiuhejnaoH+pvMXqxZuYLH727WW2 eLF6NZNFw7+/rBbtFw6wWPw485DJoudQP7vFyR3nWS2WLd/F7sDpMeX3RlaPJUt+Mnks3vOS yePo8jKPRVOfMXrsm7Gb3aNlzh5mj44HNxgDOKK4bFJSczLLUov07RK4MtY/kS6YyF3xYBdb A2MTZxcjJ4eEgIlE+6obzF2MXBxCAmuYJCbN2s4G4WxklJg2dwUrhHOXSeLNjrtsIC0sAqoS E2acZwSx2QRUJBq6LwO1c3CICOhJ7O7jA6lnFvjEJLG+6yQrSI2wQJjEru9fwGxeoHX9278y Qgz9xSSx7fESqISgxMmZT1hAbGYBdYk/8y6BDWUWkJZY/o8DIiwv0bx1NjOIzSngKtHXsBes XFRAWWJv3yH2CYyCs5BMmoVk0iyESbOQTFrAyLKKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10wv N7NELzWldBMjOKpclHcwvuzzPsQowMGoxMMr8PdStBBrYllxZe4hRkkOJiVR3pcyl6OF+JLy UyozEosz4otKc1KLDzFKcDArifBageR4UxIrq1KL8mFS0hwsSuK8E1sWRwsJpCeWpGanphak FsFkZTg4lCR4zysDNQoWpaanVqRl5pQgpJk4OEGG8wANZ1YBGV5ckJhbnJkOkT/FqCglznsD pFkAJJFRmgfXC0p6Etn7a14xigO9IszrDdLOA0yYcN2vgAYzAQ2eoXABZHBJIkJKqoHRVUR6 iZTWOqtd4pmituUX229eEJk+5ZmrcINrxi9zR05NJ4+dOsnmIasPX4473GhdMj2lzsrhbuaZ 5ReYd2Xz1TG+i/LS43x+aeax1ZtMXE9ILNqdM+POouLbvze+X3zmyJdzckd1OPqOKtw8NOeF eon9pV5L533BM2rZHpg0zphzlYF7l8R0JZbijERDLeai4kQASuSb51UDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/ki17tYXbeey-OkjJJFaaLB_Py1g>
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:30:52 -0000

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.

-Ben