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

Yaron Sheffer <yaronf.ietf@gmail.com> Wed, 27 November 2019 15:53 UTC

Return-Path: <yaronf.ietf@gmail.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 BBD8B1209DF for <rats@ietfa.amsl.com>; Wed, 27 Nov 2019 07:53:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.642
X-Spam-Level:
X-Spam-Status: No, score=-0.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.355, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 IRYaH-gprbFx for <rats@ietfa.amsl.com>; Wed, 27 Nov 2019 07:53:36 -0800 (PST)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8558F1209DD for <rats@ietf.org>; Wed, 27 Nov 2019 07:53:36 -0800 (PST)
Received: by mail-wr1-x436.google.com with SMTP id i12so27338628wro.5 for <rats@ietf.org>; Wed, 27 Nov 2019 07:53:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=fA3qyOxW7LuJy6vdxA3kfkrIJpjALWVB+98gYJ01Hu8=; b=FsUrF1w+9GtamMOIgSG/p3a3YOmQd1NHqeGvD3PvqKL12CwBxIiIXYPC9g+TIPmCUp Iu38lcdb8Z5676aKzfH7w9WSTPLN6A9lO9AUTvxhgqPMT+j+bGtIFQhRNt4eu08Ha8dd hv1rb74b81KmXJjXLXrynfUWayNaWKL07dHgh1qeOOhdn2MkA1NC/DDzUg7bXrZkZvoE pv1k6JcoSs6khr+KSV0cRNdX3XC10xWFeQeG14cRpj8OZ+A+YRUks9O0AYNRJrdxg8vT YFU9p4hXqLe7lUisnOimFkwQ9C0B+iMYaSHBriodQ+ogt7+XhVV7BcdUOgnLa0z0XECE eLvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=fA3qyOxW7LuJy6vdxA3kfkrIJpjALWVB+98gYJ01Hu8=; b=OfkrZugJuGfJHbZToqULHmhZlnTPfX6omxF4W5LLarLcRy4vMVrhHUgwwwVT+kjUSj QjNHUPL+c+MyVWbpS/T/RFQrjumCIXJF2DMTvxkKt43NbyHZiTYYVbn+IFVB5TbDxZYW jxRt5ddkDA5IVGgaA8P1GaRtKpP4GqrE1cT048VaXqMwI+jMpcSazfYwpnuRRKG+c7yZ pdBb0ukdLQxmRZ1xjeL3RpKOIfMl4h6EqUYWd2TO5nodwvnIapHOlZSMb1ENSPBONDho ng4/vRi605HCRuJtn70t4VKyKw+Z0vHwc8j64mTcEfKUxNxPWmtpYenSGq3e+hizvSo3 AD3A==
X-Gm-Message-State: APjAAAWWXThNRIHRaGPon+nxNxtNbCacYM0sFAWOk+lFPpoVN6PQpKHO oVTI3jB+QOD7v05KJgUjKEs=
X-Google-Smtp-Source: APXvYqzWl8KSHKhdO5gL1JWxs3KV2StIdJp+3lTTZ9qQEj9HpSB8rzOpOSfWnPiFhHemGuN01kJ9AQ==
X-Received: by 2002:adf:cf0c:: with SMTP id o12mr42686480wrj.102.1574870014963; Wed, 27 Nov 2019 07:53:34 -0800 (PST)
Received: from [172.28.128.95] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id m16sm7210154wml.47.2019.11.27.07.53.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Nov 2019 07:53:33 -0800 (PST)
User-Agent: Microsoft-MacOutlook/10.1f.0.191110
Date: Wed, 27 Nov 2019 17:53:32 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: Laurence Lundblade <lgl@island-resort.com>, Benjamin Kaduk <kaduk@mit.edu>
CC: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, "rats@ietf.org" <rats@ietf.org>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Message-ID: <ECA98A18-0E4B-4C51-AFE4-FB84E61AC809@gmail.com>
Thread-Topic: [Rats] [EXTERNAL] Re: EAT IANA registry
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> <CFF55BD3-66F8-485A-9AF5-1DD38B5F444C@island-resort.com>
In-Reply-To: <CFF55BD3-66F8-485A-9AF5-1DD38B5F444C@island-resort.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3657722013_1448132465"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/OzTONYQCVCZay8F_c4k2T6snQKE>
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 15:53:39 -0000

To put it into perspective, there are already 57 claims registered [1]. So even if 7 claims overlap, this is a relatively *small* number. IMO there is high value in a separate namespace for EAT claims, and the standard way to create such a namespace in JSON is exactly as Ben is proposing.

 

Thanks,

                Yaron

 

[1] https://www.iana.org/assignments/jwt/jwt.xhtml

 

From: Laurence Lundblade <lgl@island-resort.com>
Date: Wednesday, November 27, 2019 at 06:39
To: Benjamin Kaduk <kaduk@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>
Subject: Re: [Rats] [EXTERNAL] Re: EAT IANA registry

 

 

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