Subject: Re: [Rats] attester vs measurement target (was Re: Use the term "attester" instead of root of trust)

From: Giridhar Mandyam <[email-masked]>
Date: Mon, 2 Sep 2019 16:04:24 +0000

> I recommend reading Practical Principles for Computer Security, Butler Lampson, Microsoft Research, January, 2007 [4]

I have seen this document before, and it is quite informative and definitely described several concepts that have been used in FIDO/Authentication work.  What specific aspects of terminology from this document are you recommending we leverage?  For instance I found concepts that could be useful for attestation, but I did not find a specific description of an attester, appraiser, or target measurement.  Also, if concepts from the Lampson doc were leveraged for the RAts architecture doc then why is this not mentioned in the references?

For instance, I tried to see if an attester can be considered a “token source” (Sec. 5.2) but in reading this section I do not believe that was the intention of the author.  I tried to see if the “speaks-for engine” (Sec. 5.3) can encompass the role of the entity that measures a target, but I believe author was intending this engine to also fulfil the role of a verifier (token consumer “The job of the speaks-for engine is to derive conclusions about what principals are trusted, starting from claims and adding information derived from tokens”).

> At some point consistency is a hobgoblin.

To complete the Thoreau quote then, I hope you are not saying I am a “little mind”.  I don’t believe what I was suggesting was to slavishly adhere to previously-published definitions of attester, target of measurement, etc.  What I was suggesting was to start with commonly-accepted definitions, justify why they may need to be modified, and come up with a terminology suitable for the working group.  It seems that much of this discussion starts with the assumption that there are no commonly-accepted definitions for the terms used in the architecture document.

>The most important objective of terminology for RATS WG (IMHO) is to be able to not talk past one another. After that, we can agree on whatever industry term is most appropriate.

I don’t think anyone is arguing about the need for terminology based on what I’ve observed.  I just think it is not constructive when we assume a clean slate for all terms, and try to build up definitions from scratch.

-Giri

From: Smith, Ned
Sent: Saturday, August 31, 2019 6:02 PM
To: Ira McDonald ; Giridhar Mandyam
Cc: Laurence Lundblade ; [email-masked]
Subject: Re: [Rats] attester vs measurement target (was Re: Use the term "attester" instead of root of trust)

I recommend reading Practical Principles for Computer Security, Butler Lampson, Microsoft Research, January, 2007 [4]
This is very relevant to attestation and introduces useful terminology, much of which aligns with the goals of attestation architecture.
It predates some of the references given below.
At some point consistency is a hobgoblin. The most important objective of terminology for RATS WG (IMHO) is to be able to not talk past one another. After that, we can agree on whatever industry term is most appropriate.

Specific responses to Laurence’s remarks are inline below prefaced with [nms].
-Ned
[4] https://www.microsoft.com/en-us/research/publication/practical-principles-for-computer-security/
On 8/30/19, 14:21 PM, "Ira McDonald" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

+1 to Girii's comments and suggestions.  Reinventing terminology
(the curse of the computer industry) leads to automatic cognitive
disconnects and confusion and benefits no one.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
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]>
PO Box 221  Grand Marais, MI 49839  906-494-2434

On Fri, Aug 30, 2019 at 3:58 PM Giridhar Mandyam <[email-masked]<mailto:[email-masked]>> wrote:
I am not sure why we are trying to re-define terms that have already been defined in the literature.  In my review on the -01 version of the architecture doc [1], I cited a couple of papers where terminology had been addressed [2]-[3].  I wonder if the RATS architecture editors did a complete literature review prior to the creation of this document, and if so whether they can provide a justification as to why they rejected previous approaches to defining attestation terminology and architecture.
In particular, [2] has the following text:
“Terminology. An appraiser is a party, generally a computer on a network, making a decision about some other party or parties. A target is a party about which an appraiser needs to make such a decision.”
“Terminology. Attestation is the activity of making a claim to an appraiser about the properties of a target by supplying evidence which supports that claim. An attester is a party performing this activity. An appraiser's decision-making process based on attested information is appraisal.”
“Terminology. To measure a target means to collect evidence about it through direct and local observation of it.”
[1] https://mailarchive.ietf.org/arch/msg/rats/9iIrnD9YixKCuwOGKtvGZIzd_bU.

