Subject: [Rats] Clarifications around Endorsements scope

From: Thomas Fossati <[email-masked]>
Date: Fri, 30 Jul 2021 10:01:28 +0000

Hi all,

Before I go on holiday and my memory is fully reset :-)

During the session yesterday there was a bit of back and forth on jabber
[0] about the scope of endorsements.

It looks like the ARCH phrases the term [1] and illustrates it [2] in a
way that has led people to believe that an endorsement is only scoped to
an instance.

Personally, I think this is a limitation that serves no purpose other
than creating a gap in the conceptual modelling provided by the ARCH -
exemplified by our inability to give a proper name to the DLOA thing -
and I'd like to see it clarified that the definition of endorsement is
orthogonal to the cardinality of the (sub)set of Attesters to which it
applies.

cheers!

PS: I shall note that the CoRIM/CoMID information model builds on the
assumption that endorsements can have instance, class and even "group"
(e.g., an anonymity set) scope.

[0] https://jabber.ietf.org/jabber/logs/rats/2021-07-29.html#20:57:54.659809
[1] https://www.ietf.org/archive/id/draft-ietf-rats-architecture-12.html#section-4.2-1.4.1
[2] https://www.ietf.org/archive/id/draft-ietf-rats-architecture-12.html#name-endorsements

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: Henk Birkholz <[email-masked]>
Date: Fri, 30 Jul 2021 12:30:17 +0200

Hi Thomas,

thank you for highlighting that topic again. I absolutely agree with you 
that limiting Endorsements to instances of things seems to be an 
artificial restriction that I can't actually see a real purpose for.

The use of device as singular in the first half of [2] could be one 
source of the problem. The first half of [2] talks about "key material", 
but it does not state that that "key material" is device unique - yet 
that can apparently one way to read it. [2] later illustrates two 
laptops of the same manufacturer and how Endorsements help there, but 
might not be enough (why additional device-specific) Evidence is needed, 
implying that Endorsements can encompass more than one device.

All that said, it is not the intend of the text to limit an Endorsement 
to a single thing and therefore that is an issue that we will have to 
address in the next review phase. Adding a simple statement that 
expresses the intended scope explicitly would fix the issue, I think.

The DLOA discussion was surprising to me. Even after a few points of 
views where exchanged, the arguments contra DLOA being Endorsements 
still sounded more like pro to me. That might also be an independent 
topic and limited to the EAT Claim?

Viele Grüße,

Henk

On 30.07.21 12:01, Thomas Fossati wrote:
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 30 Jul 2021 10:44:48 -0700

I think an RATS Endorsement is an abstract message that tells a Verifier that it can trust an Attester. Its definition is a RATS concept that is fully bound to the notion of Attester and Verifier. 

While a DLOA could be an Endorsement, a DLOA’s purpose is very different:
As far as I know there is no certification program in existence that certify Attesters. The certification may cover the attester by coincidence, but the purpose today is not to tell a Verifier that an Attester can be trusted.
A DLOA usually covers some HW + SW combination that is an execution environment that could be very large and expansive, far beyond an Attester
Certification programs are not defined in terms of a Verifier and Attester like RATS Endorsements are
Even if a certification reported by a DLOA covers the Attester, that may not be sufficient reason for a Verifier to trust it.
Maybe someday there will be a certification program for particular flavors of RATS Attesters and it’s output will serve as an Endorsement, but certification results reported in a DLOA will always be far more broad-ranging than Endorsements and thus can’t be boxed in by calling them thus.

LL

> On Jul 30, 2021, at 3:30 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Thomas,
> 
> thank you for highlighting that topic again. I absolutely agree with you that limiting Endorsements to instances of things seems to be an artificial restriction that I can't actually see a real purpose for.
> 
> The use of device as singular in the first half of [2] could be one source of the problem. The first half of [2] talks about "key material", but it does not state that that "key material" is device unique - yet that can apparently one way to read it. [2] later illustrates two laptops of the same manufacturer and how Endorsements help there, but might not be enough (why additional device-specific) Evidence is needed, implying that Endorsements can encompass more than one device.
> 
> All that said, it is not the intend of the text to limit an Endorsement to a single thing and therefore that is an issue that we will have to address in the next review phase. Adding a simple statement that expresses the intended scope explicitly would fix the issue, I think.
> 
> The DLOA discussion was surprising to me. Even after a few points of views where exchanged, the arguments contra DLOA being Endorsements still sounded more like pro to me. That might also be an independent topic and limited to the EAT Claim?
> 
> Viele Grüße,
> 
> Henk
> 
>

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 30 Jul 2021 20:52:59 +0000

Hi Laurence,

On 30/07/2021, 19:45, "Laurence Lundblade" <[email-masked]> wrote:
> I think an RATS Endorsement is an abstract message that tells a
> Verifier that it can trust an Attester. Its definition is a RATS
> concept that is fully bound to the notion of Attester and Verifier.

It looks like our understanding of Endorsements is quite different from
mine.

For you an Endorsement is a statement of the form "Endorser tells
Verifier that it can trust Attester".

This look very abstract indeed, and frankly hardly actionable as-is.

Instead, I see Endorsements as statements of the form: "Endorser tells
Verifier that Attester has non-measured attribute X".
Once the Verifier has validated the Endorsement, it can use X as input
in the process of producing Attestation Results related to Evidence
coming from the Attester.

...

The fact that two people like you and me, who have spent a non-trivial
amount of time staring at the ARCH document, can't agree on the meaning
of a base concept seems to suggest we should allocate a few cycles to
try and converge on this and have whatever we converge to clearly stated
in the ARCH doc.

Cheers, t

