Subject: [Rats] Adam Roach's No Objection on charter-ietf-rats-00-00: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Tue, 05 Feb 2019 23:02:53 -0800

Adam Roach has entered the following ballot position for
charter-ietf-rats-00-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-rats/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The charter contents look generally good to me, although I have some
copy-editing suggestions to make. I also agree with Ben that the charter needs
to be clear about whether the referenced support documents are intended for
publication as RFCs.

One substantive comment first:

> The architecture may include a system security model
> for the signing key material and involve at least the system component, system
> component provider, and the relying authority.

It's not clear to me whether this is intended to include/leverage an existing
PKI, establish a new PKI, or use some other scheme to establish trusted roots.
It seems that some of these options could end up being rather far ranging. I
don't feel strongly about what the correct answer is, but I think we want the
charter to make it clear whether such potentially broad tasks are in scope for
the working group, or if the models to be considered should be more
constrained.

---------------------------------------------------------------------------

The introduction of the charter is a bit jarring in the way that it jumps in
without first giving an indication of the technology field being dealt with.
Starting with an introductory sentence -- or even a clause -- indicating that
the working group is dealing with component attribute attestation would help.

---------------------------------------------------------------------------

> To improve the confidence in a system component's trustworthiness a relying
> party may require evidence about:

Nit: "...trustworthiness, a relying..."

---------------------------------------------------------------------------

> While domain-specific attestation mechanisms such as Trusted Computing Group
> (TCG) Trusted Platform Module (TPM)/Trusted Software Stack (TSS), Fast
> Identity Online (FIDO) Alliance attestation and Android Keystore attestation

Consider an Oxford comma before "and Android".

---------------------------------------------------------------------------

> While a relying party may use
> reference values to assess the assertions/claims the procedures for this
> activity are out of scope for this WG.

Nit: "...claims, the procedures..."

---------------------------------------------------------------------------

> The working group will cooperate and coordinate with other IETF WG such as
> TEEP, SUIT and SACM as appropriate.

Consider an Oxford comma before "and SACM".

---------------------------------------------------------------------------

> 3. Standardize data models that implements and secures the defined information

Nit: "...models that implement and secure..." or "...a data model that
implements and secures..."

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 15 Feb 2019 17:41:44 -0600

> https://datatracker.ietf.org/doc/charter-ietf-rats/

As a mental model, think "device" for "system component" and "manufacturer"
for "system component provider" (the terms are as such to allow for more
complicated scenarios).  The whole scheme is going to be premised on the
manufacturer getting some cryptographic bits in the device and keeping a
handle on which bits go with which device.  The relying party needs to get
that information somehow, and be able to trust it.  But to a large extent
we don't actually care how that happens, and that flow is not what we're
focusing on in this initial charter.  So my take on this is that the
architecture could describe a couple ways of doing this, but as more of an
informative matter to help someone understand how to build a system using
RATS, and not as a prescriptive matter.  I don't really think that falls
under "establish a new PKI", and it could but does not have to involve an
existing PKI.  So I'm not really sure what text we could add to the charter
that would help bring the clarity you desire.

I tried to reduce the jar factor.

Thanks for these.

-Benjamin