[2] Coker, George et al.  "Principles of Remote Attestation."  International Journal on Information Security.  Vol. 10.  No .2.  2011.  pp. 63-81.  Available at http://web.cs.wpi.edu/~guttman/pubs/remote_attest.pdf.

[3] J. Guttman et al.  ""Attestation:  Evidence and Trust".  MITRE Technical Report MTR080072.  March 2008. https://www.mitre.org/sites/default/files/pdf/07_0186.pdf.

-Giri Mandyam
From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Laurence Lundblade
Sent: Friday, August 30, 2019 12:36 PM
To: Smith, Ned <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Rats] attester vs measurement target (was Re: Use the term "attester" instead of root of trust)

CAUTION: This email originated from outside of the organization.
Changed the subject as I want to reorient the discussion a bit. Apologies if this is all obvious to you.
When measurements are being performed there is the subsystem that is doing the reporting / measuring and the subsystem that is being measured. [nms] +1
I think the attester is the subsystem that is doing the reporting. It generates and formats the claims, has the signing key and does the signing. [nms] +1
I am calling the subsystem that is being measured the measurement target. I am proposing that the attester measures the measurement target in RATS architecture.
[nms] The semantics of ‘attester measures the measurement target’ seems correct to me. Based on the definitions I’ve seen for “entity” it seems correct to say a ‘measurement target’ is an entity. It seems correct to say the ‘attester is an entity’ too. But they are different entities. Since an entity can be lots of things and we need to disambiguate what is relevant to attestation, the architecture introduced the idea of role names. We chose ‘attester’, ‘verifier’, ‘relying party’ and ‘asserter’. There are many possible alternative synonymous or nearly synonymous choices to be found in an English dictionary and in computer security literature. The role names are just place holder names for now, IMO. If RATS WG prefers using different strings then these then some alternatives can be proposed. I’m OK using these for now as place holders that allow the group to discuss RATS roles semantics.
Going back to measurement target, I don’t think ‘measurement target’ conceptually would be a RATS role since it is being acted upon rather than doing something.
Note: Butler Lampson’s paper [4] uses ‘Principal’ to name entities that can ‘say’ something  (e.g. “X”) or can ‘speak-for’ another Principal. Using Lampson’s terminology, the semantic is “the Principal named ‘Attester’ measures the Object named ‘Measurement target’.” Since the goal of the architecture is to provide a meta model for attestation behavior, it makes sense to use place holder names ‘Attester’ and ‘Measurement Target’ rather than actual instance names. BTW: Lampson clarifies that Objects are also Principals because of the identity property. This allows anything to say what it is. I.e. X says X. Ultimately ‘measurement target’ is just a placeholder name for an Object that is “the target of a measurement operation”. Maybe the RATS WG is happier with a different string than “measurement target”, but we should have some alternative suggestions first (so long as they don’t change intended semantics).
For the measurement to be of best value, there must be isolation between the attester and the measurement target. For example the attester doing the measurement should be a TEE, TPM or such. The measurement target is usually the HLOS like Linux or Windows.
[nms] +1. I think it is obvious that the Attester, though isolated from the Measurement Target (MT) is nevertheless able to observe it.
The point of measurement is so that attacks against the measurement target can be detected. If there is no isolation, the attacker that succeeds against the measurement target is likely to be go on to affect the attester and then the evidence (e.g. measurement claims in an EAT token) can be manipulated.
[nms] +1
In some architectures the manufacturer of the attester will be different than the manufacturer of the measurement target. For example a TPM is made by a TPM chip vendor. A TEE is made by a SoC vendor. These are different than the HLOS vendor, the vendor of Windows, Linux or the router’s OS.
[nms] +1
The verifier role primarily needs two thing to successfully verify measurement evidence.

