Subject: [Rats] use case document updates on Roots of Trust

From: Michael Richardson <[email-masked]>
Date: Sun, 08 Sep 2019 14:23:06 +0100

We seem to have regular email disputes on terms like Roots of Trust. 
I continue to have difficulty with the term. Particularly in the plural
"Roots" form.
As I process edits to the use case document, I got a bunch of text:

   The TCG Glossary also offers a general definition for Root of Trust “A
   component that performs one or more security-specific functions, such as
   measurement, storage, reporting, verification, and/or update. It is trusted
   always to behave in the expected manner, because its misbehavior cannot be
   detected (such as by measurement) under normal operation. “ 

{I personally find it very difficult to understand the words as other than an
alias for Trust Anchor, yet it clearly is something else.  It's hard to make
my neurons pull up a different meaning.  This is probably something that
every RATS document should say clearly upon first using the term, in order to
ease the impedence mis-match with IETF readers as we get reviews} 

I have included not just Ned Smith's comments about the term Roots of Trust,
but his survey of the various origins of the term.  I'm sure that this
belongs somewhere else.

That diff is here:
  https://ietf.org/rfcdiff?url1=draft-richardson-rats-usecases-04&url2=https://ietf-rats-wg.github.io/ietf-rats-usecases/draft-richardson-rats-usecases.txt

and commit is:
  https://github.com/ietf-rats-wg/ietf-rats-usecases/commit/7386e8c0df11ece66e3c95f85d141a639d440e12

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

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 9 Sep 2019 13:56:09 -0700

Appreciate you wading into this with something written and concrete.

As a thought experiment consider adding this to our RATS definition:

A root of trust may also be a simple unsecured user mode application, like an Android, Windows or Linux application that trust has been placed in by a particular attestation system. It is provisioned with a signing key or such and other capabilities so as to be able to produce attestation evidence (e.g. signed tokens).  The application may or may not be signed or authenticated.

In a sense, the usual definition of root of trust applies in that it is something that is unconditionally trusted. In another sense, this is at odds with the usual conception as it is not anchored in HW or to any kind of system or boot SW.

I assuming this addition is too much at odds with the convention usage and there is no support for RATS adopting this definition. This is one of the main reasons I am asking we not use the term normatively.

LL

> On Sep 8, 2019, at 6:23 AM, Michael Richardson <[email-masked]> wrote:
> 
> 
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 10 Sep 2019 00:48:48 +0200

Hi all,

wrt the topic of "roots of trust", on the list a very visible concern 
was highlighted: "the definition [of RoT] defines what they are -not- 
and not what it actually -are-". And I am inclined to agree with that.

My initial and unpolished proposal is this:

"If" we use the spectrum of meanings what "roots of trust" are in RATS, 
we probably have to do two things:

1.) We maybe should highlight that "Roots of Trust" are a demarcation 
line. There are system components or system components characteristics 
(aka "Claims" that are composed into "Evidence" about "Trustworthiness") 
that an Attester cannot create Evidence about only by itself. It is the 
"rock bottom" that an Attester cannot attest to (because, quoting: 
"their misbehavior cannot be detected"). While that being very true, it 
seems not to be enough of a reason to just exclude them conceptually.

Hence, the only established procedure to "deal" with these roots of 
trust is a third's party endorsement. The consumer of attestation 
results is at its own liberty to put trust into these third party's 
endorsements - or not.

It is an optional Claim Set, typically provided in the form of 
Endorsement Certificates (but there surely are other ways). And these 
methods might simply not be available to an Attester. And if that i that 
case that MUST not be a blocker, especially wrt to the RATS architecture.

I.e. in RATS these Claims about RoT (Endorsements) should be purely 
optional. The architecture should allow to include them. But by any 
means, there should not be prescriptive or a normative MUSTs to provide 
them.

If an Attester is able to provide or refer to such an endorsements of a 
system components capabilities, it should be able to do so. If an 
Attester is not able to provide such third party endorsements, that 
should not be a blocker to conducts RATS. The benefit of having the 
option to provide them is to fuel a framework about "levels of 
confidence" that most likely is out of scope of IETF definitions, but 
would enable other entities to fill that gap in.

2.) I am proposing that the RATS WG puts some effort in defining what 
"roots of trust" actually do (and not only what they cannot do). That 
would help to create an understanding what they actually mean - a lot. 
And - I think that is important - that might not have to be part of the 
architecture document. Maybe it is an Appendix of it, maybe it is an 
informational draft that complements the architecture document, or this 
content goes alongside with solutions drafts. We don't know yet, I think.

TL;DR

Roots of Trust are relevant. But their upcoming definition and use 
should not stop us from progressing essential corner stone drafts, today.

My understanding is that some use cases really require them, and other 
use cases don't. Neither am I inclined to include them in the 
architecture draft and over-complicate elegant solutions, such as EAT, 
nor am I inclined to exclude them and thereby inhibit established 
solution, such as RIV.

