Re: [Rats] Use case -> architecture document

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 16 October 2019 14: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 86F861200FB for <rats@ietfa.amsl.com>; Wed, 16 Oct 2019 07:31:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.436
X-Spam-Level: *
X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 5SxSI7GM2dbW for <rats@ietfa.amsl.com>; Wed, 16 Oct 2019 07:31:11 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C710C12004C for <rats@ietf.org>; Wed, 16 Oct 2019 07:31:05 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [IPv6:2001:67c:64:42:5650:5f0a:e07a:7e5f]) by relay.sandelman.ca (Postfix) with ESMTPS id 04A8F1F455; Wed, 16 Oct 2019 14:31:04 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 7AD19E8B; Wed, 16 Oct 2019 16:31:57 +0200 (CEST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
cc: "rats@ietf.org" <rats@ietf.org>
In-reply-to: <CAHbuEH6vTuJ-GuYfeEvUXFaFT-DeGv-c9NAAYyDFBFPWWSfbJQ@mail.gmail.com>
References: <CAHbuEH7f0jjquR=iZDgof4DkgpZKgxEP86NcQ0A1NQ=SP+_FHA@mail.gmail.com> <C02846B1344F344EB4FAA6FA7AF481F13E9560C0@dggemm511-mbx.china.huawei.com> <CAHbuEH7WkqeyUW3sL5bdw5N25B6O7ZEF0Qkx03fE5c42Sd4M5w@mail.gmail.com> <b91baad2-2fc3-a5e4-6898-e2cddcda300d@sit.fraunhofer.de> <20191009145006.r2pjsoo6jxirah64@anna.jacobs.jacobs-university.de> <CAHbuEH6u-6GsJjK8s0eFQPLeSuGjPMgonhyQkmaeA6Q+rp42kA@mail.gmail.com> <9379d880-2b7e-6657-c547-b37bb7a9e466@sit.fraunhofer.de> <CAHbuEH7XfWgPT+=T-Za9Cw-5GRQj0_+WT3L+Kd4aPp6VvU9jAQ@mail.gmail.com> <MWHPR21MB078499E5D4A2A5E697924EC7A3900@MWHPR21MB0784.namprd21.prod.outlook.com> <20191015154500.ruv2ie36hsxfb3qq@anna.jacobs.jacobs-university.de> <18413.1571227622@dooku.sandelman.ca> <CAHbuEH6vTuJ-GuYfeEvUXFaFT-DeGv-c9NAAYyDFBFPWWSfbJQ@mail.gmail.com>
Comments: In-reply-to Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> message dated "Wed, 16 Oct 2019 10:18:08 -0400."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 16 Oct 2019 16:31:57 +0200
Message-ID: <13312.1571236317@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/mGGXy6He7ivfOlZwrBCmIhzqKj4>
Subject: Re: [Rats] Use case -> architecture document
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: Wed, 16 Oct 2019 14:31:13 -0000

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
    >> Schönwälder, Jürgen wrote:
    >> > Henk's architecture discusses 'Attestation Principles' that are not
    >> in
    >> > Dave's proposal. I guess the WG needs to decide whether to include
    >> them
    >> > or not. Are these important for understanding or guiding the RATS
    >> work?
    >>
    >> I think that, to the extent that the architecture document includes
    >> requirements on the technical document must answer, that these principles
    >> need to be made explicit.   They should be numbered as well so that we know
    >> which principle to compromise to maintain another one.

    > In a sense, Dave's document covers this idea as it does discuss the ability
    > for 2 functions to be combined.  I don't think adding a term is needed to
    > state that though and adding a specific term for that leads to
    > confusion.

I need the architecture document to introduce terms like "freshness" and "provenance"
and explain how they apply in an attestation context.  I need to know, if I
have to compromise one or the other to satisfy a particular use case, which
one is more important.

{I don't claim the other document does a great job at defining those terms, btw}

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