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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Wed, 27 November 2019 12:09 UTC

Return-Path: <kathleen.moriarty.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 9FEF812088D for <rats@ietfa.amsl.com>; Wed, 27 Nov 2019 04:09:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 sU7SRdBeeO_O for <rats@ietfa.amsl.com>; Wed, 27 Nov 2019 04:09:24 -0800 (PST)
Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 C0D87120113 for <rats@ietf.org>; Wed, 27 Nov 2019 04:09:24 -0800 (PST)
Received: by mail-oi1-x236.google.com with SMTP id o12so19829245oic.9 for <rats@ietf.org>; Wed, 27 Nov 2019 04:09:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jcTJ1ceVO2nkNd3ytR95RAsmtOWmDtuNuOtN6LT3dB4=; b=sSIjQGBMU43RJhKxa9V4K2ORNlUEo/SAK+9EQCZN4sUocuNM+wYuUOQhC1bS6UK9+P fMmnbsat8ccsbi4Bn+RR0BmovYpSyn4UAYnZPSJ0+nuN1DYHjz1+hT4nW8SaEaWcMRBG Uzm4eusAqQRZEkD67bUOUkVJc5spm9B6zyFbiQbGzr18M4fD7ZCUqQMtun8BVmGZ8omh kSCjwk7irGXD50pXtdym4bpY2hWx3h+GqSHWKPYHdXIvp/g401qYTilW0LiNB5XV6HsZ wilON5ZdyMBx795YZFabpqikvg9fnAZnD190BqAndZ2+aF2yArqKFBL7oQX7kUzaZcYz o0cg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jcTJ1ceVO2nkNd3ytR95RAsmtOWmDtuNuOtN6LT3dB4=; b=tx40iHCRyYdf1cn4oG2VPE10p5Z2KAos3h+nS825kubDawpUXapIOMUJUmtGgSs0gg FtgP7wWu+6jDrW8k1m4nJmtrEwCsbXUPJD/invrO5L0Qz3M9YIBEDf7lr9LTyFrZVN5R 87l6ytOgYRlNPr4+vbask/ZygkzVZXcMQXM8Ry4ZomOxjrX4ZWYtFmXhi/ZExVDn1SLk KvLfgLpH9x0dSNNFFiK5z2OkA/bnwRattW9a1LaZZTJjfocjkpo9/Zz8aRirlmR00FS+ Pi9DiK47X/orcYOfVPJNZZiYB67ooy44IM+PsqwTcx8J831IqZvzCkF6ifpK2SaSmCA+ +/tA==
X-Gm-Message-State: APjAAAVOexz744vkNPDpvNbFcscuImp3ukWqJxfefMsLyZKfhSwZ7hXl CIgtihXU1fnn9WP9o02H0f5bGG2WP9o4mvBE9oE=
X-Google-Smtp-Source: APXvYqxtof3Q4CLES8rKXoOSLPgW6dHgnqUApkp/tYZPIYK78tTA+cbfjqy1XvXXz5quMSm6FkYpnvy48iVSDoPOJR0=
X-Received: by 2002:aca:75cb:: with SMTP id q194mr3887278oic.158.1574856564098; Wed, 27 Nov 2019 04:09:24 -0800 (PST)
MIME-Version: 1.0
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>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Wed, 27 Nov 2019 07:08:48 -0500
Message-ID: <CAHbuEH7pVskERzbRBD+cmEozvOsQ2MmKn7UBsScsFMrRbhApHQ@mail.gmail.com>
To: Laurence Lundblade <lgl@island-resort.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, Yaron Sheffer <yaronf.ietf@gmail.com>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, "rats@ietf.org" <rats@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000134c03059852def3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/SmzNpo5683SUFBYdKT4Bjqxd9UA>
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 12:09:27 -0000

On Tue, Nov 26, 2019 at 11:39 PM Laurence Lundblade <lgl@island-resort.com>
wrote:

>
> 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.
>

One registry might become large, but it sounds like it will be easier and
reuse may happen on occassion.

To Yaron's earlier question, you can use claims that have not been
registered as the requirement to figure out vendor specific claims was
discussed and agreed as important at a previous interim for RATS.  If I
remember correctly, this was not done the same between JWT and CWT and that
was the issue to figure out.

Best regards,
Kathleen


>
> LL
>
>
>
>
>
>
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
>


-- 

Best regards,
Kathleen