There is some middle ground here, I think. My proposal is to neither 
disregard the system components an Attester is not able to create 
Evidence for by itself, nor to mandate that an Attester can only create 
believable Evidence, if RoT are available. Both options should be 
enabled by the RATS architecture, I think.

Viele Grüße,

Henk

On 09.09.19 22:56, Laurence Lundblade wrote:
>     A root of trust may also be a simple unsecured user mode
>     application, like an Android, Windows or Linux application that
>     trust has been placed in by a particular attestation system. It is
>     provisioned with a signing key or such and other capabilities so as
>     to be able to produce attestation evidence (e.g. signed tokens).
>       The application may or may not be signed or authenticated.
> 
>     In a sense, the usual definition of root of trust applies in that it
>     is something that is unconditionally trusted. In another sense, this
>     is at odds with the usual conception as it is not anchored in HW or
>     to any kind of system or boot SW.
> 
> I assuming this addition is too much at odds with the convention usage 
> and there is no support for RATS adopting this definition. This is one 
> of the main reasons I am asking we not use the term normatively.
> 
> LL
> 
> 
>> On Sep 8, 2019, at 6:23 AM, Michael Richardson <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>> Michael Richardson <[email-masked] 
>> <mailto:[email-masked]>>, Sandelman Software Works
>> [email-masked] <mailto:[email-masked]>

---

From: Ira McDonald <[email-masked]>
Date: Mon, 9 Sep 2019 19:20:02 -0400

Hi,

Chiming in here.

The TCG is neither the originator of the term "Root of Trust", nor a
particularly good source for RoT definitions.

One might look at this US NIST project on Roots of Trust:

https://csrc.nist.gov/Projects/Hardware-Roots-of-Trust/publications

And especially this SP800-164 document:

https://csrc.nist.gov/publications/detail/sp/800-164/draft

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

---

From: Ira McDonald <[email-masked]>
Date: Mon, 9 Sep 2019 19:40:00 -0400

Hi,

SP800-164 contains this rather informative definition for RoTs:

Roots of Trust (RoTs). RoTs are security primitives composed of hardware,
firmware and/or software that provide a set of trusted, security-critical
functions. They must always behave in an expected manner because their
misbehavior cannot be detected. As such, RoTs need to be secured by their
design. Hardware RoTs are preferred over software RoTs due to their
immutability, smaller attack surface, and more reliable behavior.

Notice that both hardware and software RoTs are addressed, with a rationale
for the preference for hardware RoTs.

If the term RoT continues to cause heartburn in RATS, then we might just use
the generic "Trust Anchor" which is widely used to encompass both hardware
and software RoTs in a number of SDOs.

Cheers,
- Ira

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 10 Sep 2019 23:23:53 +0000

The term "Trust Anchor" seems to connote a public key, public key certificate or something related primarily to termination of a certificate path validation. https://tools.ietf.org/html/rfc5914. 

The root_of_trust term as used by https://csrc.nist.gov/Projects/Hardware-Roots-of-Trust/publications seems to refer to a computing environment that performs a well-defined security related function. The environment doesn't necessarily need to have a key associated with it - unless its function requires a key or trust anchor. For example: 
	- Attestation requires signing of evidence, hence it requires a key. 
	- Verification of signatures requires a Trust Anchor / public key. 
	- A RATS Verifier produces Attestation Results, hence must have a signing key in addition to Trust Anchor(s). 

The TCG uses the term "roots" of trust because there are several separable functions included in a TPM. It can store measurements and keys hence it is a "storage" RoT. It can sign evidence hence it is a "reporting" RoT - aka attestation RoT. A TPM can also verify signatures hence it is a Verification RoT. 

A RoT is more than just functions. A TPM is a library of security functions that are intended to be implemented in a trustworthy environment. However, there are software TPM libraries that can run in a variety of environments - some of which wouldn't normally be thought of as "trustworthy". 

Glossaries defining root of trust seem to consistently acknowledge the distinguishing factor for root-of-trust as "misbehavior cannot be detected". To protect root-of-trust functions from simple attacks, implementers often harden them by implementing them in immutable hardware. But the property of non-detectable misbehavior existed before the hardening was applied.

RATS Attestation architecture should promote minimizing the surface area of Root-of-Trust functions IMO. Nevertheless, it seems there will always be some function r() for which there is no function f'() that can detect misbehavior. Nevertheless, there may be a function f() where misbehavior can be detected by f'(), but not of r().  Hence, f'(f(r())) means f'() can detect misbehavior of f() but not of r(). Therefore, r() is a root of trust.

