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

[Michael Richardson <[e-mail]>]

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.

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

    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
       isn't.

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

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

    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.

...

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

>Deliverables
> 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  [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [







--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-