Subject: Re: [Rats] Early AD Review of draft-ietf-rats-architecture-13

From: Michael Richardson <[email-masked]>
Date: Thu, 9 Dec 2021 15:03:42 -0500

On 2021-11-12 4:15 p.m., Roman Danyliw wrote$
    > ** Section 3.1.
    >
    > There is no limit to or requirement on the types
    > of hardware or software environments that can be used to
    > implement an
    > Attesting Environment, for example: Trusted Execution Environments
    > (TEEs), embedded Secure Elements (eSEs), Trusted Platform Modules
    > (TPMs) [TCGarch], or BIOS firmware.
    >
    > To reinforce that software only solutions are acceptable too should
    > 'software agent' or something to that effect be added to
    > the following
    > example list?

This became issue: https://github.com/ietf-rats-wg/architecture/issues/356
The design team felt that TEE was sufficiently connected to software 
that we didn't think we needed to add any additional text to clarify this.

https://github.com/ietf-rats-wg/architecture/issues/357
we dealt with many of the pieces here.

    > ** Section 3.3. Editorial. s/In consequence/Consequently,/
    >
    > ** Section 4. The following terms appeared repeatedly in
    > the document
    > but were defined here: root of trust, target environment, and lead
    > attester. Should they be?

The term "root of trust" is too slippery for us to attempt to define.
The design team, and the WG as a whole dealt with this at length when we
started, and the conclusion was that:
   1) others (including the TCG) have already tried.
   2) that the term is generally understood among those doing
      attestation work
   3) that even just trying to pick a single source for defining it
      is too difficult

The other terms, "Target Environment" and "Lead Attester" are defined 
more clearly in section 3.

    > ** Section 4.1. Relying Party. Figure 1 says that the relying party
    > also consume the "Appraisal Policy for Attestation Results" by that
    > isn't noted here.
    >
    > ** Section 4.*. Editorial.
    > -- Section 4.1. In the definition of relying party, what does the
    > sentence fragment "Compare /relying party/ in [RFC4949]" mean?
    > -- Section 4.2. Per the definition of "Claim", what does "Compare
    > /claim/ in [RFC7519]" mean?

Where we write "compare", our intention is to encourage the reader to 
get more context about the meaning of Relying Parties outside of the 
terminology specific use in this document.
The definitions are similar.  We don't think we need to repeat here.

    > -- Section 4.3. Per the definition of "Appraisal Policy for
    Attestation Results", what does "Compare /security policy/ in
    [RFC4949]" mean?

This list of editorial changes became:
      https://github.com/ietf-rats-wg/architecture/issues/357

and we dealt with most of them, but:

    >
    > ** Section 4.2. Claim is the only definition that doesn't
    > explicitly
    > call out what "consumes" and "produces" it.

That is intentional. It is actually the only term that is neither about 
a conceptual message nor a role. It still work slightly different than 
the encoding specific claim definitions in web tokens and belongs into 
the terminology. We could not find a way to fix this would make many 
passages less readable.

https://github.com/ietf-rats-wg/architecture/issues/360

    > ** Section 8.1
    > Evidence is appraised by a Verifier to establish
    > its relevance, compliance, and timeliness
    >
    > What is meant by having to establish that evidence is relevant? Is
    > the concern that the Attester would provide evidence that is not
    > relevant? Is than attack or attempt a subterfuge?

We are erring on the side of the attester oversharing, and we deal with 
this issue in the Privacy Considerations.

https://github.com/ietf-rats-wg/architecture/issues/362
    > ** Section 8.2. This section is a subsection of Section 8
    > which seems to be scoped around "conceptual messages".
    > It isn't clear to me what "conceptual messages" or
    > channel properties are being described here.

The reader is expected to know that "roles" input and output "conceptual
messages" that are conveyed by some form of protocol payload or message.
We agree that the term "conceptual message" isn't that intuitive.
There is a definition in the Intro that seems adequate but if the reader
didn't internalize this then it may require rereading.

_Conceptual Message_ was a compromise that nobody really loved but also 
nobody could find a better name for. Suggestions welcome!

---

From: Ira McDonald <[email-masked]>
Date: Thu, 9 Dec 2021 16:36:14 -0500

Hi Michael,

Replying to one of your comments:

"The term "root of trust" is too slippery for us to attempt to define.
      is too difficult"

I note that the TCG RoT definition is terrible and not useful.  And it's
the only
definition (from the ISO TPM spec) in the ISO Online Dictionary.

