[Rats] how does the Verifier work

Michael Richardson <mcr@sandelman.ca> Fri, 05 February 2021 21:31 UTC

Return-Path: <mcr@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 3BF293A0B60 for <rats@ietfa.amsl.com>; Fri, 5 Feb 2021 13:31:44 -0800 (PST)
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 o4LR-k78j-LK for <rats@ietfa.amsl.com>; Fri, 5 Feb 2021 13:31:42 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C943A0B8F for <rats@ietf.org>; Fri, 5 Feb 2021 13:31:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9F5533899E for <rats@ietf.org>; Fri, 5 Feb 2021 16:34:38 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id aim047_9c8SE for <rats@ietf.org>; Fri, 5 Feb 2021 16:34:37 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9123E38999 for <rats@ietf.org>; Fri, 5 Feb 2021 16:34:37 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 24923430 for <rats@ietf.org>; Fri, 5 Feb 2021 16:31:37 -0500 (EST)
From: Michael Richardson <mcr@sandelman.ca>
To: rats@ietf.org
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: Fri, 05 Feb 2021 16:31:37 -0500
Message-ID: <31999.1612560697@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/t2OCsfwQ5ivPScqgO2mN0nlGvL8>
Subject: [Rats] how does the Verifier work
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: Fri, 05 Feb 2021 21:31:44 -0000

In issue https://github.com/ietf-rats-wg/architecture/issues/210
and in quite a number of discussions in the design team, we ratholed on
whether or not we were specifiying a normative description of how verifiers
worked.

In the architecture document we want to specify what goes in to the Verifier
(from the Attester direction!), and what goes out of the Verifier (to the
Replying Party only).
https://www.ietf.org/archive/id/draft-ietf-rats-architecture-09.html#dataflow

We did not want to specify the other arcs (Endorsements, Appraisal Policy for
Verifiers), but we did need to place some requirements on what was possible.

For instance, that Evidence would be signed, and that Verifiers could verify
the signature on it.

The large X diagram at:
  https://www.ietf.org/archive/id/draft-ietf-rats-architecture-09.html#name-claims-encoding-formats

which in many ways started the entire architecture document, remains an
intentional black box from this document.

It seems that there is a desire among some participants to more clearly
articulate how many (but perhaps not all) Verifiers work.  It seems that with
an appropriate initial narrow scope that such a document could be written by
the IETF.   For pretty much all the cases of "perhaps not all", then it is
probably the case that the specifics will be very specific to a vertical, and
should be written in that technical consortium outside of the IETF.

This email is basically the concluding recommendation of the design team: we
aren't going to put this into the architecture document, but we don't object
if someone else wants to write _Architecture of common Verifiers_, or some
equivalently titled document.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [