[Rats] should base architecture mandate a distributed structure for Endorsements

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 01 August 2020 15:49 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 2700C3A0C64 for <rats@ietfa.amsl.com>; Sat, 1 Aug 2020 08:49:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZhHDN4AGi02M for <rats@ietfa.amsl.com>; Sat, 1 Aug 2020 08:48:58 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14D743A0C68 for <rats@ietf.org>; Sat, 1 Aug 2020 08:48:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2E7D9389B4 for <rats@ietf.org>; Sat, 1 Aug 2020 11:28:19 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4ednF_0cbmEJ for <rats@ietf.org>; Sat, 1 Aug 2020 11:28:17 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C0D6D389B3 for <rats@ietf.org>; Sat, 1 Aug 2020 11:28:16 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 25F4C9A for <rats@ietf.org>; Sat, 1 Aug 2020 11:48:52 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: rats@ietf.org
In-Reply-To: <MWHPR11MB1439D21DA4B20ABCC97214F2E5720@MWHPR11MB1439.namprd11.prod.outlook.com>
References: <B1E7A6D0-4A08-494F-A065-9D1025A4E209@island-resort.com> <4445014C-A191-4885-BE67-5502EF3E551F@intel.com>, <413326C7-E1BA-43A1-BAD0-015AC0B5AD0F@island-resort.com> <MWHPR11MB1439D21DA4B20ABCC97214F2E5720@MWHPR11MB1439.namprd11.prod.outlook.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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-sha512; protocol="application/pgp-signature"
Date: Sat, 01 Aug 2020 11:48:52 -0400
Message-ID: <2900.1596296932@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/4RDlF4rGa2TcsCP5uGZ3IZhTCA0>
Subject: [Rats] should base architecture mandate a distributed structure for Endorsements
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: Sat, 01 Aug 2020 15:49:01 -0000

There is some discussion in private, on github and in the architecture DT
calls around the question of Endorsements.

There is a pull request at:
   https://github.com/ietf-rats-wg/architecture/pull/94
text.  The text is
   https://github.com/ietf-rats-wg/architecture/pull/94/files,
and I suggest that new readers go to the three dots and unselect "Show comments"

But, I include the text:

  - An Endorsement is a secure statement that some entity (e.g., a
  - manufacturer) vouches for the integrity of the
  - device's signing capability.  For example, if the signing capability is in hardware, then
  - an Endorsement might be a manufacturer certificate that signs a public key whose corresponding
  - private key is only known inside the device's hardware.

  + An Endorsement input to a Verifier is always required. An Endorsement is
  + what allows a Verifier to trust an Attester and in turn to trust the Evidence
  + produced by an Attester. Without Endorsements a Verifier cannot function.
  + Said another way, an Attester for which there is no Endorsement is not
  + useful since there is no good basis by which a Verifier can trust it.

  + One of the Endorsements for an Attester will just about always contain
  + cryptographic key material.
  + This key material will correspond to key material that is put in the Attester.
  + The key material is the basis for the Verifier trusting the Attester.
  + This architecture does not dictate any particular cryptographic protocol
  + for establishing this trust, hence the key material can be symmetric or
  + asymmetric, a single key, multiple keys, key hierarchies, X.509 cert or
  + chains or other.

I think that we get into conflict immediately on the first sentence.

There ARE many use cases in which we WILL need input to the
Verifier from a variety of manufacturers in a signed artifact form.(A)

There are other use cases in which the Verifier will be configured with all
the information that it needs.  Is a configuration file, loaded by a trusted
operator, a "secure statement"?
I think so, and this is why we used this wording. (B)

When I read the changes above, it seems to me that it contains aspirational
text that intends to make case (A) universal.

I think that a number of us believe that an Endorsement is the name for a
signed artifact.  This may be the basis for our disagreement: I'm not entirely sure.
Our definition of "Endorsement" does not say that, so it may be that I read
too much into the proposed changes.

I firmly believe that we will need an Architecture for Distributed Endorsements.
I also think that we can do this separately, and that there are probably
reasons for some industrial verticals to do this on their own.

It could be that this is not the goal of the above text.

I do not think we need this level of detail in this part of the architecture.
It's not wrong, it's just not helpful, I think.

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