Re: [Rats] use case document updates on Roots of Trust

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 16 September 2019 16:59 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 4778612012C for <rats@ietfa.amsl.com>; Mon, 16 Sep 2019 09:59:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 pK0-YsqhNTqc for <rats@ietfa.amsl.com>; Mon, 16 Sep 2019 09:59:55 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CAAE120072 for <rats@ietf.org>; Mon, 16 Sep 2019 09:59:55 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7639D38983; Mon, 16 Sep 2019 12:58:15 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 98F2F71B; Mon, 16 Sep 2019 12:59:53 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Salz, Rich" <rsalz@akamai.com>
cc: "rats@ietf.org" <rats@ietf.org>
In-Reply-To: <92137679-7DEA-42AD-B8D1-F3B909C77459@akamai.com>
References: <4155.1567948986@dooku.sandelman.ca> <64BD12AA-951A-468A-9F08-D442054605AD@island-resort.com> <de6ff852-062d-805d-3eed-10aca60502b2@sit.fraunhofer.de> <CAN40gStH5jUCJeVggREr3ABoFw7K97F=KtoJOSR_X+LWNLB+JA@mail.gmail.com> <CAN40gSu13DKkyahHA3_Cbt5j7Gsh=uGh5ic7fS3AvDGP3K1cug@mail.gmail.com> <5276.1568315351@dooku.sandelman.ca> <92137679-7DEA-42AD-B8D1-F3B909C77459@akamai.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Mon, 16 Sep 2019 12:59:53 -0400
Message-ID: <21587.1568653193@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/I8IGbag0xMoVJghkXL-6AWvarjE>
Subject: Re: [Rats] use case document updates on Roots of Trust
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: Mon, 16 Sep 2019 16:59:58 -0000

Salz, Rich <rsalz@akamai.com> wrote:
    > I do not see a meaningful difference between "trust anchor" and "trust
    > root" and "root(s) of trust."  All of them:

    > - Are pieces of data (certificate or key is not meaningful)
    > - Used to verify something such as a certificate or signature
    > - Are trusted by the application, based on actions that are "out of
    > band" of the application itself

That's because the term "root of trust" as used by attestation people are
very confusing.  And it's precisely your confusion that I would like to avoid.

** A root of trust is a piece of code that measures itself, because nothing
** before it can do that. (It might be the first piece of code to run).

While it is true that a trust anchor (in the form of a self-signed
certificate) comes with a similar kind of circular/implicit trust, the
measurement made by the root of trust code can actually be attested to by a
third party, and this is typically done.

The trust anchor used by a relying party to verify this attestation may also
come with implicit trust, the verification of the measurement made by the
root of trust does not.

I think that terms RoT Storage/etc. are even more confusing.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-