> * As far as I know there is no certification program in existence that
> certify Attesters. The certification may cover the attester by
> coincidence, but the purpose today is not to tell a Verifier that an
> Attester can be trusted.
> * A DLOA usually covers some HW + SW combination that is an execution
> environment that could be very large and expansive, far beyond an
> Attester
> * Certification programs are not defined in terms of a Verifier and
> Attester like RATS Endorsements are
> * Even if a certification reported by a DLOA covers the Attester, that
> may not be sufficient reason for a Verifier to trust it.
>
> Maybe someday there will be a certification program for particular
> flavors of RATS Attesters and it’s output will serve as an
> Endorsement, but certification results reported in a DLOA will always
> be far more broad-ranging than Endorsements and thus can’t be boxed in
> by calling them thus.
>
> LL

> thank you for highlighting that topic again. I absolutely agree with
> you that limiting Endorsements to instances of things seems to be an
> source of the problem. The first half of [2] talks about "key
> material", but it does not state that that "key material" is device
> unique - yet that can apparently one way to read it. [2] later
> illustrates two laptops of the same manufacturer and how Endorsements
> help there, but might not be enough (why additional device-specific)
> Evidence is needed, implying that Endorsements can encompass more than
> one device.
>
> All that said, it is not the intend of the text to limit an
> Endorsement to a single thing and therefore that is an issue that we
> will have to address in the next review phase. Adding a simple
> statement that expresses the intended scope explicitly would fix the
> issue, I think.
>

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 30 Jul 2021 15:21:23 -0700

> On Jul 30, 2021, at 1:52 PM, Thomas Fossati <[email-masked]> wrote:
> 
> Hi Laurence,

Glad you are being productive during vacation. :-)

> Verifier that it can trust Attester".

Yes, but I’ll revise and say “At minimum, an Endorsement tells the Verifier it can trust an Attester, but the Endorsement may also carry other information, claims and such that help the Verifier do its job and that may be passed on to the Relying Party”.

The minimum is critical. You can’t have functioning attestation unless the Verifier is told it can trust an Attester.

(Maybe Reference Values or Policy could be an alternate to Endorser, but it has to be one of the three).

The architecture draft seems mostly OK on this minimum for an Endorser.

> Verifier that Attester has non-measured attribute X".

That definition seems too limited. For one, you can have Endorsements, attestation and such all with no measurements at all. So Endorsement can’t be defined in terms of measurement.

> coming from the Attester.

Seems fine for data in an Endorsement to flow through the Verifier to the Relying Party, but only as an add-on benefit over trust establishment.

> try and converge on this and have whatever we converge to clearly stated

Part of the trouble here is that Endorsements and other Verifier input are out of scope for RATS so we haven’t whole-heartedly worked on it. (Is CoMID/CoRIM in scope?)

I also think there’s a diverse set of views and understandings on the role of measurement in attestation that may be factoring n here.

LL

---

From: Henk Birkholz <[email-masked]>
Date: Sat, 31 Jul 2021 01:29:43 +0200

Hi Laurence,

> Yes, but I’ll revise and say “At minimum, an Endorsement tells the Verifier it can trust an Attester, but the Endorsement may also carry other information, claims and such that help the Verifier do…

While I think that the phrasing definitely needs more context and 
polish, it is also going into the right direction, I think.

> That definition seems too limited. For one, you can have Endorsements, attestation and such all with no measurements at all. So Endorsement can’t be defined in terms of measurement.

I'd also say that you are right to some extend. An Endorsement (not sure 
what exactly you mean by Attestation here) may include "no measurement 
at all". Concrete Endorsements simply include explicit or implicit 
assertions about an Attester that the Attester itself does not express 
as Evidence. The most prominent example is "trust some parts of the 
Attester" (i.e., the roots of trust). That certainly is not defined in 
terms of measurements that would appear as Claimes in Evidence, I think. 
That also does not exclude the possibility, that measurements about the 
Attester not generated in the form of Evidence by the Attester can be 
included in an Endorsement, too.

In (maybe very abstract) theory, an Attester does not have to include 
meaningful Claims in Evidence at all and could only be endorsed by a 
simple "trust that Attester" Endorsement. If that is actually still 
remote attestation is obviously debatable - at the very least there is 
literally no effective Evidence about the Attester's trustworthiness and 
according Attestation Results should be handled with a corresponding... 
low level of assurance.

While I think that Thomas' statement about "Endorser tells Verifier that 
Attester has non-measured attribute X" includes that "Endorsement only" 
scenario, I am also rather sure he might not... endorse that or he might 
not have intended to include my rather extreme interpretation here :-)

It is late here, if I were more awake, I might have been able to whip up 
a more concise reply.

Viele Grüße,

Henk

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 31 Jul 2021 12:33:50 -0700

> On Jul 30, 2021, at 3:21 PM, Laurence Lundblade <[email-masked]> wrote:
>> 

Here’s the near-minimal attestation system I can think of. Its purpose is identification of individual HW devices kinda like a stripped down IDevID:

- The endorsement is just a bare public key
- The only claim in attestation evidence is the UEID
- There is of course a nonce in the system for freshness

So
- There is no measurement involved
- Nothing from the endorsement goes into attestation results

> Part of the trouble here is that Endorsements and other Verifier input are out of scope for RATS so we haven’t whole-heartedly worked on it. (Is CoMID/CoRIM in scope?)

I wrote this <https://mailarchive.ietf.org/arch/msg/rats/iokP8oZ6VMuPt2PI6WCXyhCmQHE/> a year ago, a definition of verifier input that avoided the term endorsement because it means different things to different people. It is a listing of the main inputs to a verifier (which isn’t very long). I recall part of the reason this level of detail wasn’t pursued is because endorsements are out of scope per the RATS charter.

Another thing that would be super useful would be a good set of system examples.

LL