Re: [Rats] Use case -> architecture document

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Wed, 16 October 2019 14:36 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.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 40B9E12093E for <rats@ietfa.amsl.com>; Wed, 16 Oct 2019 07:36:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 (2048-bit key) header.d=gmail.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 EW95fHaJwt89 for <rats@ietfa.amsl.com>; Wed, 16 Oct 2019 07:36:01 -0700 (PDT)
Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 99C4D1208B3 for <rats@ietf.org>; Wed, 16 Oct 2019 07:35:58 -0700 (PDT)
Received: by mail-ot1-x331.google.com with SMTP id 67so20340407oto.3 for <rats@ietf.org>; Wed, 16 Oct 2019 07:35:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0k8B8D44ZhNEpq2bojltVwtEE9x0UZtpZiH8OVqGUp0=; b=dran2QVdkH6jVscws/Ma3aLUrP2ITuRWGx9MSkuUklrMuS/7zQcd1pPglY/n1CflX/ e/GA0rhgIUWwyW/ZsmHCw2u9rHPIDoQIpRoQf+3F95BO8iIXdH5leRKmbRnU1YhrlleA Xq53lAFZj3thYLihgU7N355hvByKgRzLGjLBWeGtf+KVEI3Emp9Pk2S2E7w21+0fZmvD RgwHJp8VfqrqRz77vgrBPS4LcNaBO6oclCMBTMs8yaivcewr6is6U3sr0LoBMaaM424r IYZFNutJhF5QyIc/SG0OSP8Cr7rGgCCEKmAIPI6ZUtU4MYNqpmZxrta29NqZt7SQXW9w qJwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0k8B8D44ZhNEpq2bojltVwtEE9x0UZtpZiH8OVqGUp0=; b=okmwXZFaN7ZvdlihWH6P/131M5/uLk3Bi+B/xzKoLBEI4AtuS+lTQJRh65/ju0cUeI xoe/HPgmic4AN35uwvtdO64ZXe8SNjLyTwiXA/2C9qAHG2qbcwr17JXgdr3fV28u6duX DKTN3py1R/UpNudT2q5/ZnyOxDZmbhh+S4IyeggUXE9XtN80Ddpg/w8WTaS6F+1IbOA8 j5p3s38StCKilanDXm9uLQpTnxzoGi5BDybWPnvijATMElwzYa2rQKJzycQLWax3Iscq UmHixBLCu/GVk2dPytv9J3DjRZC3OgVohTaviN+wXSwCHXW4FvSOpWroGp+8O1e2aDng U8XA==
X-Gm-Message-State: APjAAAXBwhgvoSYuv0oBGc7DKrdrz5BD+jhZHkYP/WQ3t9xnkxCOFY4z ssSaImb0uYyyeoEnbIc4D77no/DhOu21pWjPTLA=
X-Google-Smtp-Source: APXvYqzcXM3n96ruslgwSum8plIW8sk89u1ZFvGKq+6DLcI7gyV274spWT3NU+goqyo1w7aRlREf87b1sEHIK4Y3wSw=
X-Received: by 2002:a05:6830:1685:: with SMTP id k5mr3209554otr.250.1571236557745; Wed, 16 Oct 2019 07:35:57 -0700 (PDT)
MIME-Version: 1.0
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> <13312.1571236317@dooku.sandelman.ca>
In-Reply-To: <13312.1571236317@dooku.sandelman.ca>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Wed, 16 Oct 2019 10:35:21 -0400
Message-ID: <CAHbuEH5Uw7AdeQSxg_Ty-AOe7vwtqGXDC_4YZWB8t_FEnwcmUA@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: "rats@ietf.org" <rats@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e1f3780595080436"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/8ri_-cg9WEJ0kXphLUxxN7csq1U>
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:36:04 -0000

On Wed, Oct 16, 2019 at 10:31 AM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> 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.
>

Agreed, this is important.  Attestations also provide origin
authentication, which is the basis for provenance.  Provenance just makes
that origin authentication (possibly for nested components) to be
possible.  IMO, it's a well understood term and should be easy to add, but
I'd like to see it in context of origin authentication that helps to
provide provenance.  It's how I talked about it yesterday.


>
> {I don't claim the other document does a great job at defining those
> terms, btw}
>
Hopefully, my explanation helps toward a definition in terms used in the
IETF already.

Best regards,
Kathleen


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

-- 

Best regards,
Kathleen