Subject: [Rats] Comments on draft-birkholz-rats-architecture-01

From: Thomas Hardjono <[email-masked]>
Date: Sun, 7 Jul 2019 15:17:26 +0000

Here are some comments on draft-birkholz-rats-architecture-01.

There are several typos in the text,  but I will focus on some of the more fundamental questions.

(a) Abstract:

>>> the goal of the RATS Architecture is
>>> to enable interoperable interaction between the RATS Roles. Hence,
>>> the RATS Architecture is designed to enable interoperability via
>>> well-defined semantics of the information model (attestation
>>> assertions/claims),...

Is it true/correct that RATS will address the semantics of the information model (and not just the syntax).

The issue of trust semantics goes very deep into the architecture of the hardware and platform, so much so that  I don't think (correct me) it is practical to compare between two hardware manufacturer platforms (e.g. Intel based PC versus Qualcomm-based iPhones) .  The best that can be achieved (correct me) is that there is a paired-matching between the Computing-Context measured/reported by the device (Attester) and the Computing-Context information (manifest) issued by the Asserter (platform or device manufacturer) and accessible to the Verifier.  The Verifier must somehow know (detect) the differences in Computing-Contexts between two distinct platforms/devices. 

Or did I misunderstand the usage of the term "semantics" in this document.

(b) Page 4

>>> One of the goals of the RATS Architecture is to provide the building
>>> blocks - the roles defined by the RATS Architecture - to enable the
>>> composition of service-chains/hierarchies and work-flows that can
>>> create and appraise evidence about the trustworthiness of devices and
>>> services.

The notion of "service-chains" or assertion-chains needs to be defined clearly (maybe in the next draft).  In fact, service-chains is a topic that is barely discussed in this draft-01.

(c) Page 5 top:

>>> Mandatory and optional trust relationships between its Roles, that
>>> may assume a Root-of-Trust context,

This one is confusing I think, because perhaps of the word "optional".

One of the outcome of a successful RATs interoperability scenario is to enable the establishment of trust (based on the observance of RATS-defined remote attention procedures) between the Asserter and Verifier.

(d) Page 5 Section 3.1 on RATS Role.

>> Claimant:

I'm assuming we going with the word "Asserter" instead of Claimant.

(e) Page 6 second paragraph:

>>> ... supply chain entities (SCE)...

Supply chain entities need to be defined.  Does this mean supply chain of components that make-up a platform (e.g. OEMs), or does it mean something else.

(f) Page 6 third pa paragraph a:

>>> Attester: The producer of attestation evidence that has a root of trust for reporting (RTR)

Why only the RTR?  I would have thought that the Attester (e.g. my device) must also have an RTM.

(g) Page 7, last paragraph:

>>> In general, and RATS Duties are typically associated with a
>>> RATS Role. The list presented in this document is exhaustive.

Did you mean "exhaustive" or "non-exhaustive"

(h) Page 8, Section 4.1.2:

>>> Acquisition and storage of appraisal policies

The term "appraisal policies" needs to be defined.  Dos it mean "processing rules" ? (akin to the X509 cert policies which define the ways to process received certs).

>>> Verification of Attester Identity (attestation provenance)

Is this a typo?  An "Attester Identity" is not the same as the provenance of attestations.

(i) Page 12 first paragraph:

>>> In essence, the
>>> attestation provenance of attestation evidence is the system that
>>> intends to present its trustworthiness in a believable manner.

This sentence sounds circular, but I think I get the intent.

Should it read something like:  The provenance of the attestation-evidence of a given system originates from the system itself, and pertains to the trustworthiness of the system.  It must be presented in a believable manner by the system to external entities, namely the Verifiers and Relying Parties.

(j) Page 12 fourth paragraph:

>>> If the root of trust involved is a root of trust for measurement
>>> (RTM), the producer of information takes on the role of a asserter.

Is this a typo?  Should this instead read ".. the role of an *Attester" (because an Attester, not the Asserter, has the RTM and possibly RTR).

(k) Page 15 Section 7.1

The Lying Endpoint Problem text should be placed in the Use Cases document, not in the Architecture doc.

