Subject: [Rats] next steps after the RATS BoF in Bangkok

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 14 Nov 2018 13:42:47 -0600

[bcc'd to [email-masked]]

Hi all,

Thanks to everyone for the productive BoF discussion in Bangkok, especially
to the chairs for organizing the session and adapting to keep us flowing
smoothly even as we deviated from the planned schedule.

During the session, I think we had broad support for work in the remote
attestation space, and some specific aspects within that space.  In
particular, I saw enough support to form a working group without
necessarily needing a second BoF.[1]  I see two likely candidates for
"minimum viable charterable work":

(1) the semantics of specific attestation claims and what preconditions
    must be present (i.e., provided by the higher level protocol) for them
    to be usable
(2) the protocol flow/structure for directly conveying an attestation
    request/response (i.e., just one bidirectional arrow of the diagram)

The initial scope could be expanded later as the WG's interests become
clear.

In order to know what starting point to use, we need to gauge the
community's level of interest: please let us know if you are interested in
working on either or both of these areas (or if you think it's the wrong
direction).

Proceeding with (2) would benefit from presenting a few concrete use cases
including all entities involved, to clarify which interaction is being
considered and which other interactions left as out of scope for the
initial work.  This could include cases like a mobile phone app (where the
phone is assumed to be powerful enough to apply policy and filter what
evidence/claims are presented to the apps' server) and measured boot (where
the device just presents measured values to an external server that must
determine validity and what information is to be conveyed to the relying
party), as well as others.  Hopefully we can keep up our momentum and get
some good discussions in the next few weeks before moving on to discussing
charter text.

In the interest of simplicity, I propose to use the [email-masked] list for
these discussions and close the [email-masked] list, since recent discussions
have been heavily overlapping and RATS was the BoF name.  (This of course
does not preclude much of anything, including reopening the [email-masked]
list and using a name other than RATS for the future WG.)

Thanks,

Ben

[1] This would still require the usual agreement on the mailing list,
IETF Last Call, etc.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 14 Nov 2018 14:06:55 -0600

On Wed, Nov 14, 2018 at 01:42:47PM -0600, Benjamin Kaduk wrote:
> party), as well as others.  [...]

I don't think I'm familiar enough with the material to present a full
use-case diagram for either of these cases, but I'll try to repeat some of
what I said at the mic line and expound a bit further on what I think I
understand so far.

Dave Thaler brought up the potential for an entity called the "attestation
server", which I (steeped in the prepared slides for the BoF) had a hard
time understanding at first; at the mic I think I characterized the
attestation server as an engine for applying policy and for potentially
reducing the initial evidence set from the device to a smaller or distinct
set of claims for conveyance to the RP.  (Dave/others, please correct me if
I've got that wrong!)  The original slides that were presented would then
have been assuming a sufficiently capable "device" entity that it would be
consolidated with the attestation server, making its own policy decisions
and choices about what claims to include in its response to the RP.

I think we probably also want to consider some concept of "owner" in at least
some of our use cases (noting that in the case of a mobile phone app this
might actually be the app author and not the device owner) -- the owner
would in my model be configuring what policy to use on an attestation
server or provisioning an ACL on a device for who is authorized to receive
evidence and/or claims.

-Ben