Maybe an attestation construction looks something like this:
	 f'''(f''(f'(f(r())))) where a prime (') denotes attestation function(s) that can detect misbehavior of enclosed functions. Since the inner-most functions f() contains r() and where no f'() exists to detect its misbehavior, r() is a root-of-trust. In theory, there could be many layers of functionality that are attestable. For example, the TEEP architecture allows fan-out and nesting of Trusted Agents in the same platform.

That doesn't however mean r() must remain anonymous, r() can be given a name and can be subject to manufacturing process controls. Typically, something like the tuple (mfg, product ID, version, S/N) can be used to manually track r(). But that is the best anyone can do. 

In the case of TPM, the root of trust for reporting a() includes a key called the "endorsement key" that is only used for tracking purposes. Nevertheless, the verifier must trust a() to implement the endorsement key and tracking functionality correctly. Maybe it is circular logic, but a() still fits the definition of a root-of-trust.

Trusted boot is another use case for a root of trust. The idea of trusted boot is there is a function b() that is trusted to load another function b'(). Misbehavior on the part of b() could result in loading a malicious function m() instead of b'(). Before b'() loads, b() measures b'() into a storage root s(). A trusted boot construction might look like this: b(b'(b''(b'''(...)))). Since there is no function x() that loads b(). Therefore, b() is a root-of-trust. 

Note: that if b() doesn't have some function f'() such that f'(b()) exists, then b() cannot be attested - but it is still a root-of-trust. 