The entire reason we have RATS (and indeed the whole notion of Remote Attestations) is largely due to the The Lying Endpoint Problem.

(l)  Page 21 section 8.1:

This paragraph is a good explanation of remote attestations because it talks about "telemetry", which seems core to network devices.

Perhaps this paragraph could be moved up front towards the start of the document.

(m) Page 22 Section 8.4:

>>> Claim: Structured Evidence asserted about a Computing Context. It
>>> contains metadata that informs regarding the type, class,
>>> representation and semantics of Evidence information. A Claim is
>>> represented as a name-value pair consisting of a Claim Name and a
>>> Claim Value

Firstly, I would avoid the use of the term "Claim" because it is already used in higher layer protocols and other organizations. The term "Assertion" is good enough for RATS.

Secondly, is the goal/deliverable for RATS to define these name-value pairs? (for both RTMs and RTRs).

The TCG uses the term "manifest" to indicate the list of expected compliments and measurements in the platform, produced by the Asserter (e.g. device manufacturer).

(n) Page 23 second-last paragraph:

>>> Activity: A sequence of actions conducted by Computing Contexts
>>> that compose a Remote Attestation procedure.

Should RATS care about the "activity" or actions of s given device or platform (that concludes in the generation of an attestation).  Isn't activities/actions internal to the device and the device-manufacturer.

(o) Other comments:

The diagrams from the RATS architecture presentation at IETF104 are excellent ("Evolution of RATS Architecture" and "RATS WG Scoping").  It would be good to have them represented somehow in ASCII.

-- thomas --

---

From: Nicolae Paladi <[email-masked]>
Date: Mon, 8 Jul 2019 14:44:56 +0000

Hello,

Some comments on draft-birkholz-rats-architecture-01<https://tools.ietf.org/html/draft-birkholz-rats-architecture-01>

3.1. RATS Roles

 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.

Root of trust for verification (RTV) is neither defined, nor introduced nor referenced anywhere in the document.

4.1.4 Relying party Duties

Evaluate assertions/evidence locally as far as possible

- The formulation  is inadequate and looks like a “wish” rather than a duty; rephrasing “as far as possible” can fix it;
- What is the difference between Evaluate vs Appraise for a Relying party? *Evaluate* becomes redundant after reading 4.1.5 RATS Interactions - paragraph “Attester/Relying Party”:

A Relying Party typically requires external help to either validate authentication information or to appraise evidence presented by an Attester.

4.1.5<https://tools.ietf.org/html/draft-birkholz-rats-architecture-01#section-4.1.5>.  RATS Interactions

Attester/Relying-Party:  A Relying Party typically requires external help to either validate authentication information or to appraise evidence presented by an Attester.  In most cases, a Relying Party requires a corresponding Verifier to process the assertions/evidence received.  In consequence, (a subset of) the information received by an Attester must be relayed securely to a Verifier.

- “Received by” seems to be incorrect here; while the Attester “consumes assertions about itself” (as per 3.1:Attester), it seems more reasonable that the authors meant “sent by”? Otherwise the sentence should bine rewritten to make it clearer.

5.1. Trust and Trustworthiness

If the root of trust involved is a root of trust for measurement (RTM), the producer of information takes on the role of a asserter. An asserter can also make use of a root of trust for integrity (RTI) in order to increase the level of assurance in the assertions produced.  If the root of trust involved is a root of trust for reporting (RTR), the producer of information takes on the role of an attester.

Unless the asserter role is not a “first class” RATS role, it makes sense to describe it   already in "3.1 RATS Roles”

5.2. Claims and Evidence

The RATS asserter role produces measurements about the system’s characteristics in the form of signed (sometimes un-signed) claim sets in order to convey information.

“Sometimes un-signed” introduces a great deal of uncertainty without further explanation. The difference between signed and unsigned claim sets will have implications on the trustworthiness of the system and needs to be explained in more depth.

   The RATS asserter role produces measurements about the system's
   characteristics in the form of signed (sometimes un-signed) claim
   sets in order to convey information.  A secret signing key is
   required for this procedure, which is typically stored in a shielded
   location that can be trusted, for example, via a root of trust for
   storage (RTS).

   The RATS attester role produces signed attestation evidence in order
   to convey information.  The secret key required for this procedure is
   stored in a shielded location that only allows access to that key, if
   a specific operational state of the system is met.  The trust with
   respect to this origination is based on a root of trust for
   reporting.

