Re: [Rats] =?UTF-8?B?562U5aSN?=: =?UTF-8?B?IOetlOWkjQ==?=: use case document updates on Roots of Trust

Carl Wallace <carl@redhoundsoftware.com> Tue, 17 September 2019 02:36 UTC

Return-Path: <carl@redhoundsoftware.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 06E6912001E for <rats@ietfa.amsl.com>; Mon, 16 Sep 2019 19:36:37 -0700 (PDT)
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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 K80XEv1kyGxG for <rats@ietfa.amsl.com>; Mon, 16 Sep 2019 19:36:34 -0700 (PDT)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 502F0120018 for <rats@ietf.org>; Mon, 16 Sep 2019 19:36:34 -0700 (PDT)
Received: by mail-qt1-x834.google.com with SMTP id d2so2504221qtr.4 for <rats@ietf.org>; Mon, 16 Sep 2019 19:36:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version:content-transfer-encoding; bh=ZbSF48NFbTXN6s/mNqy7z3LyB7cX7yajCulx211F6mA=; b=rzmv0MWhJFM0AQICgWMxA1OPLkUj/Ll6kazJHO8OuD2ZSUbFSf6NQKbW05yLgfbhJN rxjsBOyzXWRP840rFpvbX5jFphRJX9KfRiWz2WEotFVp47CSVNmqFMi6rhOv5JxHg1LC X3vYlI8wP+ZKAATVVvi3Vlpt2jQBorc1pH2Sw=
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:mime-version:content-transfer-encoding; bh=ZbSF48NFbTXN6s/mNqy7z3LyB7cX7yajCulx211F6mA=; b=JcCZyZrM2qw4kor02wqLCTzb+ZW3l9cKhHIGOctakjPtgWfDexZolhKNPh+UAdtdIs JsBFdY8+WM1+JmgR/ps9YFx7n6eT3JvqmfSWtYv1FR+ww6b7L1ZnOeEuwRV04ee6DnPy hFasnltKN8TWhWZW5hhUrQuvt6NQ4Bu1J4eL7J9nl2JBQV3sW0OMmTHdOPVT1NFTJDfW rl/mzup8WUAmXCt83lhgvIj6dHhvLIIBELNCxO81UggSyiIEFQU59cifxUauyIl12Ghs 0T3TjxLXNXmxuT9DahYHta/hZUFK95jdMWzqltvQui68Kb+D5Wkjy4OfG6PVFD/OwUhb 1Xzw==
X-Gm-Message-State: APjAAAWrwn10QJpCL1htV666hruoOg1ZZLvdfagMhiNWErvqifTPbeE+ Jh0hHti96kCsg5cJ+xBHS9gm/g==
X-Google-Smtp-Source: APXvYqwV/0ZvIGn0tP4vDt/5Ms+sCQw6+I5ELlidGBQZOVRFY+R0LDNUGy6eYXKjMxlCnU2sFB4aOA==
X-Received: by 2002:ac8:16e2:: with SMTP id y31mr1532778qtk.370.1568687793289; Mon, 16 Sep 2019 19:36:33 -0700 (PDT)
Received: from [192.168.1.180] (pool-96-255-231-27.washdc.fios.verizon.net. [96.255.231.27]) by smtp.googlemail.com with ESMTPSA id g3sm409659qkb.117.2019.09.16.19.36.25 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 16 Sep 2019 19:36:32 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.7.6.170621
Date: Mon, 16 Sep 2019 22:36:21 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>
CC: Laurence Lundblade <lgl@island-resort.com>, "Salz, Rich" <rsalz@akamai.com>, Michael Richardson <mcr+ietf@sandelman.ca>, "rats@ietf.org" <rats@ietf.org>
Message-ID: <D9A5BCFC.EB494%carl@redhoundsoftware.com>
Thread-Topic: 答复: 答复: [Rats] use case document updates on Roots of Trust
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/COqk5FBnWi2RS-8vbHrGboY-V7w>
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: Tue, 17 Sep 2019 02:36:37 -0000

TAMP messages are an example. But any signature could apply, whether a
public key is a trust anchor or not is not up to the verifier.

On 9/16/19, 10:21 PM, "Xialiang (Frank, Network Standard & Patent Dept)"
<frank.xialiang@huawei.com> wrote:

>Can you give some other examples?
>
>-----邮件原件-----
>发件人: Carl Wallace [mailto:carl@redhoundsoftware.com]
>发送时间: 2019年9月17日 10:19
>收件人: Xialiang (Frank, Network Standard & Patent Dept)
><frank.xialiang@huawei.com>
>抄送: Laurence Lundblade <lgl@island-resort.com>; Salz, Rich
><rsalz@akamai.com>; Michael Richardson <mcr+ietf@sandelman.ca>;
>rats@ietf.org
>主题: Re: 答复: [Rats] use case document updates on Roots of Trust
>
>The definition of a trust anchor does not limit the scope to certificate
>chains. 
>
>> On Sep 16, 2019, at 8:51 PM, Xialiang (Frank, Network Standard & Patent
>>Dept) <frank.xialiang@huawei.com> wrote:
>> 
>> Hi Carl,
>> The other big difference between them is the object they deal with: RoT
>>is for integrity measurement value chain, CA is for certificate chain.
>> 
>> Hope it is helpful.
>> 
>> B.R.
>> Frank
>> 
>> -----邮件原件-----
>> 发件人: RATS [mailto:rats-bounces@ietf.org] 代表 Carl Wallace
>> 发送时间: 2019年9月16日 20:26
>> 收件人: Laurence Lundblade <lgl@island-resort.com>; Salz, Rich
>> <rsalz@akamai.com>
>> 抄送: Michael Richardson <mcr+ietf@sandelman.ca>; rats@ietf.org
>> 主题: Re: [Rats] use case document updates on Roots of Trust
>> 
>> I took Rich's statement to be more from a relying party perspective and
>>your detail to be more what one might find in a policy describing nature
>>of the root of trust, which is not that different from how one may
>>describe a trust anchor/CA in a PKIX context in a policy that describes
>>how a CA are operated, etc. Two sides of the same coin.
>> 
>> On 9/15/19, 4:50 PM, "RATS on behalf of Laurence Lundblade"
>> <rats-bounces@ietf.org on behalf of lgl@island-resort.com> wrote:
>> 
>>>> On Sep 12, 2019, at 3:31 PM, 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
>>> 
>>> This is not how I understand a root of trust, nor how I think it is
>>> generally used in the TCG or TEE worlds. I think a root of trust
>>> involves a CPU, memory and SW that actively does something like boot
>>> and measure a device. There is usually a boundary around it so that
>>> other software on the device, like the high-level OS, can’t corrupt it.
>>> When it is doing reporting as in RATS it will have a private key that
>>>can do some signing.
>>> When it is doing trusted/secure boot, it will also have a public key
>>> to verify the software it loads.
>>> 
>>> LL
>>> 
>>> 
>>> _______________________________________________
>>> RATS mailing list
>>> RATS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rats
>> 
>> 
>> _______________________________________________
>> RATS mailing list
>> RATS@ietf.org
>> https://www.ietf.org/mailman/listinfo/rats