IETF Logo Mail Archive

Re: [Rats] Dealing with Attestation Roots

Laurence Lundblade <lgl@island-resort.com> Sun, 26 April 2020 19:35 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 C89753A0F6B for <rats@ietfa.amsl.com>; Sun, 26 Apr 2020 12:35:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.716
X-Spam-Level:
X-Spam-Status: No, score=-2.716 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 5O3e0RMxw0E9 for <rats@ietfa.amsl.com>; Sun, 26 Apr 2020 12:35:30 -0700 (PDT)
Received: from p3plsmtpa11-09.prod.phx3.secureserver.net (p3plsmtpa11-09.prod.phx3.secureserver.net [68.178.252.110]) (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 8810E3A0F6C for <rats@ietf.org>; Sun, 26 Apr 2020 12:35:30 -0700 (PDT)
Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id Sn3pjMe5YAH7jSn3pj2gXP; Sun, 26 Apr 2020 12:35:30 -0700
X-CMAE-Analysis: v=2.3 cv=YbzDGDZf c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=LfMD5_FKE7ujrVmnwTkA:9 a=Z8SXLZCkHBhyYdnq:21 a=qnao9o7MuypvPuO3:21 a=QEXdDO2ut3YA:10 a=Sdg63LF2uTc0LgqzOYkA:9 a=krBrgrtZv85E3sP6:21 a=m6tv8Tqb58I8cgzQ:21 a=fQp-Z9kRC3JnKVG6:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <22D8F1C3-63B1-4629-B0C0-A79884FB6DC1@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E8D4D633-7901-4665-9BDD-25D533D3185C"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 26 Apr 2020 12:35:28 -0700
In-Reply-To: <089B4CD9-64FD-491C-8E92-7235A11F9080@cisco.com>
Cc: Anders Rundgren <anders.rundgren.net@gmail.com>, "rats@ietf.org" <rats@ietf.org>
To: Eliot Lear <lear=40cisco.com@dmarc.ietf.org>
References: <49d8907c-7637-3d21-0619-4999565fc50e@gmail.com> <7C65B977-FA56-4118-BA8B-121BD9697F7C@island-resort.com> <d67985a1-97da-3e23-81e6-1b58b61e1d1a@gmail.com> <FE63538E-389A-4F07-B8DB-6B875D27C3D0@island-resort.com> <089577da-e46c-5f9c-ef08-30a325ea9cfc@gmail.com> <089B4CD9-64FD-491C-8E92-7235A11F9080@cisco.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfFyzKkZXbxBRe+qdjnvZVbhyPmR+Ek7pPXxpBhSybEyom5ltnQ/A6jSzdJh7Mvn/PK3yF56QvEecfp29pP+K7t1pKY9y23Z8g/mCtIg7f5mio+4UBwLJ 63FB3f7zdS1x0VxoDN9NJBWPWh/1npMD8utoyOHJQh48B0sboQw8GaDt6bi2pFYXmdQljQdWogx1EZaOV89EP1E0chWsQya6XrCwnAt4sDblAjxV04l7KDr6 PVFaUJm+ULNZEfQDg+jzJw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/S0WfUPWMo-_7_KGUEFWY4RF30Zk>
Subject: Re: [Rats] Dealing with Attestation Roots
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: Sun, 26 Apr 2020 19:35:32 -0000


> On Apr 24, 2020, at 12:16 AM, Eliot Lear <lear=40cisco.com@dmarc.ietf.org> wrote:
> 
> Hiya
> 
>> On 24 Apr 2020, at 05:31, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>> 
>>> The two EAT implementations I know of, use other means to find the verification key. One by key ID, another by a combination of claims inside the attestation.
>> 
>> Somewhere there must be a trust anchor or a trusted public key, right? How do you locate it expressed in practical terms?  
> 
> Yeah, “combination of claims inside the attestation”?  Isn’t that a self-assertion?
> 

By “claims inside the attestation” I don’t mean self-assertion. You use the claims inside the attestation to find the key. For example you use OEM ID to find the OEM of the device, then you use the UEID to find the specific key. Yes, you are using claims that are unverified to find the key, but that is OK. If you get the wrong key, nothing works anyway. COSE’s key id is unprotected.

Personally, I prefer to use the COSE kid or https://tools.ietf.org/html/draft-ietf-cose-x509-06 <https://tools.ietf.org/html/draft-ietf-cose-x509-06> because it keeps the SW stack cleaner, but there’s nothing insecure about using claims inside the attestation to look up the verification key. 

LL

v2.23.0 | Report a Bug | By Email