Subject: [Rats] RATS rechartering poll

From: "Smith, Ned" <[email-masked]>
Date: Wed, 23 Feb 2022 19:10:05 +0000

1.  Does the working group want to recharter now: yes / no

  1.  If you believe RATs should recharter, should the working group use the proposed text in https://github.com/ietf-rats/charter/blob/2nd-RC4/ietf-rats-charter.md as the new charter?

Please respond to the above questions related to rechartering.

Thanks,

RATS Chairs

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 23 Feb 2022 20:19:36 +0100

Hi Ned,

1. yes
2. yes

And a quick question: do the responses to Roman's statement [1] 
(highlighting that some items in the related document section are "are 
out of scope per the charter") that were indicating a desire for 
rechartering count into the responses for Question 1.)?

Viele Grüße,

Henk

[1] https://mailarchive.ietf.org/arch/msg/rats/f7E-G5O_JuadzVVLjeGXqSBbpwo

On 23.02.22 20:10, Smith, Ned wrote:
>  2. If you believe RATs should recharter, should the working group use
>     the proposed text
>     inhttps://github.com/ietf-rats/charter/blob/2nd-RC4/ietf-rats-charter.md
>     <https://github.com/ietf-rats/charter/blob/2nd-RC4/ietf-rats-charter.md>as
>     the new charter?
> 
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Ira McDonald <[email-masked]>
Date: Wed, 23 Feb 2022 14:52:16 -0500

Hi,

1. yes
2. yes

Cheers,
- Ira

*Ira McDonald (Musician / Software Architect)*

*Chair - SAE Trust Anchors and Authentication TF*
*Co-Chair - TCG Trusted Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*

*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: [email-masked]
<[email-masked]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Wed, Feb 23, 2022 at 2:20 PM Henk Birkholz <
[email-masked]> wrote:

> >     inhttps://
> github.com/ietf-rats/charter/blob/2nd-RC4/ietf-rats-charter.md
> >     <
> https://github.com/ietf-rats/charter/blob/2nd-RC4/ietf-rats-charter.md>as
> >     the new charter?
> >

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Thu, 24 Feb 2022 10:36:35 +0000

Hi Ned.

  1.  Yes
  2.  2. Yes

Best regards
Jeremy

On 23/02/2022, 19:53, "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,

1. yes
2. yes

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - SAE Trust Anchors and Authentication TF
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]<mailto:[email-masked]>
(permanent) PO Box 221  Grand Marais, MI 49839  906-494-2434

On Wed, Feb 23, 2022 at 2:20 PM Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ned,

1. yes
2. yes

Viele Grüße,

Henk

On 23.02.22 20:10, Smith, Ned wrote:
>     inhttps://github.com/ietf-rats/charter/blob/2nd-RC4/ietf-rats-charter.md<http://github.com/ietf-rats/charter/blob/2nd-RC4/ietf-rats-charter.md>
> [email-masked]<mailto:[email-masked]>

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

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 24 Feb 2022 11:19:25 +0000

Hi Ned, thanks for kicking this off.

On Wed, Feb 23, 2022 at 7:10 PM Smith, Ned <[email-masked]> wrote:
>
> Does the working group want to recharter now: yes / no

Yes.

> If you believe RATs should recharter, should the working group use the proposed text in https://github.com/ietf-rats/charter/blob/2nd-RC4/ietf-rats-charter.md as the new charter?

Yes.

cheers,
Thomas & Simon

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 24 Feb 2022 13:20:26 +0000

Yes 

Yes.

> > If you believe RATs should recharter, should the working group use the
> proposed text in
https://github.com/ietf-rats/charter/blob/2nd-RC4/ietf-rats-
> charter.md as the new charter?
> 
> Yes.
> 
> cheers,
> Thomas & Simon
>

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 24 Feb 2022 13:08:30 -0800

> On Feb 23, 2022, at 11:10 AM, Smith, Ned <[email-masked]> wrote:
> 
> 	• Does the working group want to recharter now: yes / no

Yes

>  
> 	• If you believe RATs should recharter, should the working group use the proposed text in https://github.com/ietf-rats/charter/blob/2nd-RC4/ietf-rats-charter.md as the new charter?

No

The charter's only stated goal is trustworthiness. This excludes device identity, device OEM, device characteristics and such. The charter must allow for other than trustworthiness.

The charter is narrowed to a two stage model. I do not think that is required or should be mandated.  The RP should be able to get the verification keys (the endorsement) directly from the manufacturer. 

I hope this is just a matter of wording in the charter. I don’t think there is disagreement about including device identity and allowing the Verifier to be collapsed into the RP.

Apologies if my comment is late in the process here. Didn’t have a chance to review until now.

LL

---

From: "Panwei (William)" <[email-masked]>
Date: Fri, 25 Feb 2022 01:11:02 +0000

Hi Ned,

1. Yes
2. Yes

Regards & Thanks!
Wei Pan (潘伟)