The two paragraphs are at least partly overlapping.

5.3. RATS Information Flows

There are six roles defined in the RATS architecture.

This seems to imply that “asserter” is a RATS role and should be defined in 3.1

iFigure 2 provides a simplified overview of the RATS Roles defined above

Only four roles are included in the figure. Was that intended?

7.1.1<https://tools.ietf.org/html/draft-birkholz-rats-architecture-01#section-7.1.1>.  How the RATS Architecture Addresses the Lying Endpoint Problem

 RATS imply the involvement of at least two players (roles) who seek
   to overcome the lying endpoint problem.  The Verifier wishes to
   consume application data supplied by a Computing Context.  But before
   application data is consumed, the Verifier obtains Attestation
   Evidence about the Computing Context to assess likelihood of poisoned
   data due to endpoint compromise or failure.  Remote Attestation
   argues that a systems's integrity characteristics should not be
   believed until rationale for believability is presented to the
   relying party seeking to interact with the system.

“Likelihood” implies a probabilistic approach to trustworthiness (e.g. 42% likelihood of poisoned data”). Is that really feasible? And if so, is it actually of any use? IMO trustworthiness is binary (“trustworthy or not trustworthy”), or binary and conditional/contextual (“trustworthy if used for certain actions”).

8.1.1<https://tools.ietf.org/html/draft-birkholz-rats-architecture-01#section-8.1.1>.  Characteristics of a Computing Context

Computing context characteristics provide the following: * An
      independent environment in regard to executing and running
      software, * An isolated control plane state (by potentially
      interacting with other Computing Contexts),

It remains unclear - an environment independent of what? Is a TPM equally independent as a container and as an SGX enclave or a standalone discrete device? Likewise for “isolated”.

Computing context characteristics do not necessarily include a
   network interface with associated network addresses (as required by
   the definition of an endpoint) - although it is very likely to have
   (access to) one.

It is not clear what definition of endpoint the authors refer to.

8.3. Core RATS Terminology

   $ Remote Attestation:  A procedure involving Attestation, Conveyance
      and Verification.

Is remote attestation _exclusively_ consist of Attestation, Conveyance and Verification, or does it _involve_ them among other actions?

 $ Attested (Asserted) Claim:  An Attestable Claim where the proof
      elements are populated.

   $ Evidence (Claims) Creation:  Instantiation of Attested Claims by a
      Claimant.

   $ Evidence (Claims) Collection:  Assembling of Attested Claims by an
      Attester for the purpose of Conveyance.

   $ Verified (Valid) Claim:  An Attested Claim where the proof elements
      have been verified by a Verifier according to a policy that
      identifies trusted Claimants and/or trusted Evidence values.

The terms in parenthesis (Asserted, Claims, Claims, Valid) seem to be redundant. It is not clear what is their purpose.

Misc. comments, throughout the document:

● AttestEr and AttestOr are used concurrently. I suggest to stick to “AttestEr”.

—
Nicolae Paladi,
RISE Research Institutes of Sweden

On 7 Jul 2019, at 17:17, Thomas Hardjono <[email-masked]<mailto:[email-masked]>> wrote:

(a) Abstract:

(b) Page 4

(c) Page 5 top:

Claimant:

In essence, the

(k) Page 15 Section 7.1

(l)  Page 21 section 8.1:

(m) Page 22 Section 8.4:

(o) Other comments:

-- thomas --

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 12 Jul 2019 21:38:17 -0500

Cherry-picking one point...

> Some comments on draft-birkholz-rats-architecture-01<https://tools.ietf.org/html/draft-birkholz-rats-architecture-01>
[...]
> “Likelihood” implies a probabilistic approach to trustworthiness (e.g. 42% likelihood of poisoned data”). Is that really feasible? And if so, is it actually of any use? IMO trustworthiness is binar…

