Re: [Rats] [ietf-rats-wg/eat] Definition and usage of the term 'entity' (#16)

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Fri, 04 October 2019 20:02 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 4DD6E1200E9 for <rats@ietfa.amsl.com>; Fri, 4 Oct 2019 13:02:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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] 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 hiPgSWS1Vuno for <rats@ietfa.amsl.com>; Fri, 4 Oct 2019 13:02:34 -0700 (PDT)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 F204A1200DE for <rats@ietf.org>; Fri, 4 Oct 2019 13:02:33 -0700 (PDT)
Received: by mail-ot1-x335.google.com with SMTP id m19so6348812otp.1 for <rats@ietf.org>; Fri, 04 Oct 2019 13:02:33 -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=OlCguLCKYu0tqsc/r7tVeETJe3rDWLO/ZTXmc62+ikM=; b=SKFlGgtpJaf9ZDBWPaS83N3tD4omowgC8xwq7EIRCDJMey8sR3S7/JEgAs887Y3Uob vzGaKI0e0GlGR7OiE7gbBQhLilJ8m+HDuZsjk6Xt2rOkp2LWtV6dEKdvnGP9QUNc/+b5 MRQXEuVOY4UZi8dKKGOp+MT/JfMlzxFqMlbxUsWBuOwijCdExAUAApY4VPhFsH5zE05p vZQUWfcCpuIrrEybnqHsaw3Yb2ud6clEodHe7T67+kCqvSa78FV8+LaY+0KV/+sQbh+v kdYimdmT6kts0Jfot2RisMgdwsEAq3VJrrsQOTD5dho21J62EmZPPZXqeeIr0cmsEnu/ w82A==
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=OlCguLCKYu0tqsc/r7tVeETJe3rDWLO/ZTXmc62+ikM=; b=CWJ9e/4DCBhCNaQpiHKbLAan7anqtYLhXBku7xIdMUQFexYBPncCbOoSrOhROc8DJf ZQ7h4eM3Aa56Imrx3x2NmVlyL+oSH2i9+VUEiGSpm20inQiI9+ta/h/DYr3pa4RD+rvM 0dg+pXNAMyXetwO7HnqiKGMgQnCyouwzSsVBUaycfUpNb2EfeUK7QI8mtH5FIxzsXj2k UYb7hEqS9w/UWWsMrol/VW6tX2lJj9OM5euyx8UKeAfyihS8zydcWQc0o9xzkpi6Zspd H7zMorbfyQ4FH0bRDEKwVXwy3dW/YtF01PWYbdmIqzCjjNuU+15kvIu96IyB5HiwVBod 9jiw==
X-Gm-Message-State: APjAAAX+yxpLh9bjeZyKmYAJaHZO8IzYjjoc18x9T0sH4YB9owNqibho exiMErFrhZbC//WmwiwTpTpaX8lVkin1FXU/6f0=
X-Google-Smtp-Source: APXvYqxzVNFZpr4Kl39jgrfvqHzUmOiY4YPicGsR0MEpPF7NsYHIwt+D3DPvVQD5yve+YM6VgYeLGSQLiuPTCEZ3MCo=
X-Received: by 2002:a9d:6642:: with SMTP id q2mr11942622otm.250.1570219353160; Fri, 04 Oct 2019 13:02:33 -0700 (PDT)
MIME-Version: 1.0
References: <ietf-rats-wg/eat/issues/16@github.com> <ietf-rats-wg/eat/issues/16/538489003@github.com> <E4998B54-DD72-46BA-8022-38F95F46021A@intel.com> <CAHbuEH7Wr-6+ADcRDpoq7m_iDjndkaKWW5MRSG9DUDdc8c_f5A@mail.gmail.com> <D5CE0BA1-E9A8-4B20-A9BB-3A6BBCE1F1D7@intel.com>
In-Reply-To: <D5CE0BA1-E9A8-4B20-A9BB-3A6BBCE1F1D7@intel.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Fri, 04 Oct 2019 16:01:56 -0400
Message-ID: <CAHbuEH7fv_8Wx2Jiph+W+hF6CYMPBeddHhn2j8F+QXM_DjCJsA@mail.gmail.com>
To: "Smith, Ned" <ned.smith@intel.com>
Cc: ietf-rats-wg/eat <reply+ABPMCSFS3MJKQGCWIELN36V3UTAZLEVBNHHBX3OMDM@reply.github.com>, ietf-rats-wg/eat <eat@noreply.github.com>, "rats@ietf.org" <rats@ietf.org>, Comment <comment@noreply.github.com>
Content-Type: multipart/alternative; boundary="000000000000c3c26105941b2e5c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/qtpvVQ8edvMDKyoz-irTLxMDZjU>
Subject: Re: [Rats] [ietf-rats-wg/eat] Definition and usage of the term 'entity' (#16)
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, 04 Oct 2019 20:02:36 -0000

On Fri, Oct 4, 2019 at 3:53 PM Smith, Ned <ned.smith@intel.com> wrote:

> See inline [nms]
>
>
>
> On 10/4/19, 12:17 PM, "Kathleen Moriarty" <
> kathleen.moriarty.ietf@gmail.com> wrote:
>
>
>
>
>
>
>
> On Fri, Oct 4, 2019 at 1:56 PM Smith, Ned <ned.smith@intel.com> wrote:
>
> The architecture defines:
>
> · Entity:  a user, organization, device or computing environment.
>
> · Principal:  an Entity that implements RATS Roles and creates provable
> Claims or Attestation Results (see [ABLP] and [Lampson2007]).
>
> · Attesting Computing Environment:  a Computing Environment capable of
> monitoring and attesting a target Computing Environment.
>
> · Attested Computing Environment:  a target Computing Environment that is
> monitored and attested by an Attesting Computing Environment.
>
>
>
> The attested computing environment is the subject of attestation which
> clearly is creating provable claims.
>
>
>
> The ‘attested’ environment may be less clearly a Principal. At one point
> the list suggested the architecture should define a term “target of
> attestation” or “attestation target” (or something similar). The term
> “attested computing environment” seems close to this. Do we think the
> attested environment is semantically the same as “subject of the
> attestation”?
>
>
>
> Using Lampson’s definition of Principal, an expression of attributes (aka
> claims) is itself a principal.
>
>
>
> There are lots of cases where ‘entity’ is used to refer to organizations
> and users (see https://csrc.nist.gov/glossary/term/entity ). Given the
> broad use of the term to mean: a “user, organization, device or process” it
> might not make sense for RATs to change its scope. The RATS Arch used the
> term “computing environment” instead of process because not every computing
> environment has an operating system.
>
>
>
> An “attested computing environment” is clearly intended to be a “computing
> environment” and hence is an Entity according to the arch draft.
>
>
>
> And from a review of the EAT draft (again), I am reading this as the
> attestation based on the installed code with the attestation performed at
> boot to match what was installed.  This would verify that the code was what
> the system administrator installed and configured.  As opposed to code
> being attested by the creator, which might be done with the same format,
> but would assure the code was as he creator expected.
>
>
>
> I'm asking about this clarification in light of supply chain and the flow
> document:
>
>
> https://datatracker.ietf.org/doc/draft-fedorkow-rats-network-device-attestation/?include_text=1
>
>
>
> Does the supply chain use case hold in these definitions or is there some
> reason why we might not care about attestations on code from the originator
> that might include code it relies upon when chained attestations are
> considered?  This would expand out the definition of entity as well.
>
> [nms] The RATS architecture describes the “attestations on code from the
> originator” as “Endorsements” from “Asserters”. The architecture tries to
> avoid using the term “attestation” in this context as collection of
> reference values (Endorsements) isn’t the same as providing proof and
> evidence (and the charter ruled this out of scope for now). The NIST
> definition of Entity includes supply chain entities (aka Asserters).
>
>
>
> If the RATS charter were updated to allow definition of “Endorsements” it
> might make sense to propose using JWT/CWT as a binding.
>

Could an endorsement be a form of attestation so the charter does not need
to be updated?  If we wind up with lots of formats, it'll be impossible to
manage with code being used by an entity for which they each chose their
own format. From the submitted flow draft that covers this scenario, I'm
not sure the terminology was clear enough on the point to separate those
out and intentionally exclude endorsements.


> The Architecture draft defines endorsements [here] as a specialization of
> Claims. Claims in Evidence can be semantically linked to claims in
> Endorsements. This is intentional so that verification is less susceptible
> to semantic misdirection.
>
> [here]
>
>    - Endorsements are reference Claims about the environment protecting
>    the Attesters capabilities to create believable Evidence (e.g. the type of
>    protection for an attestation key).  It answers the question "why Evidence
>    is believable".
>
>
>
This was helpful, thank you.
Kathleen

>
>
> If the EAT draft’s use of entity is semantically equal to the architecture
> draft use of “attested computing environment” then possibly it makes sense
> for the EAT draft to begin using this term instead?
>
>
>
> The architecture draft potentially could be more clear as to whether an
> “Attested computing environment” is both an entity and a principal or just
> an entity. It seems clear that an “attesting computing environment” is a
> Principal.
>
>
>
> Is EAT limited to 'attested computing environments' or a broader
> definition of entity?
>
>
>
> Kathleen
>
>
>
>
>
> Ned
>
>
>
> On 10/4/19, 10:27 AM, "Laurence Lundblade" <notifications@github.com>
> wrote:
>
>
>
> EAT and Architecture are absolutely NOT aligned on the term entity. See my
> recent email comments on the architecture document.
>
> My basis for closure is that the architecture document will define some
> term that is the is used to refer to the subject of the attestation. Maybe
> we shouldn't close this until the architecture doc starts tracking issues
> formally.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/ietf-rats-wg/eat/issues/16?email_source=notifications&email_token=ABPMCSG6S47KPNKHPDRK3TDQM54ILA5CNFSM4ID7KXSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAMLBKY#issuecomment-538489003>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABPMCSAPK5BFFBWNGO2SLZTQM54ILANCNFSM4ID7KXSA>
> .
>
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
>
>
>
>
> --
>
>
>
> Best regards,
>
> Kathleen
>


-- 

Best regards,
Kathleen