From: RATS [mailto:[email-masked]] On Behalf Of Smith, Ned
Sent: Thursday, February 24, 2022 3:10 AM
To: [email-masked]
Subject: [Rats] RATS rechartering poll

Thanks,

RATS Chairs

---

From: "Meiling Chen" <[email-masked]>
Date: Fri, 25 Feb 2022 14:28:56 +0800

Hi,
1. Yes
2. Yes

Best,
Meiling
 
From: Smith, Ned
Date: 2022-02-24 03:10
To: [email-masked]

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 25 Feb 2022 08:32:58 +0000

Hi Laurence,

> The charter's only stated goal is trustworthiness. This excludes device identity, device OEM, device characteristics and such. The charter must allow for other than trustworthiness.

I don't think these dimensions are excluded. To me any determination
about identity, manufacturing, etc., can be seen as a by-product of
the evidence appraisal process, which ultimately aims at deciding the
trustworthiness of the peer.

> The charter is narrowed to a two stage model. I do not think that is required or should be mandated.  The RP should be able to get the verification keys (the endorsement) directly from the manufact…

The (logical) two-stage appraisal is what the architecture describes.
There is no way you can pass-through the Verifier.

The "RP" that you sketch above is perfectly compatible with the
architecture as long as it bundles the RP and Verifier roles in one
entity: the verification keys are obtained by the Verifier role via
the manufacturer and used to provide attestation results to the
co-located RP role.

cheers,
-- 
Thomas

---

From: Yogesh Deshpande <[email-masked]>
Date: Fri, 25 Feb 2022 09:18:07 +0000

Hi Ned,

>From my side:

1. Yes

2. Yes

Regards,
Yogesh

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Eric Voit (evoit)
Sent: 24 February 2022 13:20
To: [email-masked]
Subject: Re: [Rats] RATS rechartering poll

Yes

Yes.

> charter.md as the new charter?
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Simon Frost <[email-masked]>
Date: Fri, 25 Feb 2022 10:18:43 +0000

1: Yes
2: Yes

Thanks
Simon

From: Smith, Ned <[email-masked]>
Sent: 23 February 2022 19:10
To: [email-masked]
Subject: [Rats] RATS rechartering poll

Thanks,

RATS Chairs

---

From: Brett Henning <[email-masked]>
Date: Fri, 25 Feb 2022 08:30:30 -0700

I agree with the bulk of the votes

1.       Yes

2.       Yes

Brett

*From:* RATS <[email-masked]> *On Behalf Of *Smith, Ned
*Sent:* Wednesday, February 23, 2022 12:10 PM
*To:* [email-masked]
*Subject:* [Rats] RATS rechartering poll

   1. If you believe RATs should recharter, should the working group use
   the proposed text in
   https://github.com/ietf-rats/charter/blob/2nd-RC4/ietf-rats-charter.md as
   the new charter?

Thanks,

RATS Chairs

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.

---

From: Brett Henning <[email-masked]>
Date: Fri, 25 Feb 2022 08:30:30 -0700

1.       Yes

2.       Yes

Brett

Thanks,

RATS Chairs

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 25 Feb 2022 11:16:41 -0800

I’ve created a PR <https://github.com/ietf-rats/charter/pull/13> with some changes.
- Explicitly allow authenticated claims
- Be clear the RP and Verifier can be combined
- Other wording improvements (That sentence about "determining whether RP’s can establish confidence in trustworthiness" is obtuse and technically wrong)

Comments below.

> On Feb 25, 2022, at 12:32 AM, Thomas Fossati <[email-masked]> wrote:
> 
> Hi Laurence,
> 

Glad to know you don’t think these are excluded. I’d feel better knowing there is broad agreement about this.

Maybe change 

in order to assess the trustworthiness of the peer. 

to 

in order to provide authenticated claims about the peer and to assess the trustworthiness of the peer

Here’s a few cases that should be covered by RATS that are not about assessing device trustworthiness:
- Geofencing based on location in AR. This is the RP enforcing a policy that is not policy about device trust.
- FIDO sending public key that is to be used for user authentication. This is key establishment/distribution.
- Financial transactions that log UEID, OEM ID, OEM model. This is about forensics and tracking.

> the manufacturer and used to provide attestation results to the

The Verifier is labeled a “third party” in the charter. That excludes the combined role. The removal of “third” is critical IMO.

Also, given how prominent the two-stage architecture is presented, I think it is good to point out they can be combined (and it is combined, not co-located).

LL

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 Feb 2022 14:51:11 -0500

Smith, Ned <[email-masked]> wrote:
    > If you believe RATs should recharter, should the working group
    > use the proposed text in
    > https://github.com/ietf-rats/charter/blob/2nd-RC4/ietf-rats-charter.md
    > as the new charter?

I have previously said that I had no objection to the text above.
I do not enjoy threads of +1, and I'd prefer to focus on concerns that there
might be with the text.  I think that we have already done that.

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 Feb 2022 14:53:17 -0500