BUT, the NIST Online Glossary has this very good definition, taken from NIST
SP800-172 [https://doi.org/10.6028/NIST.SP.800-171r2]:

"Roots of Trust: Highly reliable hardware, firmware, and software
components
that perform specific, critical security functions. Because roots of trust
are
inherently trusted, they must be secure by design. Roots of trust provide a
firm
foundation from which to build security and trust."

I have used this RoT definition in documents in several other SDOs and it
has
been well-received, FWIW.

Cheers,
- Ira

*Ira McDonald (Musician / Software Architect)*

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

*Co-Chair - TCG Metadata Access Protocol SG*

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

On Thu, Dec 9, 2021 at 3:04 PM Michael Richardson <[email-masked]>
wrote:

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 09 Dec 2021 17:55:09 -0500

> been well-received, FWIW.

If the WG would like to use this, it can be added, with a pointer.
I hope the other authors will express some thoughts here.

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

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 9 Dec 2021 16:19:59 -0800

> On Dec 9, 2021, at 2:55 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

I have a strong objection to that definition of root of trust because it orients to a particular security strength.

I believe there is general agreement that RATS doesn’t require any particular level of security strength. There is text in various RATS document that says this. We want to accommodate use case where the HW in use is what ever it is, where individual Android/IOS apps can be attesters and so on.

Further that definition is very subjective. For example, it doesn’t say if it has to defend against HW attacks like clock glitching and fault injection. It doesn’t mention side channels.It doesn’t calibrate to anything like CC Attack Potential.

Going back many years here, I’ve asked to avoid the term “root of trust” because a definition of it for use here would be counter to common definitions like the one above. I also think it is used as a marketing term, which further dilutes is use.

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 13 Dec 2021 11:55:07 -0800

A couple of things about a definition of root of trust in RATS:

- Root of Trust for Attestation —  The root of trust for attestation will often be the same as the root of trust for the device (secure boot stuff), but we can’t make that a requirement that they be the same, so if we use the term, it has to be “root of trust for attestation”, never “root of trust”.

- Not security-level specific — If we use the term, we must make it clear it applies equally to varying degrees of security from very minimal use cases that are just in an Android app or are an IoT devices that rely on the plastic housing and correct SW all the way to state of the art certified HW that uses specialized chips, and even on to quantum safe.

I’m not very keen on that definition below. It mostly seems to say “some important stuff that is secure”.
- It doesn’t say what it actually does
- It doesn’t say how secure
- It doesn’t accommodate varying degree of security

I take the varying level of security as critical. It is reasonable for an Internet toaster to use attestation just as it is for an Ingenico payment terminal. They have really different security requirements and cost structures. If someone breaks the toaster they don’t get much. If some one breaks the payment terminal, they are going to get a lot. Cost structures don’t allow the toaster to have the same security chip as the payment terminal.

It’s also interesting to look at the work to break iPhone of the San Bernardino gunman <https://en.wikipedia.org/wiki/FBI%E2%80%93Apple_encryption_dispute>. A lot of people mustered a lot of resources to break that. Something minimally built to the below definition of Root of Trust would have been broken in minutes.

I think we need a definition that side steps degree of security and focuses on the role. One of the best things Henk said to me was, “if your best friend is the worst best friend in the world, he’s still your best friend”. It’s about the role of friendship, not about how good the friendship is. A definition of a root of trust of XXX should not be about level of security but rather about its role as the most-trusted part of the system, the part fundamentally relied upon for the security of the whole system.

Here’s a first pass for how I’d define it:

A root of trust is some hardware, firmware and software that are the base trusted subsystem. It is called a root because nothing is more trusted than it and other subsystems fundamentally rely on its security. If its security is compromised generally, everything else in the device is compromised.

Because of this, roots of trust are often implemented with a high level of security. They are often small so they can be more secure and so they can be certified. They often use specialized HW. However, they do vary in the amount of security they provide depending on the cost structure and requirements of the use case, so there is such a thing as a (relatively) low-security root of trust. The important characteristic in their identification and definition is that they form the basis for the security of the device.

LL

> On Dec 9, 2021, at 4:19 PM, Laurence Lundblade <[email-masked]> wrote:
> 
> 
>>> components that perform specific, critical security functions. Because roots of trust
>>> are inherently trusted, they must be secure by design. Roots of trust provide a
>>> firm foundation from which to build security and trust."
>>

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 13 Dec 2021 21:12:10 +0100

Hi Laurence,

"root of trust for attestation" sounds like yet another super class to 
me and not really adding value to the already defined zoo of roots of 
trust types.

In general, a root of trust does exactly what it is intended to and does 
never do other things. The protected capabilities provided by a root of 
trust must be endorsed from the outside as it cannot generate evidence 
about them itself.

Going into criticality levels, distinguishing between software and 
hardware roots of trust, or pulling in arbitrary examples does not look 
productive to me at this stage.

Some assertions made about roots of trust (pun intended) in the current 
text seem to be incorrect in cases where symmetric key pairs are used 
and therefore seem artificially constrained. That's the topic for the 
editor's meeting tomorrow.

Viele Grüße,

Henk

On 13.12.21 20:55, Laurence Lundblade wrote:
> - Root of Trust*for Attestation* —  The root of trust for attestation 
> will often be the same as the root of trust for the device (secure boot 
> stuff), but we can’t make that a requirement that they be the same, so 
> if we use the term, it has to be “root of trust for attestation”, never 
> “root of trust”.
> 
> - Not security-level specific — If we use the term, we must make it 
> clear it applies equally to varying degrees of security from very 
> minimal use cases that are just in an Android app or are an IoT devices 
> that rely on the plastic housing and correct SW all the way to state of 
> the art certified HW that uses specialized chips, and even on to quantum 
> safe.
> 
> I take the varying level of security as critical. It is reasonable for 
> an Internet toaster to use attestation just as it is for an Ingenico 
> payment terminal. They have really different security requirements and 
> cost structures. If someone breaks the toaster they don’t get much. If 
> some one breaks the payment terminal, they are going to get a lot. Cost 
> structures don’t allow the toaster to have the same security chip as the 
> payment terminal.
> 
> It’s also interesting to look at the work to breakiPhone of the San 
> Bernardino gunman 
> <https://en.wikipedia.org/wiki/FBI%E2%80%93Apple_encryption_dispute>. A 
> lot of people mustered a lot of resources to break that. Something 
> minimally built to the below definition of Root of Trust would have been 
> broken in minutes.
> 
> 
> I think we need a definition that side steps degree of security and 
> focuses on the role. One of the best things Henk said to me was, “if 
> your best friend is the worst best friend in the world, he’s still your 
> best friend”. It’s about the role of friendship, not about how good the 
> friendship is. A definition of a root of trust of XXX should not be 
> about level of security but rather about its role as the most-trusted 
> part of the system, the part fundamentally relied upon for the security 
> of the whole system.
> 
>     A root of trust is some hardware, firmware and software that are the
>     base trusted subsystem. It is called a root because nothing is more
>     trusted than it and other subsystems fundamentally rely on its
>     security. If its security is compromised generally, everything else
>     in the device is compromised.
> 
>     Because of this, roots of trust are often implemented with a high
>     level of security. They are often small so they can be more secure
>     and so they can be certified. They often use specialized HW.
>     However, they do vary in the amount of security they provide
>     depending on the cost structure and requirements of the use case, so
>     there is such a thing as a (relatively) low-security root of trust.
>     The important characteristic in their identification and definition
>     is that they form the basis for the security of the device.
> 
> 
> LL
> 
> 
> 
>> On Dec 9, 2021, at 4:19 PM, Laurence Lundblade <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>>> On Dec 9, 2021, at 2:55 PM, Michael Richardson <[email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>>
>>>
>>> Ira McDonald <[email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>>> <https://doi.org/10.6028/NIST.SP.800-171r2]:>
>>>
>> I have a strong objection to that definition of root of trust because 
>> it orients to a particular security strength.
>>
>> I believe there is general agreement that RATS doesn’t require any 
>> particular level of security strength. There is text in various RATS 
>> document that says this. We want to accommodate use case where the HW 
>> in use is what ever it is, where individual Android/IOS apps can be 
>> attesters and so on.
>>
>> Further that definition is very subjective. For example, it doesn’t 
>> say if it has to defend against HW attacks like clock glitching and 
>> fault injection. It doesn’t mention side channels.It doesn’t calibrate 
>> to anything like CC Attack Potential.
>>
>> Going back many years here, I’ve asked to avoid the term “root of 
>> trust” because a definition of it for use here would be counter to 
>> common definitions like the one above. I also think it is used as a 
>> marketing term, which further dilutes is use.
>>
>> LL
>>
> 
>

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 13 Dec 2021 21:26:25 +0100

And as I just learned, the issue with the symmetric key phrasing is 
related to the use of trust anchors and not the roots of trust. Of 
course, this comes to my attention right after I send out a 
corresponding email :-)

In any case, the root of trust usage topic will also be on the agenda 
tomorrow - only after the trust anchor editorial issues.

On 13.12.21 21:12, Henk Birkholz wrote:
>> will often be the same as the root of trust for the device (secure 
>> boot stuff), but we can’t make that a requirement that they be the 
>> same, so if we use the term, it has to be “root of trust for 
>> attestation”, never “root of trust”.
>>
>> minimal use cases that are just in an Android app or are an IoT 
>> devices that rely on the plastic housing and correct SW all the way to 
>> state of the art certified HW that uses specialized chips, and even on 
>> to quantum safe.
>>
>> some one breaks the payment terminal, they are going to get a lot. 
>> Cost structures don’t allow the toaster to have the same security chip 
>> as the payment terminal.
>>
>> <https://en.wikipedia.org/wiki/FBI%E2%80%93Apple_encryption_dispute>. 
>> A lot of people mustered a lot of resources to break that. Something 
>> minimally built to the below definition of Root of Trust would have 
>> been broken in minutes.
>>
>>
>> your best friend is the worst best friend in the world, he’s still 
>> your best friend”. It’s about the role of friendship, not about how 
>> good the friendship is. A definition of a root of trust of XXX should 
>> not be about level of security but rather about its role as the 
>> most-trusted part of the system, the part fundamentally relied upon 
>> for the security of the whole system.
>>
>>>> On Dec 9, 2021, at 2:55 PM, Michael Richardson 
>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>
>>> fault injection. It doesn’t mention side channels.It doesn’t 
>>> calibrate to anything like CC Attack Potential.
>>>

---

From: Ira McDonald <[email-masked]>
Date: Mon, 13 Dec 2021 15:29:48 -0500

Hi Laurence,

The concept of a Root of Trust for Attestation is a fine idea.

However, you imply that secure boot only takes one Root of Trust.

In both NIST SP800 series and TCG specs, there are several RoTs that are
necessary to
implement basic secure boot:

Root of Trust for Measurement (RTM)
- to hash or otherwise summarize a series of measurements

Root of Trust for Storage (RTS)
- to protect the results of RTM operations

Root of Trust for Reporting (RTR)
- which *might* be what you're calling a Root of Trust for Attestation (I'm
unclear about this).

As you've observed, trust is NOT binary, it's a context-sensitive degree of
trustworthiness based
on out-of-band contracts, out-of-band configuration, runtime proof of
integrity, etc...

IETF RFC 8485 Vectors of Trust [
https://datatracker.ietf.org/doc/html/rfc8485] is a good read.

ITU-T X.1254 Entity Authentication Assurance Framework [
https://www.itu.int/rec/T-REC-X.1254]
underlies many TCG, DMTF, ETSI, and other SDO security specs.

Cheers,
- Ira

On Mon, Dec 13, 2021 at 2:55 PM Laurence Lundblade <[email-masked]>
wrote:

> - Root of Trust* for Attestation* —  The root of trust for attestation
> stuff), but we can’t make that a requirement that they be the same, so if
> we use the term, it has to be “root of trust for attestation”, never “root
> of trust”.
>
> - Not security-level specific — If we use the term, we must make it clear
> it applies equally to varying degrees of security from very minimal use
> cases that are just in an Android app or are an IoT devices that rely on
> the plastic housing and correct SW all the way to state of the art
> certified HW that uses specialized chips, and even on to quantum safe.
>
> I take the varying level of security as critical. It is reasonable for an
> Internet toaster to use attestation just as it is for an Ingenico payment
> terminal. They have really different security requirements and cost
> structures. If someone breaks the toaster they don’t get much. If some one
> breaks the payment terminal, they are going to get a lot. Cost structures
> don’t allow the toaster to have the same security chip as the payment
> terminal.
>
> It’s also interesting to look at the work to break iPhone of the San
> Bernardino gunman
> focuses on the role. One of the best things Henk said to me was, “if your
> best friend is the worst best friend in the world, he’s still your best
> friend”. It’s about the role of friendship, not about how good the
> friendship is. A definition of a root of trust of XXX should not be about
> level of security but rather about its role as the most-trusted part of the
> system, the part fundamentally relied upon for the security of the whole
> system.
>
> A root of trust is some hardware, firmware and software that are the base
> trusted subsystem. It is called a root because nothing is more trusted than
> it and other subsystems fundamentally rely on its security. If its security
> is compromised generally, everything else in the device is compromised.
>
> Because of this, roots of trust are often implemented with a high level of
> security. They are often small so they can be more secure and so they can
> be certified. They often use specialized HW. However, they do vary in the
> amount of security they provide depending on the cost structure and
> requirements of the use case, so there is such a thing as a (relatively)
> low-security root of trust. The important characteristic in their
> identification and definition is that they form the basis for the security
> of the device.
>
>
> LL
>
>
>
> I have a strong objection to that definition of root of trust because it
> orients to a particular security strength.
>
> document that says this. We want to accommodate use case where the HW in
> use is what ever it is, where individual Android/IOS apps can be attesters
> and so on.
>
> Further that definition is very subjective. For example, it doesn’t say if
> it has to defend against HW attacks like clock glitching and fault
> injection. It doesn’t mention side channels.It doesn’t calibrate to
> anything like CC Attack Potential.
>
> Going back many years here, I’ve asked to avoid the term “root of trust”
> because a definition of it for use here would be counter to common
> definitions like the one above. I also think it is used as a marketing
> term, which further dilutes is use.
>
> LL
>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Dec 2021 16:30:14 -0500

Laurence Lundblade <[email-masked]> wrote:
    > - Root of Trust for Attestation —  The root of trust for attestation

Secure boot involves validating a signature, and therefore involves a public
key, or a trust anchor, not a root of trust.

And creating Evidence for attestation involves a private key, not a public key.

So, "root of trust for attestation" is either nonsense (if you think
root-of-trust is code) or it's a contradiction in terms (if you think
root-of-trust is a public key).

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Mon, 13 Dec 2021 22:50:45 +0000

If anyone is interested, there is a pretty extensive set of definitions and requirements for a Root of Trust created by GlobalPlatform at https://globalplatform.wpengine.com/wp-content/uploads/2018/07/GP_RoT_Definitions_and_Requirements_v1.1_PublicRelease-2018-06-28.pdf. As a requirements document this one is not behind a click-through agreement.

It is quite a long document, and although some material could be omitted (especially in RATS context) it does try to cover some of the complexities of Roots of Trust – it came about as a consequence of similar internal discussions on the RoT concept to the one in this WG.

The definitions are inclusive of NIST SP800-164 guidelines and the TCG Glossary.

Reduced to its essence, the RoT is that part of a system that has to be implicitly trusted because there is no meaningful way to measure it as it is immutable. As Laurence mentions, it almost always a combination of hardware and immutable code.

A _useful_ Root of Trust provides a set of services - Attestation being one possibility – which are usually useful because the RoT can contain key material and perform cryptographic operations.

My main take-away on this is that there really is no single short definition of a Root of Trust that is both universally applicable and useful, but at the risk of inviting Nemesis to visit, I’ll have a go anyway:

“A Root of Trust is a combination of hardware, firmware, software and keys that are implicitly trusted to provide foundational security services to other subsystems. If it is compromised, the entire device is also compromised. A Root of Trust containing a shielded private or secret key can provide services to an Attesting Environment – this service is called the Root of Trust for Attestation.

As a compromised Root of Trust leads to compromise of the entire device, Roots of Trust are often designed to protect against specific threats. There is extensive literature covering RoT security including [NIST SP 800-164], [TCG Glossary], [GlobalPlatform RoT Requirements].“

Best regards
Jeremy

On 13/12/2021, 21:30, "RATS" <[email-masked]> wrote:

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 14 Dec 2021 00:24:57 +0100

Hi Jeremy,

we could work from there. I am way more comfortable with this kind if 
definition. Consequences of "compromization" should be clear from the 
definition itself though, I think.

On the one hand, I am still quite hesitant to bring the term "rot for 
attestation" into play.

On the other hand, the service provided is definitely using "protected 
capabilities" as defined in the TCG. So there is semantic synergy 
already. I think we can work from the first paragraph. If at least three 
SDOs would be comfortable with the result, that I would call real 
progress. So it is worth a try from my point of view.

Viele Grüße,

Henk

On 13.12.21 23:50, Jeremy O'Donoghue wrote:
> If anyone is interested, there is a pretty extensive set of definitions 
> and requirements for a Root of Trust created by GlobalPlatform at 
> https://globalplatform.wpengine.com/wp-content/uploads/2018/07/GP_RoT_Definitions_and_Requirements_v1.1_PublicRelease-2018-06-28.pdf 
> <https://globalplatform.wpengine.com/wp-content/uploads/2018/07/GP_RoT_Definitions_and_Requirements_v1.1_PublicRelease-2018-06-28.pdf>. 
> As a requirements document this one is not behind a click-through agreement.
> 
> It is quite a long document, and although some material could be omitted 
> (especially in RATS context) it does try to cover some of the 
> complexities of Roots of Trust – it came about as a consequence of 
> similar internal discussions on the RoT concept to the one in this WG.
> 
> Reduced to its essence, the RoT is that part of a system that has to be 
> implicitly trusted because there is no meaningful way to measure it as 
> it is immutable. As Laurence mentions, it almost always a combination of 
> hardware and immutable code.
> 
> A _/useful/_ Root of Trust provides a set of services - Attestation 
> being one possibility – which are usually useful because the RoT can 
> contain key material and perform cryptographic operations.
> 
> My main take-away on this is that there really is no single short 
> definition of a Root of Trust that is both universally applicable and 
> useful, but at the risk of inviting Nemesis to visit, I’ll have a go anyway:
> 
> “A Root of Trust is a combination of hardware, firmware, software and 
> keys that are implicitly trusted to provide foundational security 
> services to other subsystems. If it is compromised, the entire device is 
> also compromised. A Root of Trust containing a shielded private or 
> secret key can provide services to an Attesting Environment – this 
> service is called the Root of Trust for Attestation.
> 
> As a compromised Root of Trust leads to compromise of the entire device, 
> Roots of Trust are often designed to protect against specific threats. 
> There is extensive literature covering RoT security including [NIST SP 
> 800-164], [TCG Glossary], [GlobalPlatform RoT Requirements].“
> 
> Best regards
> 
> Jeremy
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary 
> of any links or attachments, and do not enable macros.
> 
>      > - Root of Trust for Attestation —  The root of trust for attestation
>      > will often be the same as the root of trust for the device 
> (secure boot
>      > stuff), but we can’t make that a requirement that they be the 
> same, so
>      > if we use the term, it has to be “root of trust for attestation”, 
> never
>      > “root of trust”.
>

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 13 Dec 2021 16:48:05 -0800

> However, you imply that secure boot only takes one Root of Trust.

It was just an accidental turn of a phrase in my example. Main point is that the things that implement Attestation might not be any of the things we’re currently calling a RoT.

> 
> In both NIST SP800 series and TCG specs, there are several RoTs that are necessary to 
> - which *might* be what you're calling a Root of Trust for Attestation (I'm unclear about this).
> 
> As you've observed, trust is NOT binary, it's a context-sensitive degree of trustworthiness based 
> on out-of-band contracts, out-of-band configuration, runtime proof of integrity, etc...
> 
> IETF RFC 8485 Vectors of Trust [https://datatracker.ietf.org/doc/html/rfc8485 <https://datatracker.ietf.org/doc/html/rfc8485>] is a good read.
> 
> ITU-T X.1254 Entity Authentication Assurance Framework [https://www.itu.int/rec/T-REC-X.1254 <https://www.itu.int/rec/T-REC-X.1254>]

Pretty much agree with all this above.

LL

> 
> Cheers,
> - Ira
> 
> 
> Ira McDonald (Musician / Software Architect)
> Chair - SAE Trust Anchors and Authentication TF
> Co-Chair - TCG Trusted Mobility Solutions WG
> Co-Chair - TCG Metadata Access Protocol SG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
> http://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>
> http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> mailto: [email-masked] <mailto:[email-masked]>
> (permanent) PO Box 221  Grand Marais, MI 49839  906-494-2434
> 
> 
> On Mon, Dec 13, 2021 at 2:55 PM Laurence Lundblade <[email-masked] <mailto:[email-masked]>> wrote:
>> On Dec 9, 2021, at 4:19 PM, Laurence Lundblade <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>>> On Dec 9, 2021, at 2:55 PM, Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
>>> Ira McDonald <[email-masked] <mailto:[email-masked]>> wrote:
>>>> SP800-172 [https://doi.org/10.6028/NIST.SP.800-171r2]: <https://doi.org/10.6028/NIST.SP.800-171r2%5D:>
>>>

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 14 Dec 2021 05:41:42 +0000

(speaking not as chair)

The arch design team decided not to define RoT because there is no easy way to do this that is universally accepted. There are a few NIST documents that try to define a focused set of roots of trust (e.g., SP800-193 defines resiliency roots of trust and SP800-164 defines terms also used by TCG).

My point is that use of the term ‘trust’ has to be qualified or it is meaningless. Hence, the convention for “Root of Trust for Reporting – RTR” etc.

If I were to consider the RATS Arch discussion on Attesting Environments, the RTR is clearly intended functionality. It also describes ‘claims collection’ which could be interpreted to mean root-of-trust for measurement (RTM). There isn’t strong language about storage of anything in an Attesting Environment but could be interpreted that way.

Given these other documents exist already, I don’t see a strong need to try to define ‘root of trust’ in the abstract. Possibly, the RATS Arch should reference the NIST publications if it doesn’t already?

I might add that defining RoT abstractly opens the door for having to define trusted functionality that might exist in one or more target environments that may perform ‘trusted’ functionality such as collecting claims and/or creating evidence (not as a root layer).

The RATS arch already addresses the consideration that Attesting Environments could be nested / layered but doesn’t try to assign a special term to non-root-of-trust-but-trusted environments.

Do various draft authors find it challenging to write concise understandable text unless there is a rich vocabulary for root-of-trust things and other trusted things that might be layered on a root of trust?

Thx,
Ned

From: RATS <[email-masked]> on behalf of Laurence Lundblade <[email-masked]>
Date: Monday, December 13, 2021 at 4:48 PM
To: Ira McDonald <[email-masked]>
Cc: Michael Richardson <[email-masked]>, rats <[email-masked]>
Subject: Re: [Rats] Root of Trust (was Re: Early AD Review of draft-ietf-rats-architecture-13)

On Dec 13, 2021, at 12:29 PM, Ira McDonald <[email-masked]<mailto:[email-masked]>> wrote:

Hi Laurence,

IETF RFC 8485 Vectors of Trust [https://datatracker.ietf.org/doc/html/rfc8485] is a good read.

ITU-T X.1254 Entity Authentication Assurance Framework [https://www.itu.int/rec/T-REC-X.1254]
underlies many TCG, DMTF, ETSI, and other SDO security specs.

LL

Cheers,
- Ira

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

On Mon, Dec 13, 2021 at 2:55 PM Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:
A couple of things about a definition of root of trust in RATS:

It’s also interesting to look at the work to break iPhone of the San Bernardino gunman<https://en.wikipedia.org/wiki/FBI%E2%80%93Apple_encryption_dispute>. A lot of people mustered a lot of resources to break that. Something minimally built to the below definition of Root of Trust would have been broken in minutes.

LL

On Dec 9, 2021, at 4:19 PM, Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:

On Dec 9, 2021, at 2:55 PM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

Ira McDonald <[email-masked]<mailto:[email-masked]>> wrote:

BUT, the NIST Online Glossary has this very good definition, taken from NIST
SP800-172 [https://doi.org/10.6028/NIST.SP.800-171r2]:<https://doi.org/10.6028/NIST.SP.800-171r2%5D:>

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 14 Dec 2021 00:02:22 -0800

> On Dec 13, 2021, at 12:12 PM, Henk Birkholz <[email-masked]> wrote:
> 
> In general, a root of trust does exactly what it is intended to and does never do other things.

That is impossible to guarantee because a) it might be attacked successfully and b) the implementor of it might have made a mistake.

However, I think the sentiment behind this is that a RoT is the subsystem that is most fundamentally trusted. Nothing it trusted more. If it doesn’t do what is intended everything above it fails. That is a fine definition and works for me, but it’s not the same as “does exactly what is intended”.

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 14 Dec 2021 00:06:40 -0800

> On Dec 13, 2021, at 2:50 PM, Jeremy O'Donoghue <[email-masked]> wrote:
> 
> “A Root of Trust is a combination of hardware, firmware, software and keys that are implicitly trusted to provide foundational security services to other subsystems.

Yes

> If it is compromised, the entire device is also compromised.

It depends on the what the RoT does in the device. Maybe only part is compromised. I think “what relies on the RoT” is compromised.

> A Root of Trust containing a shielded private or secret key can provide services to an Attesting Environment – this service is called the Root of Trust for Attestation.

Yes as long as shielding can mean process separation, or maybe not even that for a tiny device.

>  
> As a compromised Root of Trust leads to compromise of the entire device, Roots of Trust are often designed to protect against specific threats.

Maybe not the whole device in some cases.

> There is extensive literature covering RoT security including [NIST SP 800-164], [TCG Glossary], [GlobalPlatform RoT Requirements].“

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 14 Dec 2021 00:18:32 -0800

How about we use “Attesting Environment”? Seems like it lines up very well to me and as described in the document is pretty close to a RoT for Attestation. 

(It does seem to be a capitalized term without a definition — that should probably be fixed regardless).

> On Dec 13, 2021, at 9:41 PM, Smith, Ned <[email-masked]> wrote:
> 
> (speaking not as chair)
>  
> ...
>  

I can’t see how use of the term makes the text better or that there are gaps in the text that it would fill.

Most of the definitions of RoT I’ve seen have problems for our use here:
- Doesn’t take into account the needed range of security levels
- The RoT for Attestation does not need to the the same as other RoTs on the device

Definitions and understanding of RoT seems pretty variable to me and some of them clearly don’t work without modification.

I think we could use “Attesting Environment” and then add a sentence like this: “an Attesting Environment can be thought of as a Root of Trust for Attestation, for those familiar with Roots of Trust."

LL

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 14 Dec 2021 10:08:45 +0100

On 14.12.21 09:02, Laurence Lundblade wrote:
> 
>> On Dec 13, 2021, at 12:12 PM, Henk Birkholz 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
> That is impossible to guarantee because a) it might be attacked 
> successfully and b) the implementor of it might have made a mistake.

Yes, exactly.

> 
> However, I think the sentiment behind this is that a RoT is the 
> subsystem that is most fundamentally trusted. Nothing it trusted more. 
> If it doesn’t do what is intended everything above it fails. That is a 
> fine definition and works for me, but it’s not the same as “does exactly 
> what is intended”.

Yes. Intended to do exactly what it is intended to do an doing not other 
things :-) And that trust is relatively blind, as you cannot generate 
evidence about it. Otherwise, it would be the popular turtles all the 
way down.

We are forced to trust our root turtle. As that is a horrible situation, 
the responsible supply chain entities have to relief that pain here as 
best as they can by providing cryptographically bound assertions to our 
dear but unfortunately fallible root turtle.

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 14 Dec 2021 10:42:09 +0100

On 14.12.21 09:06, Laurence Lundblade wrote:
> 
> 
>> On Dec 13, 2021, at 2:50 PM, Jeremy O'Donoghue 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> services to other subsystems.
> 
> Yes

While this is mostly correct, "security services" could be perceived as 
too broad. Also hardware, firmware, and software form a non-empty set. 
So it's a selection of the above, at least one of the above :-)

Also, the keys that come with a root of trust have key usages. At the 
very minimum, dedicated key material is involved in asserting subject 
identity of the system that comprises a root of trust.

The RTR example Ned highlighted before has at least one more protected 
capability: the generation of evidence ("reporting"). This protected 
capability also requires key material. And I hope it is clear why it is 
strongly, strongly recommended to use different key material for 
different usages.

> It depends on the what the RoT does in the device. Maybe only part is 
> compromised. I think “what relies on the RoT” is compromised.
> 

While intuitive, "device" is a bit of an arbitrary scope. But that is 
not a hill I will die on :-)

