Subject: Re: [Rats] Reminder on RATS scope

From: Jeremy O'Donoghue <[email-masked]>
Date: Tue, 4 Jan 2022 09:24:58 +0000

Hi,

I think this makes sense. +1

Jeremy

On 26/12/2021, 23:55, "RATS" <[email-masked]> wrote:

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi,

Taking advantage of the Christmas break for trying to get up-to-date with my pending email, let me share my support to the requests for extending the scope to address enforcer and reference value formats. And Henk's proposal looks good to me.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: [email-masked]
Mobile:  +34 682 051 091
----------------------------------

On 20/12/2021, 15:21, "RATS on behalf of Henk Birkholz" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Roman,

    we tried to create proposal for a minimalist change to the charter with
    the intent to allow for endorsement and reference values to be in scope.

    > https://github.com/ietf-rats/charter/compare/798fd27...2nd-RC1

    Viele Grüße,

    Henk

    On 14.12.21 18:40, Roman Danyliw wrote:
    > Hi!
    >
    > Congratulations to the WG on the recent push of documents heading to the IESG or in WGLC.  I am enthusiastic to see this progress.
    >
    > As the WG considers the future work that needs to be done, I wanted to reiterate the charter scope [1] in terms of the common language we have established through the architecture document [2].  I appreciate that there might be ambiguity as the charter language wasn't written with the benefit of this common terminology or the insights the WG has gotten since starting in 2019.
    >
    > In scope activities are:
    > ** Architecture (to include extensions, but not alternatives) and use cases (plural) documentation (informational documents) for RATS regardless of which components are involved
    > ** Protocols, formats and procedures for the communication between (a) the attester and verifier, and (b) the verifier and the relying party
    >
    > Out of scope activities are:
    > ** Protocols involving the endorser, reference value provider, verification owner, relying party owner as their primary focus
    > ** Formats for endorsements, reference values, appraisal policy for evidence, or appraisal policy for attestation results
    >
    > It has not escaped my attention that a number of the individual (unadopted) drafts [3], some under WG discussion, are out of scope per the charter.  I leave it to the WG to consider if they have both the energy and interest to consider broader scope.  I would strongly recommend that the next time the WG updates the charter with new scope, the terminology be harmonized.
    >
    > Regards,
    > Roman
    >
    > [1] https://datatracker.ietf.org/wg/rats/about/
    > [2] Figure 1. https://datatracker.ietf.org/doc/draft-ietf-rats-architecture/
    > [3] https://datatracker.ietf.org/wg/rats/documents/
    >
    > _______________________________________________
    > RATS mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/rats
    >

    _______________________________________________
    RATS mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/rats

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________
RATS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rats

---

From: Dennis Mattoon <[email-masked]>
Date: Fri, 7 Jan 2022 20:23:30 +0000

Hello,

