Re: [Rats] [EXTERNAL] Re: EAT IANA registry

Laurence Lundblade <lgl@island-resort.com> Wed, 27 November 2019 04:39 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 F01B7120B5C for <rats@ietfa.amsl.com>; Tue, 26 Nov 2019 20:39:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 D6tUejI2M89u for <rats@ietfa.amsl.com>; Tue, 26 Nov 2019 20:39:25 -0800 (PST)
Received: from p3plsmtpa09-07.prod.phx3.secureserver.net (p3plsmtpa09-07.prod.phx3.secureserver.net [173.201.193.236]) (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 5D506120B5B for <rats@ietf.org>; Tue, 26 Nov 2019 20:39:25 -0800 (PST)
Received: from [10.86.0.34] ([45.56.150.43]) by :SMTPAUTH: with ESMTPA id Zp6pissvoyTItZp6piFXAe; Tue, 26 Nov 2019 21:39:24 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <CFF55BD3-66F8-485A-9AF5-1DD38B5F444C@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AADB0005-31EB-4DF1-9BCA-66172BB9226B"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 26 Nov 2019 20:39:23 -0800
In-Reply-To: <20191127031910.GF32847@mit.edu>
Cc: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, Yaron Sheffer <yaronf.ietf@gmail.com>, "rats@ietf.org" <rats@ietf.org>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: Benjamin Kaduk <kaduk@mit.edu>
References: <D2CF9D31-057E-4B47-A3D0-08BBBF997F47@gmail.com> <VI1PR08MB53605A2A2E61E6EAE2609FECFA490@VI1PR08MB5360.eurprd08.prod.outlook.com> <09C4F36B-C9CE-44DF-9DF8-F3365A7E3053@gmail.com> <53C13986-A523-4349-BDC3-F8ACC2BCFD29@island-resort.com> <DM6PR00MB05697456BC04AC34B156850DF54B0@DM6PR00MB0569.namprd00.prod.outlook.com> <20191127031910.GF32847@mit.edu>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfLC4MnbfgneBQc4xyELujVsa+4/0O2R0M9X4qi3uwdeQmQqGIoHXEa56o7RXCOvJ6S7NvUA0dRImE7FfQuplD6oqg/u9hDHUvIOOKVhD0X4KdD7dc5bW dARIky01zM03o3zXNEh78DFtXaQ5WgXBSFVjLvUwYJC8G2ZMy5K0j9UVN5DQ8U7bOHTw5Rqyz3cti6EwwcHxRIEKyOOZEhzgyItQLtlbz9GpFDpKSt/eiQQA V/ljOZyYyKbV8/sLTDNReGnzmtt5393pfLNeLL52Nuc0r/0QSKb+dPps3PpEOebeHHD+Pr7/b7YQJUMOUNGL6A==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/jbh05qKk06s_SH8rsbmUgsX_7PI>
Subject: Re: [Rats] [EXTERNAL] Re: EAT IANA registry
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, 27 Nov 2019 04:39:27 -0000

> On Nov 26, 2019, at 7:19 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> ...but I'm not sure that "avoiding duplicates"
> would apply to a proposal that makes a single JWT/CWT claim for "EAT data"
> and puts the attestation claims in a map as the value for that "EAT data"
> claim.  What existing JWT/CWT claims would duplicate the potential contents
> of the EAT data fields?

That is an interesting thought — put all of EAT into one JWT/CWT claim that is a map. Other’s have mentioned it to me. It would let EAT re use the most compact integer CBOR integer labels.

Right now we re use the following claims from JWT or CWT by normative reference:
- nonce
- Token ID cti/jti
- Time stamp (iat)

Also these JWT or CWT seem either likely or possible use in EAT:
- cnf (proof of possession of key)
- iss Issuer
- expiration
- not before

That’s a fairly large overlap which makes me disinclined to putting all of EAT into one map that is one JWT/CWT claim, separating EAT claims from CWT/JWT claims.

I’m no OAuth expert, but I wonder if some of the EAT claims might be useful for other than EAT tokens, another reason not to keep them separate.

I suspect we’re going to find at least one more use for a signed map of label-value pairs in the next few years that would be able to re use at least some of these claims — another reason to keep them in the same space.

LL