1)      They need the public key to verify the signature generated by the attester and to know that the key is trusted and probably some implied claims.
[nms] Verifier needs to trust Attester. The trust path can be modeled using Lampson. See Figure 4 in [4] as it seems pretty close to describing how this works for your example involving both keys and implied claims.

  1.  They need the reference values for what is being measured. For example, the expected values for Linux kernel 5.x on x86 or such.
[nms] Verifier also needs to trust that “Asserters” who claim that their assertions are ‘golden’ or ‘known good’ or ‘reference’ values. This is another conversation the Verifier has that needs a trust path as exemplified in [4], figurer 4.
I think 1) and 2) are likely to come from different manufacturers and thereby might be depicted as separate roles in the architecture.
[nms] I disagree that RATS roles need to change because the entities performing the role differs. It is a case of multiple entities performing the same function (that produces the same class of output).

1)      requires the out-of-band trust role. A RATS system without 1) (above?) is not very secure and not something we want to put in our architecture.
[nms] The idea that ‘an entity is more secure than X’ is actually a determination a Relying Party should make. Attestation should supply it with information that allows the evaluation to take place.

  1.  requires the reference-value supplier role. Some RATS systems will have 2) (above?) and some will not. You can have a RATS system without 2). Android Key Store and FIDO’s use of attestation are examples.
[nms] Currently, the RATS architecture is using ‘Asserter’. Though in past revisions it was ‘Claimant’. Neither of these seem perfect. Although, it seems the majority of cases where Assertions from Asserters will be supply chain entities, there are cases (e.g. virtualized environments) where non-supply-chain entities take on the Asserter role. It would be great if RATS WG could find single word role names as this makes talking about them easier and reduces the need for acronyms.
The verifier has to have a trust relationship with both the manufacturer of the attester and the manufacture of the HLOS.
[nms] I don’t recall what HLOS means (expands to).
Or perhaps I should call these two the attestion asserter and the reference-value asserter. (I prefer manufacturer because “asserter” is too close to “attester”, is fairly abstract and has some confusion around it for me).
[nms] Are you suggesting ‘Supplier’? Some have suggested ‘Endorser’.
LL

On Aug 23, 2019, at 12:53 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

[snip]

I think the out-of-band trust role is much more important than the reference-value-supplying role.
[nms] I may not understand what you mean by these terms “out-of-band trust role” and “reference-value-supplying role”. Generally, they appear to fit in the “Asserter role” side of the diagram Henk displayed at 105 session #2.

You can have real attestation without reference values. For example, most claims can be implicit. The entity has secure boot and can be assumed to perform correctly. Maybe the only claim is location.
[nms] I agree the Verifier role needs to somehow know which claims / assertions of trustworthiness apply to the Attester and that not all claims must be conveyed as Evidence. A definition of implicit attestation might suggest all assertions of trustworthiness could be conveyed via an out-of-band channel (where out-of-band refers to a conveyance that isn’t the one carrying Evidence). Recall, that the RATS WG deemed definition of Asserter / Assertions out of scope for now. Of course the architecture can talk about them. Hence, it is in scope to say that Evidence could be as simple as a Nonce claim and a Verifier could conclude that the Nonce + OOB claims = effective claim set. More concretely, the Evidence claims set (E) + (union) the Assertions claims set (A) = effectiVe claims set (V).
I’m not sure if you are also suggesting that implicit could mean something other than explicitly described Assertions. For example, Asserter and Verifier could meet at a coffee shop and agree that whenever a certificate path resolves to the trust anchor for the Asserter that claims set (S) also can be inferred. Hence, V = (S + A + E). The charter limitation implies we can define drafts that define E for the Attester and Verifier roles and S and A for the Verifier role only and not how Verifier obtains (S, A).

If you don’t have the [1] out-of-band trust, the measurements are worthless, so the architecture is incomplete if it just has a role that provides reference values.
                                [nms] Right. The architecture should assume that role entities have valid credentials (e.g. certificates + private key) and that the Verifier can resolve that it trusts the role entities’ credentials (somehow). If ‘out-of-band’ [1] means Asserter(s) then their Assertions (measurements) are expected to be their “provable assertions”; where provable means signed by the Asserter’s credential key.
