Re: [Rats] Call for charter consensus

["Nancy Cam-Winget (ncamwing)" <[e-mail]>]

Thanks Ben and Laurence. It is correct that the intent of the preamble was for the list to be a sample, not an exhaustive list.
Adding the bullet makes good sense and I don't think it affects the actual scope of work or goals.

The charter now reads:

--[ snip ]--
Introduction
==========

Relying parties require evidence about the trustworthiness of remote system components [RFC4949] they interact with. Remote attestation procedures (RATS) enable relying parties to establish a level of confidence in the trustworthiness of remote system components by creating and processing attestation evidence. A relying party can then decide whether to consider a remote system component trustworthy or not.

To improve the confidence in a system component's trustworthiness a relying party may require evidence about:
* system component identity,
* composition of system components, including nested components,
* roots of trust,
* assertion/claim origination or provenance,
* manufacturing origin,
* system component integrity,
* system component configuration, 
* operational state and measurements of steps which led to the operational state, or
* other factors that could influence trust decisions

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 exist, there is no interoperable way to create and process attestation evidence to make determinations about system components among relying parties of different manufactures and origins. 

Goals
=====

This WG will standardize formats for describing assertions/claims about system components and associated evidence; and procedures and protocols to convey these assertions/claims to the relying parties.  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.

The working group will cooperate and coordinate with other IETF WG such as TEEP, SUIT and SACM as appropriate.  The WG will also evaluate prior work such as NEA and proprietary attestation technologies.

Program of Work
==============

The working group will develop standards supporting interoperable remote attestation procedures for system components. The main deliverables are as follows.

1. Specify a terminology, architecture and use cases that enable explicit (a set of verifiable assertion/claims is transported in the attestation) and implicit (a set of assertions/claims is implied by possession of a secret) attestation techniques.  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.

2. Standardize an information model for assertions/claims which provide information about system components characteristics scoped by the specified use-cases.

3. Standardize data models that implements and secures the defined information model (e.g., CBOR Web Token structures [RFC8392], JSON Web Token structures [RFC7519]).

4. Standardize interoperable protocols to securely convey assertions/claims.
--[ snip ]--


On 1/18/19, 10:51, "Laurence Lundblade" <[e-mail]> wrote:

    On Jan 18, 2019, at 10:42 AM, Benjamin Kaduk <[e-mail]> wrote:
    > 
    > Hi Laurence,
    > 
    > On Thu, Jan 17, 2019 at 10:17:30PM -0800, Laurence Lundblade wrote:
    >> Hi Nancy,
    >> 
    >> The charter lists some types of claims/assertions in the introduction.  That list does not include things like GPS Location, public part of key pairs generated on device, enforced conditions for use of that key, identity of an app requesting a token, and app/user defined claims. Most of these types of claims have been implemented already either by FIDO, Android attestation or other products.  A vision here is that Android or other types of apps prove who they are to the server and pass a lot of data to the relying party via the token, often as input to authentication and financial transaction risk engines. 
    >> 
    >> 
    >> I assume it will continue to hold that anyone can add any proprietary claim they want, but a lot of the types of claims/assertions I just mentioned would be valuable as a standard. Some will be relatively easy to standardize. Some may not be. My first thought is that some of the easy obvious ones should be in scope, but we need to draw a line somewhere so we’re not creating claims forever. Not sure where that line is.
    > 
    > Those are good points.  I think it's probably premature to wire down a
    > specific list of claims at charter time, so the list in the introduction
    > should be treated as exemplary rather than normative, as is typical for
    > charter introductions.  Perhaps we want to add another bullet "other
    > factors that could influence trust decisions" to make that more clear.
    
    
    That definitely works for me.
    
    LL