>> A Root of Trust containing a shielded private or secret key can 
>> provide services to an Attesting Environment – this service is called 
>> the Root of Trust for Attestation.
> 

If you cannot render your key material isolated or shielded than the 
system cannot be trusted. It is as simple as that. Such a system is 
generating "Evidence" with the believability of a Claim. Actually, 
calling the output "Evidence" would be closer to a lie than to the truth.

> 
>> As a compromised Root of Trust leads to compromise of the entire 
>> device, Roots of Trust are often designed to protect against specific 
>> threats.
> 

I would recommend to assume the worst. Actually, I am always assuming 
that the protected capabilities providing shielding and isolation of key 
material have weaknesses that we are unaware of. This does not render 
our effort mood. Technology tends to become better over time (and at 
some point email). But additional checks and balances to re-evaluate 
trust assumptions and trust relationships should be in place.

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 14 Dec 2021 10:52:55 +0100

On 14.12.21 09:18, Laurence Lundblade wrote:
> How about we use “Attesting Environment”? Seems like it lines up very 
> well to me and as described in the document is pretty close to a RoT for 
> Attestation.

Yes

>> On Dec 13, 2021, at 9:41 PM, Smith, Ned <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> (speaking not as chair)
>> ...
>> Do various draft authors find it challenging to write concise 
>> understandable text unless there is a rich vocabulary for 
>> root-of-trust things and other trusted things that might be layered on 
>> a root of trust?
> 

