[Rats] should Evidence containers be explicit about Personally Identiable Information?

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 01 July 2020 01:54 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 185913A08DB for <rats@ietfa.amsl.com>; Tue, 30 Jun 2020 18:54:41 -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 e7yaHS3RWwwS for <rats@ietfa.amsl.com>; Tue, 30 Jun 2020 18:54:39 -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 E1CD23A08D7 for <rats@ietf.org>; Tue, 30 Jun 2020 18:54:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 16EF8389BC for <rats@ietf.org>; Tue, 30 Jun 2020 21:51:50 -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 mv4WKpoF2Ck3 for <rats@ietf.org>; Tue, 30 Jun 2020 21:51:49 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3012B389BB for <rats@ietf.org>; Tue, 30 Jun 2020 21:51:49 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 520D8476 for <rats@ietf.org>; Tue, 30 Jun 2020 21:54:36 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: rats@ietf.org
In-Reply-To: <ietf-rats-wg/architecture/issues/116@github.com>
References: <ietf-rats-wg/architecture/issues/116@github.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: Tue, 30 Jun 2020 21:54:36 -0400
Message-ID: <28098.1593568476@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/Rjzo9FUrfch_rkEcNL7-fcL-daY>
Subject: [Rats] should Evidence containers be explicit about Personally Identiable Information?
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, 01 Jul 2020 01:54:41 -0000

The architecture design team is working hard to come to consensus!
We discussed for a few minutes an aside comment I had made about some text we
just added about keeping sensitive Evidence private.

Thomas Fossati has just included some of Kathleen's comments as a new ticket:

    > Kathleen's review [part 2](https://mailarchive.ietf.org/arch/msg/rats/7-UJAqHPMLhrGCk9tyh3JqGu8rw/)

    > Further privacy considerations:
    > * Remote attestation also provides a way to profile systems as well as
    > the user behind that system.
    > * If attestation results go higher in the stack to include containers
    > and applications, it could reveal even more about a system or user.

...

I had asked in my aside, if the *ARCHITECTURE* document should create a
requirement on Evidence (such as EAT) that it should *explicitely* flag when
it contains PII.

There are three pieces to this.
Let's start with the Evidence container, and use as an example:
  1) A claim about a device serial number,
  2) or a claim about a device location

a) PII could be implicit.
  The Verifier could just know this fact.
  That would be implicit: serial numbers are PII, device location is PII.
  Even if the device is a water-tower or a lighthouse. [cf:
     https://en.wikipedia.org/wiki/Lighthouse_and_naval_vessel_urban_legend ]
  The onus is now on the Verifier to ALWAYS know everything about every claim.
  Even ones it does not understand or use.
  This may have impacts upon audit trails, and who can see those audit trails.

b) PII could be explicit.
   The Attester would mark the claim with a flag, "pii: true" or something
   when it fills out a claim with data that it thinks is PII.
   This allows the Attester to mark every piece of data that might be
   sensitive as such, even if they are newly standardized claims that not
   every Verifier even uses.  {The lighthouse in the joke above, might decide
   that it's location is not PII}
   This relieves the Verifier from having to know the PII status of every
   item.

   (It is likely that "pii: true" would be the default, and pii:false
   would have to explicit, or rather, that the inverse: "public: true" would
   be what would be flagged)

An Evidence container, (such as EAT) could standardize the above.
We could debate this when we get to LC on EAT.
Another container (PKIX) might not.  This could be annoying.

So part of my question was should we debate this now, and make this an
architectural requirement for all containers?

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