My personal thinking here is along the lines of "this data makes me
confident that only someone who was able to subvert my supply chain and
surreptitiously replace the TPM chip in the sealed device delivered to me
would be able to forge the attestation evidence; I don't think I'm the
target of such an attack, so there's a low likeliyhood of endpoint
compromise".  Or, as James Mickens put it more glibly in
https://www.usenix.org/system/files/1311_05-08_mickens.pdf there's a
Mossad/not-Mossad distinction in the potential attackers, and if the Mossad
is a threat, you're gonna be Mossad'ed upon no matter what you do.

-Ben

---

From: Ira McDonald <[email-masked]>
Date: Sat, 13 Jul 2019 10:13:26 -0400

Hi,

About binary "trustworthy".

This is a fundamental fallacy.  Neither "trustworthy"
nor "secure" are *ever* binary.  That's basic to the
security by design approach.

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]
PO Box 221  Grand Marais, MI 49839  906-494-2434

On Fri, Jul 12, 2019 at 10:38 PM Benjamin Kaduk <[email-masked]> wrote:

> > Some comments on draft-birkholz-rats-architecture-01<
> https://tools.ietf.org/html/draft-birkholz-rats-architecture-01>
> >
> [...]
> > 7.1.1<
> https://tools.ietf.org/html/draft-birkholz-rats-architecture-01#section-7.1.1>.
> How the RATS Architecture Addresses the Lying Endpoint Problem
> >
> >
> >
> >
> >
> > “Likelihood” implies a probabilistic approach to trustworthiness (e.g.
> 42% likelihood of poisoned data”). Is that really feasible? And if so, is
> it actually of any use? IMO trustworthiness is binary (“trustworthy or not
> trustworthy”), or binary and conditional/contextual (“trustworthy if used
> for certain actions”).
>
> [email-masked]

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 14 Jul 2019 12:39:06 -0700

My framing for this is not binary, in this day and age of risk engines and machine learning. The relying party receiving the attestation is going to take whatever data is attested in as part of a decision that will probably involve other data such as transaction history and type. For example:

- A payment might be allowed if it is tiny and the risk of losing the customer is high even if the attestation seems wrong. Or vice-versa, the payment is large and the customer expects best protection. I’m pretty sure PayPal, VISA, Mastercard, Experian and such operate this way.

- a biometric authentication may not be allowed even though the attestation is excellent because the risk engine recognizes a pattern of fraud based on other non-attested data.

- A bad attestation from a router might be considered an isolated event until more evidence is accumulated. No one is went to the wire closet.

I also consider the security technology used to protect the signing key and attestation creation subsystem variable in security. And it needs to be considered in relation to the capacity of the attacker. A TEE (little defense against chip probing) might be consider quite good for small to medium $  payments backed by a risk engine. An EAL 6 secure element may be the only thing considered OK for access to a nuclear facility with no risk engine back up.

I prefer to never characterize something as trustworthy or as secure in any RFCs we create.  CWT and JWT don’t seem to go down this path either. 

(Correct me if I’m wrong, but I think maybe TCG does use the secure/non-secure framing. If so, I do NOT think we should bring it in here.)

LL

> On Jul 13, 2019, at 7:13 AM, Ira McDonald <[email-masked]> wrote:
> 
> Hi,
> 
> http://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] <mailto:[email-masked]>
> On Fri, Jul 12, 2019 at 10:38 PM Benjamin Kaduk <[email-masked] <mailto:[email-masked]>> wrote:
> > Some comments on draft-birkholz-rats-architecture-01<https://tools.ietf.org/html/draft-birkholz-rats-architecture-01 <https://tools.ietf.org/html/draft-birkholz-rats-architecture-01>>
> > 
> [...]
> > 7.1.1<https://tools.ietf.org/html/draft-birkholz-rats-architecture-01#section-7.1.1 <https://tools.ietf.org/html/draft-birkholz-rats-architecture-01#section-7.1.1>>.  How the RATS Architecture Addresses the Lying Endpoint Problem
> > 
> > 
> > 
> > 
> > 
> https://www.usenix.org/system/files/1311_05-08_mickens.pdf <https://www.usenix.org/system/files/1311_05-08_mickens.pdf> there's a
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: Nicolae Paladi <[email-masked]>
Date: Mon, 15 Jul 2019 11:14:19 +0000