[nms] We might want to qualify “Assertions” as “Provable Assertions” in the architecture to make it clear that there is a way for the Verifier to accept them without blindly trusting an assertion given to it. This would also qualify it in terms of an ISO/IEC terminology that defines Assertion as ‘a statement that is not necessarily provable’.
                                [nms] We could have a discussion about the veracity of Asserter(s)’ credentials. But I think it ends up being a recursion of the RATS architecture. This isn’t an interesting rat hole (pun intended), except for being convinced that the recursion terminates. For example, with some sort of trust anchor provisioning protocol or manual process (see [snip]).

I hope we can get to a clear architecture with all of this laid out. I think it will help cut through a lot of confused conversations.
[nms] +1

LL

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

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 2 Sep 2019 09:18:53 -0700

> On Sep 2, 2019, at 9:04 AM, Giridhar Mandyam <[email-masked]> wrote:
> 

I’d like to:
- re use terminology exactly "as is" when possible
- in some cases re use, but  refine and clarify for our needs
- if neither of those work, use new terminology

LL

---

From: "Oliver, Ian (Nokia - FI/Espoo)" <[email-masked]>
Date: Mon, 2 Sep 2019 19:29:47 +0000

Agree, but we can be much more precise in the descriptions of these terms.

Measurement target and attester to me are very different things.  An attester is something that attestst. A measurement target I'm not so sure of.  For example, is a server a measurement target, or is something that stores measurements, like a TPM, a measurement target?

t.

Ian

--

Dr. Ian Oliver

Cybersecurity Research

Distinguished Member of Technical Staff

Nokia Bell Labs

+358 50 483 6237

________________________________
From: Laurence Lundblade <[email-masked]>
Sent: 02 September 2019 19:18
To: Giridhar Mandyam <[email-masked]>
Cc: Smith, Ned <[email-masked]>; Ira McDonald <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Rats] attester vs measurement target (was Re: Use the term "attester" instead of root of trust)

On Sep 2, 2019, at 9:04 AM, Giridhar Mandyam <[email-masked]<mailto:[email-masked]>> wrote:

I’d like to:

LL

---

From: Ira McDonald <[email-masked]>
Date: Mon, 2 Sep 2019 16:00:09 -0400

Hi Ian,

Measurement Target to me implies something like a Common Criteria
TOE (Target of Evaluation), i.e., the entity that is measured, *not* the
entity that is doing measurement or recording the measurement (such
as a TPM).

Cheers,
- Ira

mailto: [email-masked]

On Mon, Sep 2, 2019 at 3:29 PM Oliver, Ian (Nokia - FI/Espoo) <
[email-masked]> wrote:

> Measurement target and attester to me are very different things.  An
> attester is something that attestst. A measurement target I'm not so sure
> of.  For example, is a server a measurement target, or is something that
> stores measurements, like a TPM, a measurement target?
>
> t.
>
> Ian
>
>
>
> --
>
> Dr. Ian Oliver
>
> Cybersecurity Research
>
> ------------------------------
> *From:* Laurence Lundblade <[email-masked]>
> *Sent:* 02 September 2019 19:18
> *To:* Giridhar Mandyam <[email-masked]>
> *Cc:* Smith, Ned <[email-masked]>; Ira McDonald <
> [email-masked]>; [email-masked] <[email-masked]>
> *Subject:* Re: [Rats] attester vs measurement target (was Re: Use the
> term "attester" instead of root of trust)
>
>
> I don’t think anyone is arguing about the need for terminology based on
> what I’ve observed.  I just think it is not constructive when we assume a
> clean slate for all terms, and try to build up definitions from scratch.
>
>
> I’d like to:

---

From: "Oliver, Ian (Nokia - FI/Espoo)" <[email-masked]>
Date: Mon, 2 Sep 2019 20:07:14 +0000

Thanks, this makes sense.

Ian

--

Dr. Ian Oliver

Cybersecurity Research

Nokia Bell Labs

+358 50 483 6237