Laurence Lundblade <[email-masked]> wrote:
    > The charter's only stated goal is trustworthiness. This excludes device
    > identity, device OEM, device characteristics and such. The charter must
    > allow for other than trustworthiness.

All questions are about truthworthiness.

Ned: what is your name?
MCR: "Laurence"
Ned: I don't trust your answer.

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 25 Feb 2022 12:12:26 -0800

> Ned: I don't trust your answer.

Right, but the the current charter seems to be:

Q: Verifier, tell me the devices trustworthiness rating:
A: OK. It is grade A2++

Q: Verifier, tell me the device’s name
A: I shouldn’t do that because it’s not in the RATS charter

LL

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 25 Feb 2022 23:06:40 +0000

Hi Laurence,

> Glad to know you don’t think these are excluded. I’d feel better knowing there is broad agreement about this.

I see RATS as an application enabler. If it precluded certain classes
of applications it would be self defeating. But I don't see in the
proposed charter anything that may create a barrier.

> in order to provide authenticated claims about the peer and to assess the trustworthiness of the peer

Not sure this change is needed.  In fact, the "required evidence" in
the top part of the same sentence is made of authenticated claims.

> - Geofencing based on location in AR. This is the RP enforcing a policy that is not policy about device trust.

Is a determination of the attester's trustworthiness the precondition
for accepting the claimed location as usable?
If so, this is a RATS use case, otherwise I don't think it is.

> - FIDO sending public key that is to be used for user authentication. This is key establishment/distribution.

Is a determination of the attester's trustworthiness the precondition
for accepting the public key?

> - Financial transactions that log UEID, OEM ID, OEM model. This is about forensics and tracking.

Ditto.

The goal of RATS is not to provide application-specific interfaces.
It's to define the interfaces that are needed by a relying party to
determine the trustworthiness of its peer in the context of some kind
of distributed computation.  That's the basic "RATS service", on top
of which one can construct a myriad of different applications.

> The Verifier is labeled a “third party” in the charter. That excludes the combined role. The removal of “third” is critical IMO.

SGTM

> Also, given how prominent the two-stage architecture is presented, I think it is good to point out they can be combined (and it is combined, not co-located).

Saying "combined roles" seems to remove the functional distinction
between roles, which (to me) is architecturally relevant.  Personally
I find "co-located roles within the same entity" more precise.
However, I don't feel strongly about this and I'd have no problems
with your suggestion.

cheers,
-- 
Thomas

---

From: Michael Richardson <[email-masked]>
Date: Sat, 26 Feb 2022 16:53:59 -0500

Laurence Lundblade <[email-masked]> wrote:
    >>> The charter's only stated goal is trustworthiness. This excludes
    >>> device identity, device OEM, device characteristics and such. The
    >>> charter must allow for other than trustworthiness.
    >>
    >> Ned: what is your name?  MCR: "Laurence" Ned: I don't trust your
    >> answer.

    > Q: Verifier, tell me the devices trustworthiness rating:

I personally, find this kind of thing useless.
I wouldn't design a RP/Verifier contract this way at all.

    > Q: Verifier, tell me the device’s name A: I shouldn’t do that because
    > it’s not in the RATS charter

I don't agree with this statement at all.

So far, all of the discussion has been about Evidence has been between the
Attester and Verifier.

I see no reason the Verifier can't tell the RP that it has validated evidence
as to the device's name.  (It might violate PII to tell the RP the device's
actual name, but that's a different problem)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 27 Feb 2022 15:21:13 -0800

Hey Thomas,

Seems like a useful discussion here. See below...

> On Feb 25, 2022, at 3:06 PM, Thomas Fossati <[email-masked]> wrote:
> 
> Hi Laurence,
> 

This made me step back and think about fundamentals.

Agreed — clearly, the RP policy to enforce the geofence, to use the FIDO authentication key and such are not RATS. Also agreed that RATS should not provide application-specific claims.

I think providing authenticated integrity-protected device identity (make, model, serial number) all the way to the RP is part of RATS and the RATS standards should cover it in full standardized detail. (This is akin to providing a user name in authentication protocols and the server identifier in TLS).

I also think providing information about certification to the RP is important. When you want high levels of device trust, certification is important.

RATS must allow for proprietary attestation claims because we won’t be able to standardize all trust-describing claims for all use cases. It probably should provide a way to carry lots of additional application-specific claims.  It should probably also define formats for common ones (e.g., it should define GPS location).

I think this goes far enough beyond attester’s trustworthiness to warrant the additional text about authenticated claims.

> However, I don't feel strongly about this and I'd have no problems

Many use-case specific SW packages will  provide both RATS Verification and RP policy enforcement. FIDO server SW packages do that today (for pre-RATS attestation). Probably the same for lots of simple IoT use cases too.

Or, many businesses will operate both the RATS Verifier and the RP Policy enforcement. For example, something that lets only devices of a certain makes on their network. A business might use a distributed architecture where things are not co-located. What’s important is that it’s the same business, not location.

The separation is critical in the logical architecture, but in practice many implementations won’t follow it. We need to be really clear about that.

LL