Hi and thank you for the feedback on the point about trustworthiness.

I agree that in case of complex systems or decisions trustworthiness depends on the context.
Indeed, in the finance industry, decisions about the trustworthiness of a customer or transaction are often based on many inputs that together are used to compute the likelihood of the transaction or customer being acceptable or not.

However, I was referring to the trustworthiness of a specific device as defined in draft-birkholz-rats-architecture-01:

A trustworthy system is a system "that not only is trusted, but also warrants that trust because the system’s behavior can be validated in some convincing way, such as through formal analysis or code review" [RFC4949].

In my understanding, a formally verified component (hw or sw), considered in a specific threat model is either trustworthy or not trustworthy, NOT “ X % trustworthy "

Note that I do not discuss whether it is “secure”, only whether it is trustworthy in the sense of RFC4949

Nicolae

On 14 Jul 2019, at 21:39, Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:

LL

On Jul 13, 2019, at 7:13 AM, Ira McDonald <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Cheers,
- Ira

mailto: [email-masked]<mailto:[email-masked]>

On Fri, Jul 12, 2019 at 10:38 PM Benjamin Kaduk <[email-masked]<mailto:[email-masked]>> wrote:
Cherry-picking one point...

[...]

-Ben

---

From: Ira McDonald <[email-masked]>
Date: Mon, 15 Jul 2019 07:35:06 -0400

Hi,

I think that RFC 4949 definition of "trustworthy" is seriously
flawed".  For some of the nuances see the set of definitions
of "trustworthiness" in the US NIST Online Glossary at:

https://csrc.nist.gov/glossary/term/trustworthiness

Certainly for dynamic systems (i.e., almost all systems in
the real world), the idea of absolute "trustworthy" is a bad
one to use in system designs and implementations.

Cheers,
- Ira

On Mon, Jul 15, 2019 at 7:14 AM Nicolae Paladi <[email-masked]> wrote:

> Indeed, in the finance industry, decisions about the trustworthiness of a
> customer or transaction are often based on many inputs that together are
> used to compute the likelihood of the transaction or customer being
> acceptable or not.
>
> However, I was referring to the trustworthiness of a specific device as
> defined in draft-birkholz-rats-architecture-01:
>
> A trustworthy system is a system "that not only is trusted, but also
> warrants that trust because the system’s behavior can be validated in some
> convincing way, such as through formal analysis or code review" [RFC4949].
>
>
> In my understanding, a formally verified component (hw or sw), considered
> in a specific threat model is either trustworthy or not trustworthy, NOT “
> X % trustworthy "
>
> On 14 Jul 2019, at 21:39, Laurence Lundblade <[email-masked]>
> wrote:
>
> My framing for this is not binary, in this day and age of risk engines and
> machine learning. The relying party receiving the attestation is going to
> take whatever data is attested in as part of a decision that will probably
> involve other data such as transaction history and type. For example:
>
> - A payment might be allowed if it is tiny and the risk of losing the
> customer is high even if the attestation seems wrong. Or vice-versa, the
> payment is large and the customer expects best protection. I’m pretty sure
> PayPal, VISA, Mastercard, Experian and such operate this way.
>
> - a biometric authentication may not be allowed even though the
> attestation is excellent because the risk engine recognizes a pattern of
> fraud based on other non-attested data.
>
> - A bad attestation from a router might be considered an isolated event
> until more evidence is accumulated. No one is went to the wire closet.
>
>
> I also consider the security technology used to protect the signing key
> and attestation creation subsystem variable in security. And it needs to be
> considered in relation to the capacity of the attacker. A TEE (little
> defense against chip probing) might be consider quite good for small to
> medium $  payments backed by a risk engine. An EAL 6 secure element may be
> the only thing considered OK for access to a nuclear facility with no risk
> engine back up.
>
>
> I prefer to never characterize something as trustworthy or as secure in
> any RFCs we create.  CWT and JWT don’t seem to go down this path either.
>
> (Correct me if I’m wrong, but I think maybe TCG does use the
> secure/non-secure framing. If so, I do NOT think we should bring it in
> here.)
>
> LL
>
>
>

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 15 Jul 2019 14:07:13 +0000