The TCG anticipated b() but didn't standardize it. It also assumed there was a trusted function that combined b() with a TPM storage root of trust s(). TCG presumed f(b(), s()) would exist even if they didn't standardize f() and b(). There was no attestation function for f(b(), s()) either, other than using supply chain entity endorsements (e.g. attribute certs) of platform constructions containing f(b(), s()). TCG used attribute certificates to link the TPM endorsement key in a() to other platform components such as b(). E.g.:
	TCG Trusted Platform =  f(b(b'(b''(...))), TPM(s(), a())); if the TPM implements the attestation function f'() for b'(b''(b'''(...))). 
	Then the construction: R = f(b(), TPM(s(), a())) are the roots-of-trust upon which the attestation function in the TPM depends. 
	E.g. f'() =  a(s(b'(b''(b'''(...))))) --> R; where "-->" denotes root-of-trust dependency. 

Another form of root-of-trust is a Verifier. I began this thread talking about trust anchor terminology. A Verifier function v() contains a trust anchor TA that v() uses to terminate cert path validation. Possibly, v() relies on a TA provisioning function p(), such as RFC5934 that helps v() determine which TA to use. In this case, v() contains p() e.g. v(p()); but it may be the case that there is no attestation function for p() such that f'(p()) does not exist. It may also be the case that no f'(v()) exists either. Hence, both v() and p() are roots of trust. 

However, if f'(p()) did exist, and no f'(v()) existed, then v() is still a root-of-trust, but the trusted surface area in v() is minimized by f'(p()). 

Those familiar with TPM, trusted boot and the ecosystem around it, may use the term 'roots of trust' as a way to talk about the above complexity without going into the details as I have done here.

RATS scope is essentially definition of f'() but it should acknowledge roots of trust functions even if we refer to them by some other name.

-Ned

On 9/8/19, 6:22 AM, "RATS on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

    

    That diff is here:
    
    and commit is:

---

From: Ira McDonald <[email-masked]>
Date: Tue, 10 Sep 2019 20:28:14 -0400

Hi,

FWIW, the various SAE vehicle security committees commonly use "Trust
Anchor"
(rather than "RoT") to encompass the entire spectrum of RoTs, *as well as*
the
X.509 CA style trust anchor.  There's an entire SAE vehicle security
committee
titled SAE Trust Anchors and Authentication.  In addition, the SAE J3101
spec,
soon to be published, is titled Requirements for Hardware-Protected Security
for Ground Vehicle Applications and abstracts primitives and functions from
any
of the automotive HSM-like components - it *always* uses the term "Hardware
Trust Anchor" rather than "Hardware RoT".  It explicitly avoids the
anti-definition
that misbehavior of a "Hardware Trust Anchor" cannot be detected.

Cheers,
- Ira

On Tue, Sep 10, 2019 at 7:24 PM Smith, Ned <[email-masked]> wrote:

> The term "Trust Anchor" seems to connote a public key, public key
> certificate or something related primarily to termination of a certificate
> path validation. https://tools.ietf.org/html/rfc5914.
>
> The root_of_trust term as used by
> https://csrc.nist.gov/Projects/Hardware-Roots-of-Trust/publications seems
> to refer to a computing environment that performs a well-defined security
> related function. The environment doesn't necessarily need to have a key
> associated with it - unless its function requires a key or trust anchor.
> For example:
>         - A RATS Verifier produces Attestation Results, hence must have a
> signing key in addition to Trust Anchor(s).
>
> The TCG uses the term "roots" of trust because there are several separable
> functions included in a TPM. It can store measurements and keys hence it is
> a "storage" RoT. It can sign evidence hence it is a "reporting" RoT - aka
> attestation RoT. A TPM can also verify signatures hence it is a
> Verification RoT.
>
> A RoT is more than just functions. A TPM is a library of security
> functions that are intended to be implemented in a trustworthy environment.
> However, there are software TPM libraries that can run in a variety of
> environments - some of which wouldn't normally be thought of as
> "trustworthy".
>
> Glossaries defining root of trust seem to consistently acknowledge the
> distinguishing factor for root-of-trust as "misbehavior cannot be
> detected". To protect root-of-trust functions from simple attacks,
> implementers often harden them by implementing them in immutable hardware.
> But the property of non-detectable misbehavior existed before the hardening
> was applied.
>
> RATS Attestation architecture should promote minimizing the surface area
> of Root-of-Trust functions IMO. Nevertheless, it seems there will always be
> some function r() for which there is no function f'() that can detect
> misbehavior. Nevertheless, there may be a function f() where misbehavior
> can be detected by f'(), but not of r().  Hence, f'(f(r())) means f'() can
> detect misbehavior of f() but not of r(). Therefore, r() is a root of trust.
>
>          f'''(f''(f'(f(r())))) where a prime (') denotes attestation
> function(s) that can detect misbehavior of enclosed functions. Since the
> inner-most functions f() contains r() and where no f'() exists to detect
> its misbehavior, r() is a root-of-trust. In theory, there could be many
> layers of functionality that are attestable. For example, the TEEP
> architecture allows fan-out and nesting of Trusted Agents in the same
> platform.
>
> That doesn't however mean r() must remain anonymous, r() can be given a
> name and can be subject to manufacturing process controls. Typically,
> something like the tuple (mfg, product ID, version, S/N) can be used to
> manually track r(). But that is the best anyone can do.
>
> In the case of TPM, the root of trust for reporting a() includes a key
> called the "endorsement key" that is only used for tracking purposes.
> Nevertheless, the verifier must trust a() to implement the endorsement key
> and tracking functionality correctly. Maybe it is circular logic, but a()
> still fits the definition of a root-of-trust.
>
> Trusted boot is another use case for a root of trust. The idea of trusted
> boot is there is a function b() that is trusted to load another function
> b'(). Misbehavior on the part of b() could result in loading a malicious
> function m() instead of b'(). Before b'() loads, b() measures b'() into a
> storage root s(). A trusted boot construction might look like this:
> b(b'(b''(b'''(...)))). Since there is no function x() that loads b().
> Therefore, b() is a root-of-trust.
>
> Note: that if b() doesn't have some function f'() such that f'(b())
> exists, then b() cannot be attested - but it is still a root-of-trust.
>
> The TCG anticipated b() but didn't standardize it. It also assumed there
> was a trusted function that combined b() with a TPM storage root of trust
> s(). TCG presumed f(b(), s()) would exist even if they didn't standardize
> f() and b(). There was no attestation function for f(b(), s()) either,
> other than using supply chain entity endorsements (e.g. attribute certs) of
> platform constructions containing f(b(), s()). TCG used attribute
> certificates to link the TPM endorsement key in a() to other platform
> components such as b(). E.g.:
>         TCG Trusted Platform =  f(b(b'(b''(...))), TPM(s(), a())); if the
> TPM implements the attestation function f'() for b'(b''(b'''(...))).
>         Then the construction: R = f(b(), TPM(s(), a())) are the
> roots-of-trust upon which the attestation function in the TPM depends.
> Another form of root-of-trust is a Verifier. I began this thread talking
> about trust anchor terminology. A Verifier function v() contains a trust
> anchor TA that v() uses to terminate cert path validation. Possibly, v()
> relies on a TA provisioning function p(), such as RFC5934 that helps v()
> determine which TA to use. In this case, v() contains p() e.g. v(p()); but
> it may be the case that there is no attestation function for p() such that
> f'(p()) does not exist. It may also be the case that no f'(v()) exists
> either. Hence, both v() and p() are roots of trust.
>
> However, if f'(p()) did exist, and no f'(v()) existed, then v() is still a
> root-of-trust, but the trusted surface area in v() is minimized by f'(p()).
>
> Those familiar with TPM, trusted boot and the ecosystem around it, may use
> the term 'roots of trust' as a way to talk about the above complexity
> without going into the details as I have done here.
>
> RATS scope is essentially definition of f'() but it should acknowledge
> roots of trust functions even if we refer to them by some other name.
>
> -Ned
>
> On 9/8/19, 6:22 AM, "RATS on behalf of Michael Richardson" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 11 Sep 2019 11:30:40 +0200

Hi Ira & Ned,
hi all,

TL;DR
While I understand the point of the SAE, there a number of good reasons 
not to mimic their decision here, I think.

while I see, acknowledge, and understand (to some extent) the confusion 
about TA & ROT, reiterating and adding to the confusion is a prominent 
reason why people are actually starting to become reluctant to use these 
terms at all. Down to the notion that "includes a root of trust" 
sometimes is already believed to be just a marketing term.

And that is a big problem with direct impact on security considerations 
and threat models.

At least Trust Anchor is well defined in RFC4949 and is also used in 
TEEP (although "TA" means something else there, but TEEP is dealing with 
that successfully) based on the definition in RFC4949.

Now that TEEP and RATS start to align in some capacity, I would strongly 
recommend to simply stick with the established IETF term Trust Anchor 
from RFC4949 and its corresponding use in I-D.ietf-teep-architecture.

Which leaves us with "the other confusing term" that Ned once called 
"the-entity-whose-misbehavior-cannot-be-detected".  The important point 
here is that the output of an Attester in the form of Claims that 
compose Evidence can only go so far while staying believable.  At some 
point you hit rock bottom and you cannot create believable evidence 
anymore, because there are no more turtles that go all the way down.  At 
that point an Attester cannot create believable evidence about its most 
fundamental system components and requires an external Endorsement that 
speaks on behalf of these system components.

And that is the point where Roots of Trust come into play. If you do not 
have them - that is absolutely compliant with RATS. But I'd also like to 
quote Kathleen here:

> Why would I want a device with no root of trust?  Plausible deniability perhaps? Lower cost?
> Why would I want to sell such a device?  I probably wouldn't and this could spur on higher level of assurance and remake of devices without this capability depending on the target market for a device.

And now - comes the the really tricky part: these Endorsements that come 
alongside with Roots of Trusts - those typically have Trust Anchors.

And I think that is one of the major sources of confusion (but maybe it 
is not, due to the fact that I am under the personal believe not to be 
confused here...).

On the one hand, it is okay to not have or use a Root of Trust in any 
way and not to bother with them at all in a solution I-D.

On the other hand, not using an endorsed root of trust always has a 
significant impact on the "level of assurance" (which is called "level 
of confidence" in the architecture at the moment, but that is not 
important now) and thereby on the confidence in the veracity of Claims 
in Evidence.

In summary, there are fundamental factors to take into account, if you 
want to decide whether to talk about the use a RoTs - or not, including:

* market impact,
* effective assurance of protection levels, and
* the inevitable fact that at some point an Attester hits a demarcation 
line beyond which it cannot attest to one of its system components 
anymore - and starts to depend on external endorsements about these 
system components.

Viele Grüße,

Henk

p.s. I really, really hope that I did not add to the confusion!

p.p.s. I'd also like to try to create an EAT flavor now that is an 
"Endorsement EAT" signed by a TA, I think.

On 11.09.19 02:28, Ira McDonald wrote:
> (rather than "RoT") to encompass the entire spectrum of RoTs, *as well 
> as* the
> for Ground Vehicle Applications and abstracts primitives and functions 
> from any
> mailto: [email-masked] <mailto:[email-masked]>
> On Tue, Sep 10, 2019 at 7:24 PM Smith, Ned <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     certificate or something related primarily to termination of a
>     certificate path validation. https://tools.ietf.org/html/rfc5914.
> 
>     seems to refer to a computing environment that performs a
>     well-defined security related function. The environment doesn't
>     necessarily need to have a key associated with it - unless its
>     function requires a key or trust anchor. For example:
>              - A RATS Verifier produces Attestation Results, hence must
>     have a signing key in addition to Trust Anchor(s).
> 
>     The TCG uses the term "roots" of trust because there are several
>     separable functions included in a TPM. It can store measurements and
>     keys hence it is a "storage" RoT. It can sign evidence hence it is a
>     "reporting" RoT - aka attestation RoT. A TPM can also verify
>     signatures hence it is a Verification RoT.
> 
>     functions that are intended to be implemented in a trustworthy
>     environment. However, there are software TPM libraries that can run
>     in a variety of environments - some of which wouldn't normally be
>     thought of as "trustworthy".
> 
>     Glossaries defining root of trust seem to consistently acknowledge
>     the distinguishing factor for root-of-trust as "misbehavior cannot
>     be detected". To protect root-of-trust functions from simple
>     attacks, implementers often harden them by implementing them in
>     immutable hardware. But the property of non-detectable misbehavior
>     existed before the hardening was applied.
> 
>     RATS Attestation architecture should promote minimizing the surface
>     area of Root-of-Trust functions IMO. Nevertheless, it seems there
>     will always be some function r() for which there is no function f'()
>     that can detect misbehavior. Nevertheless, there may be a function
>     f() where misbehavior can be detected by f'(), but not of r(). 
>     Hence, f'(f(r())) means f'() can detect misbehavior of f() but not
>     of r(). Therefore, r() is a root of trust.
> 
>               f'''(f''(f'(f(r())))) where a prime (') denotes
>     attestation function(s) that can detect misbehavior of enclosed
>     functions. Since the inner-most functions f() contains r() and where
>     no f'() exists to detect its misbehavior, r() is a root-of-trust. In
>     theory, there could be many layers of functionality that are
>     attestable. For example, the TEEP architecture allows fan-out and
>     nesting of Trusted Agents in the same platform.
> 
>     That doesn't however mean r() must remain anonymous, r() can be
>     given a name and can be subject to manufacturing process controls.
>     Typically, something like the tuple (mfg, product ID, version, S/N)
>     can be used to manually track r(). But that is the best anyone can do.
> 
>     In the case of TPM, the root of trust for reporting a() includes a
>     key called the "endorsement key" that is only used for tracking
>     purposes. Nevertheless, the verifier must trust a() to implement the
>     endorsement key and tracking functionality correctly. Maybe it is
>     circular logic, but a() still fits the definition of a root-of-trust.
> 
>     Trusted boot is another use case for a root of trust. The idea of
>     trusted boot is there is a function b() that is trusted to load
>     another function b'(). Misbehavior on the part of b() could result
>     in loading a malicious function m() instead of b'(). Before b'()
>     loads, b() measures b'() into a storage root s(). A trusted boot
>     construction might look like this: b(b'(b''(b'''(...)))). Since
>     there is no function x() that loads b(). Therefore, b() is a
>     root-of-trust.
> 
>     The TCG anticipated b() but didn't standardize it. It also assumed
>     there was a trusted function that combined b() with a TPM storage
>     root of trust s(). TCG presumed f(b(), s()) would exist even if they
>     didn't standardize f() and b(). There was no attestation function
>     for f(b(), s()) either, other than using supply chain entity
>     endorsements (e.g. attribute certs) of platform constructions
>     containing f(b(), s()). TCG used attribute certificates to link the
>     TPM endorsement key in a() to other platform components such as b().
>     E.g.:
>              TCG Trusted Platform =  f(b(b'(b''(...))), TPM(s(), a()));
>     if the TPM implements the attestation function f'() for
>     b'(b''(b'''(...))).
>     Another form of root-of-trust is a Verifier. I began this thread
>     talking about trust anchor terminology. A Verifier function v()
>     contains a trust anchor TA that v() uses to terminate cert path
>     validation. Possibly, v() relies on a TA provisioning function p(),
>     such as RFC5934 that helps v() determine which TA to use. In this
>     case, v() contains p() e.g. v(p()); but it may be the case that
>     there is no attestation function for p() such that f'(p()) does not
>     exist. It may also be the case that no f'(v()) exists either. Hence,
>     both v() and p() are roots of trust.
> 
>     However, if f'(p()) did exist, and no f'(v()) existed, then v() is
>     still a root-of-trust, but the trusted surface area in v() is
>     minimized by f'(p()).
> 
>     Those familiar with TPM, trusted boot and the ecosystem around it,
>     may use the term 'roots of trust' as a way to talk about the above
>     complexity without going into the details as I have done here.
> 
>     RATS scope is essentially definition of f'() but it should
>     acknowledge roots of trust functions even if we refer to them by
>     some other name.
> 
>     -Ned
> 
>     On 9/8/19, 6:22 AM, "RATS on behalf of Michael Richardson"
>     <[email-masked] <mailto:[email-masked]> on behalf of
>     [email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>     <mailto:mcr%2BIETF@sandelman..ca>>, Sandelman Software Works

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 11 Sep 2019 16:41:36 +0000

Henk commented: 
"    p.p.s. I'd also like to try to create an EAT flavor now that is an 
    "Endorsement EAT" signed by a TA, I think."

I assume Henk meant to say that the "Endorsement EAT" is a claim set that is signed by a supply-chain-entity and is trusted by a Verifier because the Verifier maintains the supply-chain-entity's Trust Anchor (TA).

-Ned

On 9/11/19, 2:31 AM, "RATS on behalf of Henk Birkholz" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Ira & Ned,
    hi all,
    
    TL;DR

    

    

    

    
    
    * market impact,

    Viele Grüße,
    
    Henk

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 11 Sep 2019 18:45:11 +0200

Thank you Ned for rephrasing my hastily added afterthought. That is 
exactly what I meant.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Sep 2019 20:09:11 +0100

Ira McDonald <[email-masked]> wrote:
    > If the term RoT continues to cause heartburn in RATS, then we might
    > just use the generic "Trust Anchor" which is widely used to encompass
    > both hardware and software RoTs in a number of SDOs.

No, that's exactly what I don't want to do!

A trust anchor is a thing you have in your system (such as your browser),
that let's you validate other certificates.  While in abstract concept it
shares many properties with a RoT, it's a very different thing to people
who don't live and breath attestation.

A reason I don't like the term RoT (not the definition, btw), is because in
some languages the order of the words doesn't matter.  So a Trusted Root
(Certificate), might be easily confused with a Root of Trust!
{It's taken me six months to get this into my head right, and at the Linux
Plumber's Conference, I watched several others fail to deal with the issue}

As I understand it, the RoT is the component which is forced measure itself,
because there exists no other component.  The trust is "Immaculate".
If I could replace RoT with another term, I'd use "Birth of Trust" or
"Immaculate Trust" or something like that.

I'M NOT PROPOSING TO CHANGE THE TERM.
I'm just airing dirty laundry, to explain that we need to be clearer about
this somewhere.

The only reason the use case document cares, is because I think it is
important for the use cases to be clear if they require the Third Party
Attestation of the RoT Claim in order to operate.

Some use cases do not, as their dependancy is upon a higher level
attestation, or the device has been attested to use Secure Boot 
rather than Trusted Boot.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 12 Sep 2019 22:31:39 +0000

I do not see a meaningful difference between "trust anchor" and "trust root" and "root(s) of trust."  All of them:
	- Are pieces of data (certificate or key is not meaningful)
	- Used to verify something such as a certificate or signature
	- Are trusted by the application, based on actions that are "out of band" of the application itself

---

From: Carl Wallace <[email-masked]>
Date: Thu, 12 Sep 2019 18:47:59 -0400

+1, though maybe say 'Used to verify a signature, possibly on a
certificate'. This is consistent with the 5914 (or 6024) definition: "A
trust anchor is an authoritative entity represented by a public key and
associated data.  The public key is used to verify digital signatures, and
the associated data is used to constrain the types of information or
actions for which the trust anchor is authoritative."

On 9/12/19, 6:31 PM, "RATS on behalf of Salz, Rich" <[email-masked]
on behalf of [email-masked]> wrote:

>I do not see a meaningful difference between "trust anchor" and "trust
>root" and "root(s) of trust."  All of them:

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 13 Sep 2019 21:52:04 +0200

I don't know what a trust root is, but a trust anchor does not reside on 
the Attester (with respect to the evidence that is created) while a root 
of trust does. That is kind of one of the primitives why they are 
differentiated. Specific comments in-line:

On 13.09.19 00:31, Salz, Rich wrote:
> 	- Are pieces of data (certificate or key is not meaningful

Well, if the entities certificates and the entities openssl software 
components are the same thing (because they both are pieces of data), 
then I think I would agree here. If it is relevant to the workflow that 
one is an executable that resides somewhere and one is a document that 
can be presented, I am more inclined to differentiate the entities TA 
from the entity ROT, too. I am aware that the analogy is a bit clunky 
and someone can surely can come up with a better one.

> 	- Used to verify something such as a certificate or signature

Some roots of trusts do that, other roots of trust don't do that (e.g. 
doing the opposite: an RTR for creating the signatures, digests, or 
evidence). So that cannot be a common denominator either, I think.

> 	- Are trusted by the application, based on actions that are "out of band" of the application itself

That in fact is indisputable and probably the reason why both trust 
anchor and root of trust include the term "trust" :)

In essence, I simply think it is just not that simple - to say "they are 
the same" and then only focus on similarities to bolster that argument.

Viele Grüße,

Henk

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 15 Sep 2019 13:50:15 -0700

> 	- Are trusted by the application, based on actions that are "out of band" of the application itself

This is not how I understand a root of trust, nor how I think it is generally used in the TCG or TEE worlds. I think a root of trust involves a CPU, memory and SW that actively does something like boot and measure a device. There is usually a boundary around it so that other software on the device, like the high-level OS, can’t corrupt it. When it is doing reporting as in RATS it will have a private key that can do some signing. When it is doing trusted/secure boot, it will also have a public key to verify the software it loads.

LL

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Mon, 16 Sep 2019 09:02:53 +0000

+1

A Root of Trust not data. The GlobalPlatform definition[1] is explicit that a Root of Trust has a computing engine and executable code that exist within a security boundary. Keys are optional as there are RoT use-cases that do not necessarily require keys (keys and/or other RoT data also exist inside the security boundary if they are present).

I’m not sure that the TCG Glossary[2] calls this requirement out quite so explicitly as GlobalPlatform, but the definition of RoT in the glossary is clear that an RoT performs functions - something that implies a computing engine.

A Root of Trust can perform other tasks than verification (and need not be capable of verification). This applies to all of the definitions I know (NIST, GlobalPlatform, TCG)

Best regards
Jeremy

[1] GlobalPlatform Root of Trust Definitions and Requirements, v1.1<https://globalplatform.org/wp-content/uploads/2018/07/GP_RoT_Definitions_and_Requirements_v1.1_PublicRelease-2018-06-28.pdf> (NB - unlike some GlobalPlatform specifications, this is not behind a click-through)
[2] TCG Glossary V1.1, Rev 1.0<https://trustedcomputinggroup.org/wp-content/uploads/TCG-Glossary-V1.1-Rev-1.0.pdf>

---
Jeremy O’Donoghue                            email: [email-masked]<mailto:[email-masked]>
Director, Engineering                        tel:   +44 1252 363189
NFC & Secure Software and Systems

On 15 Sep 2019, at 21:50, Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:

-------------------------------------------------------------------------
CAUTION: This email originated from outside of the organization.
-------------------------------------------------------------------------

On Sep 12, 2019, at 3:31 PM, Salz, Rich <[email-masked]<mailto:[email-masked]>> wrote:

LL

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

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 16 Sep 2019 12:19:18 +0000

Okay, I’m in the minority about the definition of RoT, thanks for the update.  FYI, this will probably confuse other people coming here from a strong PKIX/TLS background, so please make it very explicit.

---

From: Carl Wallace <[email-masked]>
Date: Mon, 16 Sep 2019 08:26:04 -0400

I took Rich's statement to be more from a relying party perspective and
your detail to be more what one might find in a policy describing nature
of the root of trust, which is not that different from how one may
describe a trust anchor/CA in a PKIX context in a policy that describes
how a CA are operated, etc. Two sides of the same coin.

On 9/15/19, 4:50 PM, "RATS on behalf of Laurence Lundblade"
<[email-masked] on behalf of [email-masked]> wrote:

>This is not how I understand a root of trust, nor how I think it is
>generally used in the TCG or TEE worlds. I think a root of trust involves
>a CPU, memory and SW that actively does something like boot and measure a
>device. There is usually a boundary around it so that other software on
>the device, like the high-level OS, can’t corrupt it. When it is doing
>reporting as in RATS it will have a private key that can do some signing.
>When it is doing trusted/secure boot, it will also have a public key to
>verify the software it loads.
>
>LL
>
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Sep 2019 12:59:53 -0400

> band" of the application itself

That's because the term "root of trust" as used by attestation people are
very confusing.  And it's precisely your confusion that I would like to avoid.

** A root of trust is a piece of code that measures itself, because nothing
** before it can do that. (It might be the first piece of code to run).

While it is true that a trust anchor (in the form of a self-signed
certificate) comes with a similar kind of circular/implicit trust, the
measurement made by the root of trust code can actually be attested to by a
third party, and this is typically done.

The trust anchor used by a relying party to verify this attestation may also
come with implicit trust, the verification of the measurement made by the
root of trust does not.

I think that terms RoT Storage/etc. are even more confusing.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Sep 2019 13:07:48 -0400

Salz, Rich <[email-masked]> wrote:
    > Okay, I’m in the minority about the definition of RoT, thanks for the
    > update.  FYI, this will probably confuse other people coming here from
    > a strong PKIX/TLS background, so please make it very explicit.

Thanks for making my point, that this is going to confuse people.
Particularly since I'm told that some non-english languages do not put a lot
of importance to order of words.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Sep 2019 13:09:47 -0400

> titled SAE Trust Anchors and Authentication.  In addition, the SAE J3101

okay, so if we reference any SAE documents, let's be really specific about
what we mean, and let's not use the SAE documents as reasonable sources of
clear definitions ;-)

If there were some alternate words that we could use for self-measuring code,
then I'd like to use that term ourselves.  I'd rather break down the spectrum
of the terms into it's component "colours".

---

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Tue, 17 Sep 2019 00:51:33 +0000

Hi Carl,
The other big difference between them is the object they deal with: RoT is for integrity measurement value chain, CA is for certificate chain.

Hope it is helpful.

B.R.
Frank

-----邮件原件-----
发件人: RATS [mailto:[email-masked]] 代表 Carl Wallace
发送时间: 2019年9月16日 20:26
收件人: Laurence Lundblade <[email-masked]>; Salz, Rich <[email-masked]>
抄送: Michael Richardson <[email-masked]>; [email-masked]
主题: Re: [Rats] use case document updates on Roots of Trust

I took Rich's statement to be more from a relying party perspective and your detail to be more what one might find in a policy describing nature of the root of trust, which is not that different from how one may describe a trust anchor/CA in a PKIX context in a policy that describes how a CA are operated, etc. Two sides of the same coin.

On 9/15/19, 4:50 PM, "RATS on behalf of Laurence Lundblade"
<[email-masked] on behalf of [email-masked]> wrote:

>> I do not see a meaningful difference between "trust anchor" and 
>>"trust root" and "root(s) of trust."  All of them:
>generally used in the TCG or TEE worlds. I think a root of trust 
>involves a CPU, memory and SW that actively does something like boot 
>and measure a device. There is usually a boundary around it so that 
>other software on the device, like the high-level OS, can’t corrupt it. 
>When it is doing reporting as in RATS it will have a private key that can do some signing.

---

From: Carl Wallace <[email-masked]>
Date: Mon, 16 Sep 2019 22:18:57 -0400

The definition of a trust anchor does not limit the scope to certificate chains. 

> On Sep 16, 2019, at 8:51 PM, Xialiang (Frank, Network Standard & Patent Dept) <[email-masked]> wrote:
> 
> Hi Carl,

---

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Tue, 17 Sep 2019 02:21:42 +0000

Can you give some other examples?

-----邮件原件-----
发件人: Carl Wallace [mailto:[email-masked]] 
发送时间: 2019年9月17日 10:19
收件人: Xialiang (Frank, Network Standard & Patent Dept) <[email-masked]>
抄送: Laurence Lundblade <[email-masked]>; Salz, Rich <[email-masked]>; Michael Richardson <[email-masked]>; [email-masked]
主题: Re: 答复: [Rats] use case document updates on Roots of Trust

>> When it is doing trusted/secure boot, it will also have a public key 
>> to verify the software it loads.
>> 
>> LL
>> 
>>