The use of the term "root of trust" connects this document to the rest 
of the world. We have to live with the quality of the rest of the world. 
We can try to improve that quality to some extend via our scope by 
choosing words with a little bit of delicate care and lots of heated 
debates.

> Definitions and understanding of RoT seems pretty variable to me and 
> some of them clearly don’t work without modification.
> 
> I think we could use “Attesting Environment” and then add a sentence 
> like this: “an Attesting Environment can be thought of as a Root of 
> Trust for Attestation, for those familiar with Roots of Trust."

I am strongly discouraging the introduction of yet another term to 
improve the usage of "Attesting Environment". Also, Attestation 
Environments can be layered and that would already break that statement, 
I think.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 15 Dec 2021 14:00:13 +0000

Hi Jeremy,

Thanks for your input.

It would be good to re-use definitions, whenever possible.

The definition you provide below is good*.

When I tried to find it in the referenced GP document I was unsuccessful. So, is the quoted definition from this document, from some other document or your own version?

Ciao
Hannes

PS: For me firmware = software.

From: RATS <[email-masked]> On Behalf Of Jeremy O'Donoghue
Sent: Monday, December 13, 2021 11:51 PM
To: Michael Richardson <[email-masked]>; Laurence Lundblade <[email-masked]>; Ira McDonald <[email-masked]>; rats <[email-masked]>
Subject: Re: [Rats] Root of Trust (was Re: Early AD Review of draft-ietf-rats-architecture-13)