I think both perspectives are correct. If the context of evaluation is an access decision then trust is binary. If the context is analytics, logging or risk management then trust is (can be) probabilistic.

The relying party has the necessary context. The main objective for RATS is to define Attester-Verifier interactions.

I’m just wondering, for the purposes of RATS architecture, if we need to resolve this question now?

On 7/13/19, 7:11 AM, "Ira McDonald" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Cheers,
- Ira

[...]

-Ben

---

From: Ira McDonald <[email-masked]>
Date: Mon, 15 Jul 2019 11:07:18 -0400

Hi Ned,

Perhaps in the RATS context we don't have to have this (side) discussion
about the use/definition of the word trustworthy...

For access at the datalink (device joining a network via an Access Point),
perhaps you could consider "trustworthy" as binary.  Although even later
TCG TNC and IETF NEA didn't - they distinguished which logical subnet
you got access to according to the quality of your posture information.

For access to a service (e.g., financial or medical), certainly
"trustworthy"
is not binary.  Service access and transaction authorization are dynamic
contexts for "trustworthy" - banks and credit card companies make a new
decision about relative degree of "trustworthiness" for every transaction.

Cheers,
- Ira

On Mon, Jul 15, 2019 at 10:07 AM Smith, Ned <[email-masked]> wrote:

> I think both perspectives are correct. If the context of evaluation is an
> access decision then trust is binary. If the context is analytics, logging
> or risk management then trust is (can be) probabilistic.
>
>
>
> The relying party has the necessary context. The main objective for RATS
> is to define Attester-Verifier interactions.
>
>
>
> On 7/13/19, 7:11 AM, "Ira McDonald" <[email-masked]> wrote:
>
>
>
> Hi,
>
>
>

---

From: Adrian Shaw <[email-masked]>
Date: Mon, 15 Jul 2019 16:31:01 +0000

If trustworthiness is based on whether you meet a set of criteria then it is always a binary result. But remember that trust is not absolute or blind, there’s always a specific context. You trust X to do action Y without malice. Each context has its own (maybe distinct) set of criteria e.g. whether you meet the criteria to access a particular subnet.

Best,
Adrian

On 15 Jul 2019, at 16:07, Ira McDonald <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ned,

For access to a service (e.g., financial or medical), certainly "trustworthy"
is not binary.  Service access and transaction authorization are dynamic
contexts for "trustworthy" - banks and credit card companies make a new
decision about relative degree of "trustworthiness" for every transaction.

Cheers,
- Ira

On Mon, Jul 15, 2019 at 10:07 AM Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:
I think both perspectives are correct. If the context of evaluation is an access decision then trust is binary. If the context is analytics, logging or risk management then trust is (can be) probabilistic.

Hi,

Cheers,
- Ira

On Fri, Jul 12, 2019 at 10:38 PM Benjamin Kaduk <[email-masked]<mailto:[email-masked]>> wrote:
Cherry-picking one point....

[...]

-Ben

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: Laurence Lundblade <[email-masked]>
Date: Mon, 15 Jul 2019 10:47:57 -0700

> On Jul 15, 2019, at 7:07 AM, Smith, Ned <[email-masked]> wrote:
> 

For the EAT claims document, I don’t think there is much of an issue with “trust”. It hardly uses the word.

However the architecture document has a lot of orientation around trusted or not. Here’s some example text from 4.1.3:

   o  Evaluates trustworthiness during manufacturing, supply chain and
      onboarding

   o  Produces trustworthiness assertions applicable to the Attestor
      role

I don’t think the architecture document should be adopted until we resolve how it treats trust.

My fundamental argument is that no notion of trusted/untrusted is possible in our documents. Only the relying party can decide that and they will decide that based on their individual and wildly varying requirements (payments large or small, enterprise access, web site access…).

Further, the notion that an individual implementation can be deemed trustworthy seems flawed. How many HW chip defenses does it require? What strength of cryptography? Is EAL 5 Common Criteria evaluation enough?

LL