________________________________
From: Ira McDonald <[email-masked]>
Sent: 02 September 2019 23:00
To: Oliver, Ian (Nokia - FI/Espoo) <[email-masked]>; Ira McDonald <[email-masked]>
Cc: Laurence Lundblade <[email-masked]>; Giridhar Mandyam <[email-masked]>; Smith, Ned <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Rats] attester vs measurement target (was Re: Use the term "attester" instead of root of trust)

Hi Ian,

Cheers,
- Ira

On Mon, Sep 2, 2019 at 3:29 PM Oliver, Ian (Nokia - FI/Espoo) <[email-masked]<mailto:[email-masked]>> wrote:
Agree, but we can be much more precise in the descriptions of these terms.

t.

Ian

--

Dr. Ian Oliver

Cybersecurity Research

Nokia Bell Labs

+358 50 483 6237

________________________________
From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Sent: 02 September 2019 19:18
To: Giridhar Mandyam <[email-masked]<mailto:[email-masked]>>
Cc: Smith, Ned <[email-masked]<mailto:[email-masked]>>; Ira McDonald <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] attester vs measurement target (was Re: Use the term "attester" instead of root of trust)

I’d like to:

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 2 Sep 2019 15:40:30 -0700

Hi Ian,

> On Sep 2, 2019, at 12:29 PM, Oliver, Ian (Nokia - FI/Espoo) <[email-masked]> wrote:
> 

Yes, we’ve got a ways to go yet. When we’re done (or close to it) we’ll have general consensus on the architecture document and all the terms in it. Should include references to previous definitions.  We’ll be directing comments and filing issues directly against a document.

> 
> Measurement target and attester to me are very different things. 

Yes, they are very different.

> An attester is something that attestst. A measurement target I'm not so sure of.  For example, is a server a measurement target, or is something that stores measurements, like a TPM, a measurement target?

The measurement target is what is being measured. Typically it is the SW and memory that is being hashed. 

In something like IMA <https://sourceforge.net/p/linux-ima/wiki/Home/> or TIMA <https://www.engr.ncsu.edu/news/2014/11/19/tima-technology-is-core-to-samsungs-state-of-the-art-knox-platform/> that is measuring Linux with TrustZone, Linux is the measurement target. The memory and/or code space and/or file space of the Linux OS and often Android is hashed. 

Some SW running in TrustZone is what is doing the measuring and the attesting. It is not the measurement target. TrustZone HW allows SW running in TrustZone to access all of Linux, but not vice versa. 

I tend to shy away from TPM/Windows examples because I don’t know it so well, but I would guess the TPM chip is the attester and Windows and parts of the boot sequence are the measurement target.

LL

>> On Sep 2, 2019, at 9:04 AM, Giridhar Mandyam <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Oliver, Ian (Nokia - FI/Espoo)" <[email-masked]>
Date: Tue, 3 Sep 2019 07:24:41 +0000

<quote>

In something like IMA<https://sourceforge.net/p/linux-ima/wiki/Home/> or TIMA<https://www.engr.ncsu.edu/news/2014/11/19/tima-technology-is-core-to-samsungs-state-of-the-art-knox-platform/> that is measuring Linux with TrustZone, Linux is the measurement target. The memory and/or code space and/or file space of the Linux OS and often Android is hashed.

</quote>

More thinking of this, sticking with the practical x86/TPM example for the moment - this generalises to other architectures and situations of course.

The Root of Trust is the code that measures the code that starts the systems, the initial read-only part of BIOS (and the measurement code itself). This code is also the measurement target. The next step is the storage of this measurement in a secure place, ie a TPM PCR (PCR 0).

After boot/measurement has been completed, the Root of Trust is then the TPM itself.

The TPM does not attest anything, but provides a mechanism for delivering an "attestation token" (in this case the TPMS_ATTEST structure) in a secure form, ie: signed by the TPM AK.

The attester in an external entity that requests this proof and verifies it against a known good value.

OK, in TPM 1.2 the launch control policy mechanism could perform local attestation (not so much used in TPM 2.0) - this could be considered an attester and verifier, just packaged on the same piece of silicon.

Ian

--

Dr. Ian Oliver

Cybersecurity Research

