IETF Logo Mail Archive

Re: [Rats] Verifier Input instead of Endorsement?

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 04 July 2020 23:18 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 A3F093A11DB for <rats@ietfa.amsl.com>; Sat, 4 Jul 2020 16:18:32 -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 FzpFgUYhGvBo for <rats@ietfa.amsl.com>; Sat, 4 Jul 2020 16:18:31 -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 0394B3A11DA for <rats@ietf.org>; Sat, 4 Jul 2020 16:18:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D2428389BC; Sat, 4 Jul 2020 19:15:38 -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 5vXZ1nV3XUsO; Sat, 4 Jul 2020 19:15:38 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1DE74389BB; Sat, 4 Jul 2020 19:15:38 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BFEB964F; Sat, 4 Jul 2020 19:18:28 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Laurence Lundblade <lgl@island-resort.com>, "rats@ietf.org" <rats@ietf.org>
In-Reply-To: <6091010E-3F7D-4B45-9B8E-9D954CE03C43@island-resort.com>
References: <878E068C-DAFD-4441-94F7-BA79CAF7FED6@island-resort.com> <BL0PR2101MB10279501A4ECA5BB7B6AED63A36F0@BL0PR2101MB1027.namprd21.prod.outlook.com> <BF5071AC-0C8D-4B26-8330-8589736B6EF5@island-resort.com> <af8e64b9-41b3-f42a-183d-1c9544fc1d7d@sit.fraunhofer.de> <C4D6DCB6-F0D9-4858-823C-7B045005B48C@island-resort.com> <13132.1593723461@localhost> <6091010E-3F7D-4B45-9B8E-9D954CE03C43@island-resort.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, 04 Jul 2020 19:18:28 -0400
Message-ID: <24201.1593904708@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/Y3oLzDucq2LSwIz5cyjryWS54Ps>
Subject: Re: [Rats] Verifier Input instead of Endorsement?
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, 04 Jul 2020 23:18:33 -0000

Laurence Lundblade <lgl@island-resort.com> wrote:
    >> Laurence Lundblade <lgl@island-resort.com> wrote:
    >>> The problem with Endorser is that they produce Endorsements and I think there are problems with Endorsements:
    >>
    >>> - In Berlin you told me they don’t have keys in them. So then how do
    >>> keys get into the Verifier?
    >>
    >> Well, first, I thought we agreed that the arcs above Verifier were out of
    >> scope for the architecture.  The WG might recharter to include that, but I
    >> thought we agreed that the concerns were seperable.  HOWEVER...

    > If that’s the approach, then Endorsements should be removed from the
    > document, both in the text and diagram.

That makes no sense to me.

It is perfectly reasonable to define something just well enough in order to make it
clear what is out of scope for standardization.

We can come up with many different ways to standardize Endorsements (or
Verifier Inputs), and it shouldn't matter at all to the protocol between
Attester and Verifier.

That's what makes it seperable.
Do you agree?

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

v2.23.0 | Report a Bug | By Email