Re: [EAT] [Rats] Attestation BoF charter updates?

Michael Richardson <> Thu, 11 October 2018 20:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02C19130EDB; Thu, 11 Oct 2018 13:08:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G94q6dzVWbtM; Thu, 11 Oct 2018 13:08:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 01BFC130EC3; Thu, 11 Oct 2018 13:08:01 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPS id BBB731F95B; Thu, 11 Oct 2018 20:07:59 +0000 (UTC)
Received: by (Postfix, from userid 179) id 002AD14B5; Thu, 11 Oct 2018 16:07:52 -0400 (EDT)
From: Michael Richardson <>
To: Henk Birkholz <>
cc: "rats\" <>, "eat\" <>, Laurence Lundblade <>
In-reply-to: <>
References: <> <>
Comments: In-reply-to Henk Birkholz <> message dated "Thu, 11 Oct 2018 18:49:46 +0200."
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: Thu, 11 Oct 2018 16:07:52 -0400
Message-ID: <>
Archived-At: <>
Subject: Re: [EAT] [Rats] Attestation BoF charter updates?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EAT - Entity Attestation Token <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Oct 2018 20:08:05 -0000

re: "Information Elements (IE)"

If you have some wiggle room (i.e. you aren't trying to align with some other
pre-existing standards work elsehwere), it might be worth using another term,
as I think that this term is used for layer-2 extensions in 802.15.4
networks. I think that some people will be confused by this.  I think your
usage is very much a layer 6+ (abstract) concept.

I found the introduction to be meaningful only to those who already know what
it is about.  I suggest the following edits.  I make some of them just that
the charter will continue to meaningful in a year or two.

    Remote ATtestation ProcedureS (RATS) are included in network protocols to
    provide the basis for establishing trustworthy exchanges with a device.
    RATS expose trusted claim sets to detailed Attestation Evidence that
    enables a Verifying Party to retrace every step that led to its current
    Operational State. A consequence of this retracing is that it is possible
    to appraise the trustworthiness of a device. Application of RATS
    encompasses infrastructure supporting financial transactions, critical
    infrastructure, constrained-node environments, or the management of
    end-user devices.

    Measured file execution procedures (including the now deprecated term
    Secure Boot) provide the basis for conveying additional device
    characteristics that enable a Verifying Party to assess that a device is
    a Trusted System: one that operates as expected, does what is required,
    and does not do other things. Various Roots of Trust (e.g. for
    Measurement, for Reporting, or for Verification) provide the foundation
    to enable Implicit Attestation (the fact that a secret key is accessible
    implies specific meaning) and Explicit Attestation, which uses the output
    of Measured file execution as Attestation Evidence which along with event
    Log details can be used to can ratify that the device is actually a
    Trusted System.

    Problem Statement
    (1) We need a standard way to establish a sufficient level of confidence that a communication
    partner is with a trustworthy endpoint. This is a fundamental

    a) In 2018, there were no agreed upon standards that define a
       minimal set of Reference Values and Attestation Evidence that
       distinguishes a trustworthy execution environment over one that

    b) There isn't agreement on how to convey it appropriately, how to
        appraise evidence and how to present the appraisal results in an
        interoperable fashion. In essence, there is increasing demand for an
        overall communication, trust and assurance model to establish trust in
        potentially lying endpoints that is not currently met by other

    (2) In 2018, there are no common, standard ways for Relying Parties to know
    the provenance and characteristics of a device (e.g., an end-user device,
    platform or endpoint, servers, IoT devices, device subsystems and
    sub-modules) that may be requesting services.

    As a result, in 2018, a Relying Party would be unable to tell if a device is
    trying to mimic the identity of another device or
    some of its characteristics.   For instance, distinguishing between a
    secure wallet and INSERT SOMETHING would be relevant for a financial

    In 2018 there are existing domain-specific ways to do this, such as TCG TPM
    Attestation, FIDO Alliance attestation and Android Keystore Attestation.

    (3) Risk engines collect large amounts of information from a device in
    order to determine whether it is allowed access to data, a financial
    transaction or to perform other risk-sensitive operations. Agreement over
    the syntax and semantics of provenance and characteristics is essential
    for interoperability. Attestation provenance and characteristics
    represented via IE require proper definitions as Assertions. Standardized
    assertions promote increased - possibly ubiquitous -
    interoperability. Assertions also must be believable, for example, via
    Evidence that proves Assertion veracity.


    > Syntax for each Assertion in CBOR, JSON, YANG, and potentially others
    > [reintroduce terminology here? TARGET 2 @everyone, please chime in
    > here}

The only two have missed are XML and ASN.1, and I don't see that as a bug.
Writing in YANG, it's all mappable there if someone wants to do this.
I think you will also be using YANG for data at rest (yang-data), rather than
accessed by API.  This seems an increasingly common usage.

> Attestation information flows, consolidated terminology and corresponding
> taxonomies (overview/architecture to be developed in parallel with solution
> documents; can be separate document or go into 2, 3, 4 below)

In a break from the waterfall method of requirements, use-cases and then
protocols (or rather, in this case, artifact formats), I suggest that that
each be worked on in parallel, and that the terminology and architecture
documents be constrained to be published *LAST*. But, the WG should issue WG
Consensus Calls on the documents at intervals such that the text is in them
can be considered authoritative enough to answer questions in the protocol.

Note that I cut out a bunch of text from the Introduction. It didn't help me
understand the purpose of the group.  Also I note that IE is never used again
after the first paragraph, so I think you could just call them artifacts.

]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]        |   ruby on rails    [

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-