Nokia Bell Labs

+358 50 483 6237

________________________________
From: Laurence Lundblade <[email-masked]>
Sent: 03 September 2019 01:40
To: Oliver, Ian (Nokia - FI/Espoo) <[email-masked]>
Cc: Giridhar Mandyam <[email-masked]>; Smith, Ned <[email-masked]>; Ira McDonald <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Rats] attester vs measurement target (was Re: Use the term "attester" instead of root of trust)

Hi Ian,

On Sep 2, 2019, at 12:29 PM, Oliver, Ian (Nokia - FI/Espoo) <[email-masked]<mailto:[email-masked]>> wrote:

In something like IMA<https://sourceforge.net/p/linux-ima/wiki/Home/> or TIMA<https://www.engr.ncsu.edu/news/2014/11/19/tima-technology-is-core-to-samsungs-state-of-the-art-knox-platform/> that is measuring Linux with TrustZone, Linux is the measurement target. The memory and/or code space and/or file space of the Linux OS and often Android is hashed.

LL

t.

Ian

I’d like to:

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 8 Sep 2019 11:33:43 -0700

Thanks for writing that out...

> On Sep 3, 2019, at 12:24 AM, Oliver, Ian (Nokia - FI/Espoo) <[email-masked]> wrote:
> 

That definition of attester seems quite different from the one in draft-birkholz-rats-architecture-01 <https://tools.ietf.org/html/draft-birkholz-rats-architecture-01> and from the definition I’m advocating. Here’s the main part of the definition from draft-birkholz-rats-architecture-01 <https://tools.ietf.org/html/draft-birkholz-rats-architecture-01>

   Attester:  The producer of attestation evidence that has a root of
      trust for reporting (RTR) and implements a conveyance protocol,
      authenticates using an attestation credential, consumes assertions
      about itself and presents it to a consumer of evidence (e.g. a
      relying party or a verifier).  Every output of an attester can be
      appraised via reference values.

By this definition, it seems like the attester is the TPM and boot code that is tightly associated with the entity.  Attestation Evidence is signed token, TPMS_ATTEST.

The RATS definition of Verifier is:

   Verifier:  The consumer of attestation evidence that has a root of
      trust for verification (RTV), implements conveyance protocols,
      appraises attestation evidence against reference values or
      policies, and makes verification results available to relying
      parties.

So, approximately, RATS Attester == TCG RTR and RATS Verifier == TCG Attester?  

Seems an unfortunate overlap of terms. Explains some of the confusion we encounter. I don’t have any better ideas so far...

LL

---

From: "Oliver, Ian (Nokia - FI/Espoo)" <[email-masked]>
Date: Sun, 8 Sep 2019 19:46:35 +0000

I agree with that assertion. Just to add to the confusion, the role of some elements does change over time.

For example, one boot is complete on an x86 architecture, the TPM itself is now the root of trust and the measurement code in the BIOS does not take any more part in the process, thus the TPM is now the root-of-trust for reporting.

It is the "for reporting" that seems to be key here and I don't think these additional terms have been listed yet?

I agree with the Attestation Evidence being the TPMS_ATTEST structure/token.

The RATS definition verifier is interesting, as in the TPM case we have two possibilities.

  1.  use of LCPs, where the TPM itself is both ROT for reporting and ROT for verification
  2.  use of external ROT for verification (attestation server possibly?) and the TPM is the ROT for reporting.

t.

Ian

--

Dr. Ian Oliver

Cybersecurity Research

Nokia Bell Labs

+358 50 483 6237

Sent: 08 September 2019 21:33

On Sep 3, 2019, at 12:24 AM, Oliver, Ian (Nokia - FI/Espoo) <[email-masked]<mailto:[email-masked]>> wrote:

That definition of attester seems quite different from the one in draft-birkholz-rats-architecture-01<https://tools.ietf.org/html/draft-birkholz-rats-architecture-01> and from the definition I’m advocating. Here’s the main part of the definition from draft-birkholz-rats-architecture-01<https://tools.ietf.org/html/draft-birkholz-rats-architecture-01>

LL