The charter change as proposed in Henk’s mail (https://github.com/ietf-rats/charter/compare/798fd27...2nd-RC1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats%2Fcharter%2Fcompare%2F798fd27...2nd-RC1&data=04%7C01%7CDennis.Mattoon%40microsoft.com%7C8ce85d09216240cca2a008d9cf641cb0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637768852151368471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=YAW743%2FjFByoi6Sy4CWFiXbaSLYq5iu9v65j1gUe8ps%3D&reserved=0>) is exactly what’s needed, in my opinion.

Regards,
Dennis (individually and as TCG DICE chair)

From: RATS <[email-masked]> On Behalf Of Jeremy O'Donoghue
Sent: Tuesday, January 4, 2022 1:25 AM
To: Diego R. Lopez <[email-masked]>; Birkholz, Henk <[email-masked]>; Roman Danyliw <[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: [Rats] Reminder on RATS scope

Hi,

Jeremy

On 26/12/2021, 23:55, "RATS" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Be goode,

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fdr2lopez%2F&data=04%7C01%7CDennis.Mattoon%40microsoft.com%7C8ce85d09216240cca2a008d9cf641cb0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637768852151368471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=XOmUcr0XuI1vNBAKxKkgSllUwRlGO%2FPULqdgKaWQ6wg%3D&reserved=0>

e-mail: [email-masked]<mailto:[email-masked]>
Mobile:  +34 682 051 091
----------------------------------

On 20/12/2021, 15:21, "RATS on behalf of Henk Birkholz" <[email-masked] on behalf of [email-masked]<mailto:[email-masked][email-masked]>> wrote:

    Hi Roman,

    > https://github.com/ietf-rats/charter/compare/798fd27...2nd-RC1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats%2Fcharter%2Fcompare%2F798fd27...2nd-RC1&data=04%7C01%7CDennis.Mattoon%40microsoft.com%7C8ce85d09216240cca2a008d9cf641cb0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637768852151368471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=YAW743%2FjFByoi6Sy4CWFiXbaSLYq5iu9v65j1gUe8ps%3D&reserved=0>

    Viele Grüße,

    Henk

    On 14.12.21 18:40, Roman Danyliw wrote:
    > [1] https://datatracker.ietf.org/wg/rats/about/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fwg%2Frats%2Fabout%2F&data=04%7C01%7CDennis.Mattoon%40microsoft.com%7C8ce85d09216240cca2a008d9cf641cb0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637768852151368471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=9pboABdgHl4%2BMxd6v3Vb7ssQ%2FH51pWocdryHbzFE7gc%3D&reserved=0>
    > [2] Figure 1. https://datatracker.ietf.org/doc/draft-ietf-rats-architecture/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-rats-architecture%2F&data=04%7C01%7CDennis.Mattoon%40microsoft.com%7C8ce85d09216240cca2a008d9cf641cb0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637768852151368471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=rW0tUfGvvBxXmW%2BgFGV%2FtJ01K23%2FNSauOB3%2BXteCWNw%3D&reserved=0>
    > [3] https://datatracker.ietf.org/wg/rats/documents/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fwg%2Frats%2Fdocuments%2F&data=04%7C01%7CDennis.Mattoon%40microsoft.com%7C8ce85d09216240cca2a008d9cf641cb0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637768852151368471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=lRtcC%2BKgQOOZob2I3WKV4Kurh2hcv%2B4Zw6wjwVTdTzE%3D&reserved=0>
    >
    > [email-masked]<mailto:[email-masked]>
    > https://www.ietf.org/mailman/listinfo/rats<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&data=04%7C01%7CDennis.Mattoon%40microsoft.com%7C8ce85d09216240cca2a008d9cf641cb0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637768852151368471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=HCTRDq69kZQLMbxqK0o9mlq7tZin7u0vP8UKlG4ANHo%3D&reserved=0>
    >

    _______________________________________________
    RATS mailing list
    [email-masked]<mailto:[email-masked]>
    https://www.ietf.org/mailman/listinfo/rats<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&data=04%7C01%7CDennis.Mattoon%40microsoft.com%7C8ce85d09216240cca2a008d9cf641cb0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637768852151368471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=HCTRDq69kZQLMbxqK0o9mlq7tZin7u0vP8UKlG4ANHo%3D&reserved=0>

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&data=04%7C01%7CDennis.Mattoon%40microsoft.com%7C8ce85d09216240cca2a008d9cf641cb0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637768852151368471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=HCTRDq69kZQLMbxqK0o9mlq7tZin7u0vP8UKlG4ANHo%3D&reserved=0>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Jan 2022 09:47:09 -0500

> As the WG considers the future work that needs to be done, I wanted to reiterate the charter scope [1] in terms of the common language we have established through the architecture document [2].  I…

okay, so we have a long thread of support for Henk's small wording 
change (in github).
First, I also support this change.

Second, do the WG chairs need initiate a charter update, or is the 
discussion here already well taken?

Third, my opinion is that there are a lot of scenarios where 
Endorsements and Reference Values are entirely proprietary (inhouse) 
and/or are already well defined in some community.  The reason to have 
excluded them initially was to avoid having any conflicts about what is 
good, bad, etc. about what's there, and to focus on the consensus around 
Attester/Verifier/Relying Party interoperability.

But, the architecture has captured this, and now we should move on. 
There are many greenfields (like RIV) where there are no established 
practices, nor is there a single vendor who has does not need to 
coordinate with others.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Jan 2022 09:58:38 -0500

> We do need reference measurements covered somewhere.  Otherwise I am 
not sure how a multi-vendor Verifier might be supportable.  So I would 
support a limited charter change related to this.  I suspect this was 
previously out-of-scope because the architecture wasn't done.

I agree that RIV has to define this, and I would encourage RIV to pick a 
solution (whether it's CORIM or whatever).    I think that it's okay for 
RIV to define an architecture for how Endorsements/ReferenceValues, etc. 
get to a vendor-neutral/multi-vendor Verifier.  It's specific to RIV. 
(It is certainly different for Hollywood RPs who want to use TEEP to do 
DRM. )

What I am saying is that I don't think that we can or should define a 
solution-independent architecture for the stuff behind the Verifier. 
Building blocks?  Absolutely.  But, let's expect multiple documents here 
addressing different sectors.

(In the ROLL WG, we had multiple applicability statements, in which 
security was an important part.  The applicability statement for 
industrial networks found insufficient building blocks available, and 
turned into the 6tisch WG, for instance)

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 10 Jan 2022 17:15:43 +0100

On 2022-01-10, at 15:47, Michael Richardson <[email-masked]> wrote:
> 
> okay, so we have a long thread of support for Henk's small wording change (in github).
> Second, do the WG chairs need initiate a charter update, or is the discussion here already well taken?

I’m not a WG chair, but if I were one for this group, I’d probably diagnose WG consensus on making this change.  The next step would be for the responsible AD to provide any push-back that can be prognosticated the IESG as a whole would have.  And once the discussion ensuing from that is reflected in the draft change, to pick this up as a small item recharter… before the outstanding big one is done.

Grüße, Carsten

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 11 Jan 2022 22:57:04 +0000

Hi Henk and WG!

I don't want to micromanage the creation of proposed charter text, but I would suggest we leverage the clarity we got from the all of the hard work on the architecture document an enshrine it into the charter text.

A way to repeat the same charter scope we have now using the language of the architecture document and add the new proposed scope (cribbing from Henk's words) would be as follows:

===[ OLD

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 relying parties. Given the security and privacy
sensitive nature of these assertions/claims, the WG will specify approaches to
protect this exchanged data. While a relying party may use reference, known, or
expected values or thresholds to assess the assertions/claims, the procedures
for this activity are out of scope for this WG (without rechartering).

Program of Work
===============
3. Standardize an information model for assertions/claims which provide
information about system components characteristics scoped by the specified
use-cases.

5. Standardize interoperable protocols to securely convey assertions/claims.

===[ Proposed

Goals
=====

The WG has defined an architecture (draft-ietf-rats-architecture) for remote attestation.  It will standardize formats for describing evidence and attestation results; and the associated procedures and protocols to convey this evidence for appraisal to a verifier and these attestation results to a relying party.  Additionally, the WG will standardize formats for endorsements and reference values, but protocols and associated procedures for conveying them to the verifier are out of scope.  Formats and protocols for appraisal policy for evidence and appraisal policy for attestation results are also out of scope.

Program of Work
===============
3. Standardize an information model for evidence and attestations results scoped by the specified use-cases

5. Standardize interoperable protocols to securely convey evidence and attestation results

6. Standardize information and data models to securely declare and convey endorsements
   and reference values.

==[ end

In addition to the charter text itself, the charter would need milestones for this new program of work in #6 (of the form "<date> Submit <deliverable name> draft to IESG for publication").  During this discussion I would also recommend revisiting all of the existing milestones which are 6 months - almost 2 years old in some cases.

Regards,
Roman

> -----Original Message-----
> From: Henk Birkholz <[email-masked]>
> Sent: Monday, December 20, 2021 9:21 AM
> To: Roman Danyliw <[email-masked]>; [email-masked]
> Subject: Re: [Rats] Reminder on RATS scope
> 
> Hi Roman,
> 
> we tried to create proposal for a minimalist change to the charter with the
> intent to allow for endorsement and reference values to be in scope.
> 
> > Congratulations to the WG on the recent push of documents heading to the
> IESG or in WGLC.  I am enthusiastic to see this progress.
> >
> > As the WG considers the future work that needs to be done, I wanted to
> reiterate the charter scope [1] in terms of the common language we have
> established through the architecture document [2].  I appreciate that there
> might be ambiguity as the charter language wasn't written with the benefit of
> this common terminology or the insights the WG has gotten since starting in
> 2019.
> >
> > In scope activities are:
> > ** Architecture (to include extensions, but not alternatives) and use
> > cases (plural) documentation (informational documents) for RATS
> > regardless of which components are involved
> > ** Protocols, formats and procedures for the communication between (a)
> > the attester and verifier, and (b) the verifier and the relying party
> >
> > ** Protocols involving the endorser, reference value provider,
> > verification owner, relying party owner as their primary focus
> > ** Formats for endorsements, reference values, appraisal policy for
> > evidence, or appraisal policy for attestation results
> >
> > It has not escaped my attention that a number of the individual (unadopted)
> drafts [3], some under WG discussion, are out of scope per the charter.  I leave
> it to the WG to consider if they have both the energy and interest to consider
> broader scope.  I would strongly recommend that the next time the WG
> updates the charter with new scope, the terminology be harmonized.
> >
> > Regards,
> > Roman
> >
> > [2] Figure 1.
> > https://datatracker.ietf.org/doc/draft-ietf-rats-architecture/

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 11 Jan 2022 23:54:16 +0000

@Roman Danyliw, Thanks for contributing to the discussion!

@Henk Berkholz, Thanks for capturing proposed charter text at https://github.com/ietf-rats/charter/compare/798fd27...2nd-RC1 

I assume someone will incorporate Roman's suggestions into the git repo so that all list members will be able to review the proposed text in toto? 

Maybe it makes sense for those wishing to voice objections or who want to suggest changes, to do so by the end of next week to bring the thread to a conclusion? However, this might be contingent on the proposed charter text on github being updated in a timely manner.

Thanks,
-Ned

On 1/11/22, 2:57 PM, "RATS on behalf of Roman Danyliw" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Henk and WG!

    ===[ OLD

    Goals
    =====

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

    ===[ Proposed

    Goals
    =====

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

    ==[ end

    Regards,
    Roman

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Jan 2022 19:50:57 -0500

Roman Danyliw <[email-masked]> wrote:
    > The WG has defined an architecture (draft-ietf-rats-architecture) for
    > remote attestation.  It will standardize formats for describing
    > evidence and attestation results; and the associated procedures and
    > protocols to convey this evidence for appraisal to a verifier and these
    > attestation results to a relying party.

Good rewording to here, no complaints.

    > Additionally, the WG will
    > standardize formats for endorsements and reference values, but
    > protocols and associated procedures for conveying them to the verifier
    > are out of scope.

It is unclear to me if we are allowed to write a profile document (for, e.g.:
RIV) that says that:
   The manufacturer will use CoAP POST over DTLS with client-side
   certificates to convey the reference value artefact to the Verifier.

I think that by making protocols and proceedures out of scope, you are
forbidding us from inventing something new... (HTTP/2.01 or QUIC2.3)
But, it's okay for us to say to use something that exists.

I guess, it's the "associated procedures" implies to me, that we can't
register a MIME type.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 12 Jan 2022 01:56:25 +0000

Hi Michael!

> From: Michael Richardson <[email-masked]>
> Sent: Tuesday, January 11, 2022 7:51 PM

My intent was for that text to be a restatement of the current charter text using the new words and terminology from the architecture document.

> forbidding us from inventing something new... (HTTP/2.01 or QUIC2.3) But, it's
> okay for us to say to use something that exists.
> 
> I guess, it's the "associated procedures" implies to me, that we can't register a
> MIME type.

I can see the issue.  I think the WG should figure out what they want to do and explicitly say it.  My intent wasn't to restrict anything beyond a convention of explicitly saying anything not mentioned as in-scope is out of scope.  That alternative text was my read of the originally proposed text which is entirely silent on protocol work, and only mentioned information and data models.

==[ snip ]==
A relying party or verifier may use reference,
known, endorsed, or expected values or thresholds to assess the assertions/claims.
Information and data models for this activity are in scope for this WG.
==[ snip ]==

Not to lead the WG in any technical direction, if the intent would be to do a profile as described above, perhaps something like the following would be more appropriate:

OLD:
Additionally, the WG will standardize formats for endorsements and reference values, but protocols and associated procedures for conveying them to the verifier are out of scope.

NEW:
Additionally, the WG will standardize formats for endorsements and reference values, and may profile existing protocols (e.g., CoAP or DTLS) to conveying them to the verifier.

Regards,
Roman

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 13 Jan 2022 00:06:21 +0100

Hi Ned,

as a first step, I tried to capture Roman's proposals here:

> https://github.com/ietf-rats/charter/compare/2nd-RC1...2nd-RC2

and actually took the liberty to update the 2nd paragraph of "Goals" in 
this step, too.

OLD:
The working group will cooperate and coordinate with other IETF WGs such 
as TEEP, SUIT, and SACM, and work with organizations in the community, 
such as the TCG and the FIDO Alliance, as appropriate. The WG will also 
evaluate prior work such as NEA and proprietary attestation technologies 
like the Android Keystore.

NEW:
The WG will continue to cooperate and coordinate with other IETF WGs 
such as TEEP and SUIT, and work with organizations in the community, 
such as the TCG and the FIDO Alliance, as appropriate.

Please bash, if that reads wrong and/or can be improved.

Viele Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 13 Jan 2022 00:25:22 +0100

Hi Roman,
hi list,

On 12.01.22 02:56, Roman Danyliw wrote:
> I can see the issue.  I think the WG should figure out what they want to do and explicitly say it.

As we are doing this thoroughly, please speak up, if you think there are 
work items or additions to work items missing that should be explicitly 
spelled out - to make sure that we'll propose a charter text for a first 
consensus check that accurately reflects what everybody wants to do and 
also actually can do in this next phase.

It is a tad bit late on my side to really go through the entire text 
today in a productive way. But I'll check for that tomorrow.

I also agree that we then also have to update or define corresponding 
milestones, accordingly.

Viele Grüße,

Henk

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 13 Jan 2022 16:43:09 +0000

Henk,
Good catch, as SACM has wound down. It seems the evaluation of prior work happened organically and is reflected in use cases draft. 

On 1/12/22, 3:07 PM, "Henk Birkholz" <[email-masked]> wrote:

    Hi Ned,

    OLD:

    NEW:

    Viele Grüße,

    Henk

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 14 Jan 2022 10:40:34 +0000

Hi Roman, Michael,

On Wed, Jan 12, 2022 at 1:57 AM Roman Danyliw <[email-masked]> wrote:
> > Good rewording here, no complaints.

+1

> I can see the issue.  I think the WG should figure out what they want to do and explicitly say it.  My intent wasn't to restrict anything beyond a convention of explicitly saying anything not menti…

On the media types point: it seems to me that, when describing a data
model, declaring its associated media types is a very natural thing to
do contextually to the definition of the model.  This is what we do
all the time in the IANA consideration section.  I don't see a reason
why this would need to be spelled out explicitly once the charter
contains text such as "Standardize information and data models to
securely declare and convey endorsements and reference values."?

cheers,
-- 
Thomas

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 14 Jan 2022 10:54:03 +0000

hi Roman, Michael,

> Additionally, the WG will standardize formats for endorsements and reference values, and may profile existing protocols (e.g., CoAP or DTLS) to conveying them to the verifier.

I think there is a clear distinction between:
1. defining an API (e.g., use HTTP/CoAP POST to the /submit endpoint
-- for example [1]), and
2. defining an extension to an existing protocol (e.g., MUD, SUIT,
etc.) to inline endorsements and/or reference values into an already
existing envelope.

It seems to me that Michael's example above doesn't clearly draw that
line, and I think this is worth discussing.

[1]  https://github.com/veraison/veraison/tree/main/docs/api/endorsement-provisioning

cheers,
-- 
Thomas

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 14 Jan 2022 18:46:20 +0100

Hi all,

as promised I have reviewd the whole charter text in 2nd-RC2 and here 
are my proposed changes:

> https://github.com/ietf-rats/charter/compare/2nd-RC2...2nd-RC3

All but one of them are nits and details, I think.
The essential change is an additional deliverable explicitly added to 
the program of work.

NEW:
> 7. Standardize interoperable data formats for freshness indicators to be used in conveyance protocols for evidence and attestation results.

It might be that this is already covered by deliverable #5, but as we 
are also preparing the milestones next (and we are working on this), I 
chose to err on the side of caution. Please bash and comment on that NEW 
deliverable.

Apropos milestones - there is now:

> https://github.com/ietf-rats/charter/blob/2nd-RC3/ietf-rats-milestones.md

This is just the existing milestones scraped from the datatracker and 
put into a markdown table in support of a discussion to update those 
with the help of the chairs here on the list.

NEW:
> | Date | Milestone | I-D
> | --- | --- | ---
> | Jul 2021 | Submit Architecture draft to IESG for publication | draft-ietf-rats-architecture
> | Jul 2021 | Submit Interaction Models draft to IESG for publication | draft-ietf-rats-reference-interaction-models
> | Mar 2021 | Submit RIV draft to IESG for publication | draft-ietf-rats-tpm-based-network-device-attest
> | Mar 2021 | Submit EAT draft to IESG for publication | draft-ietf-rats-eat
> | Dec 2020 | Submit TUDA draft to IESG for publication
> | Dec 2020 | Submit YANG Module draft to IESG for publication | draft-ietf-rats-yang-tpm-charra
> | Mar 2019 | Call for adoption on TUDA draft | draft-birkholz-rats-tuda

Viele Grüße,

Henk

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 14 Jan 2022 18:01:44 +0000

hi Henk,

> chose to err on the side of caution. Please bash and comment on that NEW

Yeah, freshness is an integral part of the conveyance protocols that
are covered in #5 and therefore I reckon that #7 would be redundant.
I think we can drop it without risk of accidentally descoping important work.

cheers, thanks
-- 
Thomas

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 14 Jan 2022 18:55:53 +0000

(not as chair)
The Program of Work items are presumed to align with Goals, hence wording variance in Program of Goals that could be interpreted as extending or constraining Goals should not be assumed. That said, the wording in (5.) seems to be broader than the wording in Goals as it relates to standardization of protocols, namely: "Additionally, the WG will standardize formats for endorsements and reference values, and may apply and/or profile existing protocols (e.g. DTLS, CoAP, or MUD) to convey them to the verifier." uses words like 'apply' and 'profile' whereas (5.) uses 'standardize...protocols'. The dissonance is if the protocol is existing then there is no need to standardize it. But if no protocol already exists then 'apply' and 'profile' don't seem to authorize definition of a new protocol.

If the Goals section is the last word on scope, then fine there is no confusion. But possibly, the intent of the scope isn't fully appreciated based on (5.) in Program of Work? 

I think I agree with Thomas that (7.) is a subset of (5.).

On 1/14/22, 9:47 AM, "RATS on behalf of Henk Birkholz" <[email-masked] on behalf of [email-masked]> wrote:

    Hi all,

    Viele Grüße,

    Henk

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 14 Jan 2022 20:25:38 +0100

Hi Ned,

yes, there is an asymmetry between how "evidence and attestation 
results" and "endorsements and reference values" are covered wrt scope. 
I am not a big fan of that asymmetry and, if others feel the same way, 
we could discuss that further.

On the deliverable #7: I am happy to remove it, if at some point the WG 
arrives at the conclusion that it is covered by #5 already.

Viele Grüße,

Henk

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 14 Jan 2022 19:54:35 +0000

As chair

Does anyone on the list believe item 7 in the Program of Work as stated here: https://github.com/ietf-rats/charter/compare/2nd-RC2...2nd-RC3 should remain in the Program of Work? 

If it is removed, the expectation is that the semantics of 7 are easily inferred from item 5 in the Program of Work.

Thanks,
Ned

On 1/14/22, 11:26 AM, "Henk Birkholz" <[email-masked]> wrote:

    Hi Ned,

    Viele Grüße,

    Henk

---

From: Michael Richardson <[email-masked]>
Date: Sat, 15 Jan 2022 17:59:59 -0500

Smith, Ned <[email-masked]> wrote:
    > Does anyone on the list believe item 7 in the Program of Work as stated
    > here: https://github.com/ietf-rats/charter/compare/2nd-RC2...2nd-RC3
    > should remain in the Program of Work?

My opinion is that any greenfield application of RATS that wants to use Epoch
Distribution, may need a protocol for doing that.

    > If it is removed, the expectation is that the semantics of 7 are easily
    > inferred from item 5 in the Program of Work.

"5. Standardize interoperable protocols to securely convey evidence and attestation results."

I guess that it could squeak in.

Here, "protocol" to me could mean PKIX extensions (if we are putting stuff into
certificates), or could mean some new multicast pub/sub mechanism that
transported EATs across ethernet (no CoAP, no IP, ...)

I am not bothered by scope creep here, because I think that our AD can reign
us in if we start re-inventing LLDP or something.
(I actually think that extending LLDP might actually be reasonable for some
environments, btw)