It is quite a long document, and although some material could be omitted (especially in RATS context) it does try to cover some of the complexities of Roots of Trust - it came about as a consequence of similar internal discussions on the RoT concept to the one in this WG.

A _useful_ Root of Trust provides a set of services - Attestation being one possibility - which are usually useful because the RoT can contain key material and perform cryptographic operations.

My main take-away on this is that there really is no single short definition of a Root of Trust that is both universally applicable and useful, but at the risk of inviting Nemesis to visit, I'll have a go anyway:

"A Root of Trust is a combination of hardware, firmware, software and keys that are implicitly trusted to provide foundational security services to other subsystems. If it is compromised, the entire device is also compromised. A Root of Trust containing a shielded private or secret key can provide services to an Attesting Environment - this service is called the Root of Trust for Attestation.

As a compromised Root of Trust leads to compromise of the entire device, Roots of Trust are often designed to protect against specific threats. There is extensive literature covering RoT security including [NIST SP 800-164], [TCG Glossary], [GlobalPlatform RoT Requirements]."

Best regards
Jeremy

On 13/12/2021, 21:30, "RATS" <[email-masked]<mailto:[email-masked]>> wrote:

Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:
    > - Root of Trust for Attestation -  The root of trust for attestation
    > stuff), but we can't make that a requirement that they be the same, so
    > if we use the term, it has to be "root of trust for attestation", never
    > "root of trust".

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

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: Ira McDonald <[email-masked]>
Date: Wed, 15 Dec 2021 10:15:01 -0500

