[Rats] Including public keys and such in EAT
Laurence Lundblade <lgl@island-resort.com> Tue, 10 November 2020 20:26 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 5910A3A0F2F for <rats@ietfa.amsl.com>; Tue, 10 Nov 2020 12:26:18 -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_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 Nw5XX5SskmLS for <rats@ietfa.amsl.com>; Tue, 10 Nov 2020 12:26:17 -0800 (PST)
Received: from p3plsmtpa06-10.prod.phx3.secureserver.net (p3plsmtpa06-10.prod.phx3.secureserver.net [173.201.192.111]) (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 2F6FF3A0F46 for <rats@ietf.org>; Tue, 10 Nov 2020 12:26:17 -0800 (PST)
Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id caDXk5uVBv00ycaDXkPv5G; Tue, 10 Nov 2020 13:26:16 -0700
X-CMAE-Analysis: v=2.4 cv=D9mCltdj c=1 sm=1 tr=0 ts=5faaf768 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=0XtbOteLAAAA:20 a=8aR-w2S99eIz54h-yaAA:9 a=QEXdDO2ut3YA:10 a=A1nNzoElW0jrY8uKxf4A:9 a=CzOnigSOsvp_Y1s_:21 a=_W_S_7VecoQA:10 a=WQnItmPV2fbdzLaCP6-h:22 a=Z5ABNNGmrOfJ6cZ5bIyy:22 a=bWyr8ysk75zN3GCy5bjg:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_854430EA-34E8-4FDA-9349-75F034590D1F"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Message-Id: <042DD4B4-5E22-4EFB-AF15-8697C34C7D44@island-resort.com>
Date: Tue, 10 Nov 2020 12:26:15 -0800
To: rats@ietf.org
X-Mailer: Apple Mail (2.3445.104.17)
X-CMAE-Envelope: MS4xfObLmfeUUSv+vhhyuVzg+Z6ChRg+0zIZXqSVcV2fKQEzxOpliuoLuehUO0xTpWqVcnIMdb5oZsB81YUFBOn/q53ImRE3NZFg4xXmoA41QX5DK0OkrOTB BGyuwJA3zJc6FdfcBRgxfwJavDaA621cv1n86dsLCUlxN06ZiBPDloSb2AYOEoGb7Fngg/ioVGVUWg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/AnQN-1CfcBSMkRQB7Odi2ShFFNs>
Subject: [Rats] Including public keys and such in EAT
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: Tue, 10 Nov 2020 20:26:18 -0000
I’m hoping for a lot of discussion and input on this PR <https://github.com/ietf-rats-wg/eat/pull/71> about the inclusion of keys in claims. Seems to me there are lots of use cases for key inclusion and they have semantics that vary too much to fit into one claim. I’ve chosen primarily to write guidelines rather than define claims. One use case is a CSR. However, RFC 8747 doesn’t define a CSR, so referencing it isn’t sufficient. Attestations from the Android key store include things like security level and user authentication requirements for use. Going into all that is too much for EAT, but might be good in another document. FIDO goes one step beyond Android and binds a relying party/user/device tuple with the key. It is a little tempting to define a security level for the storage and operation of keys since EAT has a security level definition. LL
- [Rats] Including public keys and such in EAT Laurence Lundblade