Hi Hannes and Jeremy,

On yesterdays RATS call on Trust Anchor (keep this term, we need it) and
Root of Trust, we had a strong consensus to *remove* all use of the RoT
term from the RATS Architecture - it's simply not needed.  Please take a
look at the GitHub writeup of our conversation, coming soon.

Cheers,
- Ira

On Wed, Dec 15, 2021 at 9:00 AM Hannes Tschofenig <[email-masked]>
wrote:

> When I tried to find it in the referenced GP document I was unsuccessful.
> So, is the quoted definition from this document, from some other document
> or your own version?
>
>
>
> Ciao
>
> Hannes
>
>
>
> *From:* RATS <[email-masked]> *On Behalf Of * Jeremy O'Donoghue
> *Sent:* Monday, December 13, 2021 11:51 PM
> *To:* Michael Richardson <[email-masked]>; Laurence Lundblade <
> [email-masked]>; Ira McDonald <[email-masked]>; rats <
> [email-masked]>
> *Subject:* Re: [Rats] Root of Trust (was Re: Early AD Review of
> draft-ietf-rats-architecture-13)
>
>
>
> https://globalplatform.wpengine.com/wp-content/uploads/2018/07/GP_RoT_Definitions_and_Requirements_v1.1_PublicRelease-2018-06-28.pdf.
> (especially in RATS context) it does try to cover some of the complexities
> of Roots of Trust – it came about as a consequence of similar internal
> discussions on the RoT concept to the one in this WG.
>
>
>
> implicitly trusted because there is no meaningful way to measure it as it
> is immutable. As Laurence mentions, it almost always a combination of
> A _*useful*_ Root of Trust provides a set of services - Attestation being
> one possibility – which are usually useful because the RoT can contain key
> material and perform cryptographic operations.
>
>
>
> “A Root of Trust is a combination of hardware, firmware, software and keys
> that are implicitly trusted to provide foundational security services to
> other subsystems. If it is compromised, the entire device is also
> compromised. A Root of Trust containing a shielded private or secret key
> can provide services to an Attesting Environment – this service is called
> WARNING: This email originated from outside of Qualcomm. Please be wary of
> any links or attachments, and do not enable macros.
>
> boot
> 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: Hannes Tschofenig <[email-masked]>
Date: Wed, 15 Dec 2021 15:39:45 +0000

That’s fine for me as well, Ira.

Independently of the architecture draft I am still curious about the RoT definition because it is a topic that frequently comes up.

Ciao
Hannes

From: RATS <[email-masked]> On Behalf Of Ira McDonald
Sent: Wednesday, December 15, 2021 4:15 PM
To: Hannes Tschofenig <[email-masked]>; Ira McDonald <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Jeremy O'Donoghue <[email-masked]>; Laurence Lundblade <[email-masked]>; rats <[email-masked]>
Subject: Re: [Rats] Root of Trust (was Re: Early AD Review of draft-ietf-rats-architecture-13)

Hi Hannes and Jeremy,

Cheers,
- Ira

On Wed, Dec 15, 2021 at 9:00 AM Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jeremy,

Thanks for your input.

Ciao
Hannes

From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Jeremy O'Donoghue
Sent: Monday, December 13, 2021 11:51 PM
To: Michael Richardson <[email-masked]<mailto:[email-masked]>>; Laurence Lundblade <[email-masked]<mailto:[email-masked]>>; Ira McDonald <[email-masked]<mailto:[email-masked]>>; rats <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Root of Trust (was Re: Early AD Review of draft-ietf-rats-architecture-13)

Best regards
Jeremy

---

From: Ira McDonald <[email-masked]>
Date: Wed, 15 Dec 2021 11:21:46 -0500

Hi Hannes,

I am also independently interested in crisp definitions of an RoT and of
the functions of
specific RoTs.  In ETSI, TCG, and SAE specs that I'm editing, we have had
to address
the functions and definitions of RoTs by workgroup consensus decision.

Dave Thaler pointed out yesterday that SUIT had managed to avoid using RoT
terms.
I seconded that, for RATS Architecture, to avoid months of rathole
discussions in RATS
(who are really the tail and not the dog in the sphere of trusted computing
systems).

Cheers,
- Ira

On Wed, Dec 15, 2021 at 10:39 AM Hannes Tschofenig <
[email-masked]> wrote:

> Independently of the architecture draft I am still curious about the RoT
> definition because it is a topic that frequently comes up.
>
>
>
> Ciao
>
> Hannes
>
>
>
> *From:* RATS <[email-masked]> *On Behalf Of * Ira McDonald
> *Sent:* Wednesday, December 15, 2021 4:15 PM
> *To:* Hannes Tschofenig <[email-masked]>; Ira McDonald <
> [email-masked]>
> *Cc:* Michael Richardson <[email-masked]>; Jeremy O'Donoghue <
> [email-masked]>; Laurence Lundblade <[email-masked]>;
> rats <[email-masked]>
> *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]
> <[email-masked]> (permanent) PO Box 221  Grand Marais, MI 49839
> 906-494-2434*
>
>
>
>
>
> On Wed, Dec 15, 2021 at 9:00 AM Hannes Tschofenig <
> [email-masked]> wrote:
>
> Hi Jeremy,
>
>
>
> Thanks for your input.
>
>
>
> *From:* RATS <[email-masked]> *On Behalf Of *Jeremy O'Donoghue

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 15 Dec 2021 18:49:59 +0100

*distracted*

But commenting anyways... *All but one* strategic mentioning of RoT that 
allows to align a bouquet of references and then add content to the 
seccon section about that.

The current decision was made about the relatively arbitrary use of RoT 
in the document. The proposed solution to be fleshed out was to fall 
back to Attesting Environment in most places where RoT is used right now 
and deal with the outliners on a case to case basis - and then tie the 
term RoT *once* to that context in the body of the text.

Generating a proposal is assigned to appropriate editors. Please give 
them a bit of time in this time of the year before there is a stable 
proposal. Progress can be tracked at 
https://github.com/ietf-rats-wg/architecture as soon as there is a first 
proposal.

Viele Grüße,

Henk

On 15.12.21 16:15, Ira McDonald wrote:
> /Ira McDonald (Musician / Software Architect)/
> /Chair - SAE Trust Anchors and Authentication TF
> /
> /Co-Chair - TCG Trusted Mobility Solutions WG/
> /Co-Chair - TCG Metadata Access Protocol SG
> /
> /Chair - Linux Foundation Open Printing WG
> <http://sites.google.com/site/highnorthinc>
> (permanent) PO Box 221  Grand Marais, MI 49839  906-494-2434/
> 
> 
> On Wed, Dec 15, 2021 at 9:00 AM Hannes Tschofenig 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Jeremy, ____
> 
>     __ __
> 
>     Thanks for your input. ____
> 
>     __ __
> 
>     It would be good to re-use definitions, whenever possible.____
> 
>     __ __
> 
>     The definition you provide below is good*. ____
> 
>     __ __
> 
>     When I tried to find it in the referenced GP document I was
>     unsuccessful. So, is the quoted definition from this document, from
>     some other document or your own version?____
> 
>     __ __
> 
>     Ciao____
> 
>     Hannes____
> 
>     __ __
> 
>     PS: For me firmware = software. ____
> 
>     __ __
> 
>     __ __
> 
>     *From:* RATS <[email-masked] <mailto:[email-masked]>>
>     *On Behalf Of * Jeremy O'Donoghue
>     *To:* Michael Richardson <[email-masked]
>     <mailto:[email-masked]>>; Laurence Lundblade
>     <[email-masked] <mailto:[email-masked]>>; Ira McDonald
>     <[email-masked] <mailto:[email-masked]>>; rats
>     <[email-masked] <mailto:[email-masked]>>
>     draft-ietf-rats-architecture-13)____
> 
>     __ __
> 
>     If anyone is interested, there is a pretty extensive set of
>     definitions and requirements for a Root of Trust created by
>     GlobalPlatform at
>     As a requirements document this one is not behind a click-through
>     agreement.____
> 
>     __ __
> 
>     It is quite a long document, and although some material could be
>     omitted (especially in RATS context) it does try to cover some of
>     the complexities of Roots of Trust – it came about as a consequence
>     of similar internal discussions on the RoT concept to the one in
>     this WG.____
> 
>     __ __
> 
>     The definitions are inclusive of NIST SP800-164 guidelines and the
>     TCG Glossary.____
> 
>     __ __
> 
>     Reduced to its essence, the RoT is that part of a system that has to
>     be implicitly trusted because there is no meaningful way to measure
>     it as it is immutable. As Laurence mentions, it almost always a
>     combination of hardware and immutable code.____
> 
>     __ __
> 
>     contain key material and perform cryptographic operations.____
> 
>     __ __
> 
>     definition of a Root of Trust that is both universally applicable
>     and useful, but at the risk of inviting Nemesis to visit, I’ll have
>     a go anyway:____
> 
>     __ __
> 
>     “A Root of Trust is a combination of hardware, firmware, software
>     and keys that are implicitly trusted to provide foundational
>     security services to other subsystems. If it is compromised, the
>     entire device is also compromised. A Root of Trust containing a
>     shielded private or secret key can provide services to an Attesting
>     Environment – this service is called the Root of Trust for
>     Attestation.____
> 
>     __ __
> 
>     device, Roots of Trust are often designed to protect against
>     specific threats. There is extensive literature covering RoT
>     security including [NIST SP 800-164], [TCG Glossary],
>     [GlobalPlatform RoT Requirements].“____
> 
>     __ __
> 
>     Best regards____
> 
>     Jeremy____
> 
>     __ __
> 
>     On 13/12/2021, 21:30, "RATS" <[email-masked]
>     <mailto:[email-masked]>> wrote:____
> 
>     __ __
> 
>     WARNING: This email originated from outside of Qualcomm. Please be
>     wary of any links or attachments, and do not enable macros.
> 
>          > if we use the term, it has to be “root of trust for
>     attestation”, never
>          > “root of trust”.
> 
>     Michael Richardson <[email-masked]
>     <mailto:[email-masked]>>   . o O ( IPv6 IøT consulting )
>     ____
>     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.
> 
>