Subject: [Rats] Dynamic Systems in IETF RATS (was Re: 3 Use cases)

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Oct 2019 14:32:56 +0200

Oliver, Ian (Nokia - FI/Espoo) <[email-masked]> wrote:
    > Dynamic Systems

    > All current integrity mechanism assume a certain degree of fixed
    > properties, eg: TPM's CRTM/SRTM, and known configurations. A case
    > exists where a set of, say, IoT devices each with integrity
    > measurements are attested by some Edge node. The Edge node may combine
    > the IoT device measurements into a single measurement (eg: Merkel
    > Tree). If the configuration of IoT device changes, particuarly in
    > relation to availability of device, then this combined measurement will
    > change. This changed measurement however may be a valid configuration.

    > For example, in a medical case, the set of measurement devices may be
    > rapidly changing due to necessity of network provisioning, device
    > availabiltiy etc, but the permutations of devices may still be valid.

So you are describing a system where there is an assembly of devices.
I have a few questions and want to offer a two categories:
1) the network's view of the devices is transparent.  That is, each device
   in the assembly is reachable by the network either through L2-bridging,
   L3-routing (facilited maybe by DHCPv6-PD), or because all devices are
   just connected to the same "wifi" or LLN.

2) the network's view of the devices is opaque: the network only sees some
   gateway device and perhaps all interaction is via an application layer gateway.

Case (2) seems that the layer of indirection means the assembly
gateway/controller should probably be a relying party for the devices,
and should communicate it's configuration to an attester in order to validate
it's configuration.  The network would see the resulting attestion of the
aggregate.  I don't see anything surprising or new here. Just a recursive
application of RATS.

Case (1) is therefore the more interesting case, I think.
I imagine, yes, some health care situation where the assembly is the hospital
room, and the devices are the individual monitors.  The room needs to attest
to it's ability to deal/collect the correct/complete set of information, and
one can see that the failure (or the deplection) of some device leads to the
room being "unviable", and requiring attention.

I also was thinking about an assembly that is a passenger-rail coach arranged
in a set.  Each has a series of safety sensors that the engine must
interrogate directly. But, it's not necessary for every sensor in every coach
to be functional, as there is some redundancy, not just within each vehicle,
but also because there are multiple vehicles.

===

In thinking about this, I also thought of some sf movie (Expanse, Star Trek,
Star Wars), where sensors and sub-systems get blown up/overloaded, and need
to be patched.  Chewbacca is waiting for the attestation system to agree that
all parts are installed correctly, and Han and R2D2 are effecting repairs... A
very dynamical system; but you don't get to lightspeed until is sure it won't
just kill everyone onboard.  ...
Scotty: "Captain! I canna give you warp speed until the wee attestations settle."

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Oct 2019 14:33:34 +0200

{sorry for the time-warp email, responding to you was important to me}

Oliver, Ian (Nokia - FI/Espoo) <[email-masked]> wrote:
    > Supply Chain Attestation

    > A device is shipped from an OEM via some delivery mechanism and is
    > received by a customer. The customer requires assurance that the device
    > has not been tampered with. This differs from the usual attestation
    > scenarios between a device/element and attestation server/verifier in
    > that this requires knowledge of the partial or full configuration of
    > the device being shipped and configured before introduction into the
    > customer's environment.

    > This use case then requires interaction between two attestation points
    > to ensure that the integrity of the device has not changed with regards
    > to a) the device, b) the original [possibly partial] configuration, c)
    > the device manufacturer's measurements and d) the receiver - customer's
    > - measurements..

There are quite a number of entities that are looking for the attestation
that involves not the device, but the configuration as well.

I think that this fits into 5.1: Device Capabilities/Firmware Attestion.
I think that the need for sensitivity to configuration is generally something
that the TCG RIV work:
     The TCG RIV Reference Document addresses the problem of knowing if a networking device
     should be part of a network, if it belongs to the operator, and if it is RUNNING
     APPROPRIATE SOFTWARE.

Guy has posted their document as draft-fedorkow-rats-network-device-attestation, which 
makes it much more accessible if you aren't a TCG member (I'm not).

You allude (but are perhaps not explicit enough) in your second paragraph
that there is some interaction between different attesters to generate the
required set of claims needed.  Do you imagine that this is done via multiple
signatures on a claim set, or some kind of nested claim structure, or perhaps
use of passport claim for one part, followed by a background-check style
process for the second. (Dave Thaler's slides included that option too)

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Oct 2019 13:39:39 +0200

Oliver, Ian (Nokia - FI/Espoo) <[email-masked]> wrote:
    > Data Attestation

    > A piece of data received from a trusted element may itself contain
    > information about the configuration of that device when that data was
    > received. This might be a single measurement or a combination of
    > measurements over time bounded by a session or transacition.

    > In this use case we continue the chain-of-trust up from the device
    > firmware/operating environment to the data. This enables that once a
    > data packet is received, it's integrity can be checked (cf: JWT) and
    > this information also be traced to the device that produced that
    > data. The data and device then can be attested together.

This use case seems similar to the the geographic cases, but also to the FIDO
use cases, where one needs to know the state of the device that took the
biometric reading in order to know if the biometric is useful.

Can I ask you to fill in my template:

   Use case name:  
   Who will use it:  
   Attesting Party:  
   Relying Party:  
   Attestation type:  Passport or Background Check
   Claims used:  
   Description:

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 7 Oct 2019 12:08:09 -0400

On Mon, Oct 7, 2019 at 8:32 AM Michael Richardson <[email-masked]> wrote:

> Guy has posted their document as
> draft-fedorkow-rats-network-device-attestation, which

I would guess a nested claim structure so that you could 'wrap'  a claim
set and signature of code that is relied upon.  Having a standard format
and evaluation method (TEEP) for this use case is then very important
across vendors int he supply chain.  Your other suggestion could work as
well, but the consistent ablity to validate will be very important.  I'd
like to follow the discussion and thoughts of others.

Best regards,
Kathleen

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

-- 

Best regards,
Kathleen

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 7 Oct 2019 18:33:52 +0000

See inline [nms]

On 10/7/19, 9:09 AM, "RATS on behalf of Kathleen Moriarty" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

On Mon, Oct 7, 2019 at 8:32 AM Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

I would guess a nested claim structure so that you could 'wrap'  a claim set and signature of code that is relied upon.
[nms] In a decomposition of a device there can be components that are ‘attested’ and components that are ‘attesting’. The architecture expects that for every attested component there SHOULD be at least one attesting component. Nesting and decomposition logic needs to preserve these trust relationships. The expectation of a Verifier is the/a correct decomposition is known and will be the basis for assessing Evidence where Evidence nesting structure should provide proof that the expected trust relationships are intact. Otherwise, that could be a condition for Verifier to fail the attestation assessment.

I think there are 3 classes of nesting logic:

  1.  Subcomponent(s) that are Attested by a parent component (single layer attestation of a multi-layered decomposition)
  2.  Subcomponent(s) that are Attested by a parent component  and Attesting other subcomponents (layered attestations)
  3.  Subcomponent(s) that are Attested by more than one parent component (e.g. countersigned or co-signed)

Having a standard format and evaluation method (TEEP) for this use case is then very important across vendors int he supply chain.
[nms] A TEE can be both an Attesting and an Attested environment. The same TEE can’t be both unto itself however. A manufacturer issued device certificate, attribute certificate or manifest can be used to capture claims about the attested (TEE) environment that has no other attesting environment. (FYI - Much of the industry would call this a root of trust). The mfg issued cert / manifest is considered by the architecture to be “Endorsement” values since there isn’t an Attesting environment (on the platform) that produces Evidence. The architecture draws a line between devices as principal entities and manufacturers as principal entities. The former relating to Attestation Evidence and the latter to Asserters and Endorsements.

Your other suggestion could work as well, but the consistent ablity to validate will be very important.  I'd like to follow the discussion and thoughts of others.

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

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

--

Best regards,
Kathleen

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 7 Oct 2019 20:45:12 +0200

That brings up an interesting topic.

If you want to nest objects/maps in EAT, do you have to define a 
separate EAT for each layer or can you define nested (potentially 
multiple) sub-structures as a single EAT flavor/specification? Like a 
"required nesting that is predefined".

I'd assume so, but I think that is not spelled out explicitly - as an 
EAT can only include nested EATs?

Viele Grüße,

Henk

On 07.10.19 18:08, Kathleen Moriarty wrote:
>     Oliver, Ian (Nokia - FI/Espoo) <[email-masked]
>     <mailto:[email-masked]>> wrote:
>          > Supply Chain Attestation
> 
>          > A device is shipped from an OEM via some delivery mechanism
>     and is
>          > received by a customer. The customer requires assurance that
>     the device
>          > has not been tampered with. This differs from the usual
>     attestation
>          > scenarios between a device/element and attestation
>     server/verifier in
>          > that this requires knowledge of the partial or full
>     configuration of
>          > the device being shipped and configured before introduction
>     into the
>          > customer's environment.
> 
>          > This use case then requires interaction between two
>     attestation points
>          > to ensure that the integrity of the device has not changed
>     with regards
>          > to a) the device, b) the original [possibly partial]
>     configuration, c)
>          > the device manufacturer's measurements and d) the receiver -
>     customer's
>          > - measurements..
> 
>     ] [email-masked] <mailto:[email-masked]>
>     http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> 
> 
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 7 Oct 2019 18:57:42 -0700

EAT has three mechanisms that can apply here:

Nested EATs
One signed EAT is embedded in another signed EAT. The signature of the top-level one is across full COSE structure of the nested EAT. This is important to bind the nested EAT (perhaps EATs) with the top-level one and all it claims.

submods
These are subordinate maps of claims that are not separately signed. The relation to the attester is explicitly labeled. For example an EAT may span 4 chips each of which has its own OEM and HW Version. There would probably be 3 submods plus the chip doing the attester. Each would have an OEM claim and a HW Version claim.

Custom Claims
There’s no preclusion to some complex claim with many levels of nesting of maps and arrays.  So, no it is not true that an EAT can only include a nested EAT.

As Ned says, the Verifier is likely to expect a lot of this and fail if not as required. The profile it adheres to might be liberal about lots of extra unknown submods, nested eats and custom claims or not liberal at all.

I after a good structure for all of these that is flexible and useful. Would be interested in folks trying to use these to construct EATs for use cases as examples.

LL

> On Oct 7, 2019, at 11:45 AM, Henk Birkholz <[email-masked]> wrote:
> 
> If you want to nest objects/maps in EAT, do you have to define a separate EAT for each layer or can you define nested (potentially multiple) sub-structures as a single EAT flavor/specification? Like a "required nesting that is predefined".
> 
> I'd assume so, but I think that is not spelled out explicitly - as an EAT can only include nested EATs?
> 
> Viele Grüße,
> 
> Henk
> 
>> On Mon, Oct 7, 2019 at 8:32 AM Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
>> I would guess a nested claim structure so that you could 'wrap'  a claim set and signature of code that is relied upon.  Having a standard format and evaluation method (TEEP) for this use case is then very important across vendors int he supply chain.  Your other suggestion could work as well, but the consistent ablity to validate will be very important.  I'd like to follow the discussion and thoughts of others.
>> Best regards,
>> Kathleen
>>    --     ]               Never tell me the odds!                 | ipv6 mesh
>>    networks [

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Oct 2019 08:52:09 +0200

> If you want to nest objects/maps in EAT, do you have to define a separate EAT
    > for each layer or can you define nested (potentially multiple) sub-structures
    > as a single EAT flavor/specification? Like a "required nesting that is
    > predefined".

And there are two ways to do this.

A: (eat (eat (eat (eat X))))
B: (eat (eat) (eat) (eat) (eat))

And they aren't mutually exclusive, either:
C: (eat (eat (eat) (eat (eat))) (eat))

(A) above is the where there are multiple layers of Supply Chain, and each
    is made up ofaggregated things.
(B) is where one takes a few different assemblies together.

For instance:
  Door assembly system + 6 chair-systems => train compartment
  4x train compartments + 40 open-seats + bathroom + 4 outer-door systems  => wagon 11
  wagons 1->11 => ICE 802

I'm not in favour of arbitrary ways to do things as I think it will be too
difficult for relying parties to understand.  I look at the incredible
difficulty that XPATH interpretation of XML and HTML documents presents.

On the other hand, I'd want the system to be sufficiently maleable to not
instantly break because a sub-assembly changed sub-sub-suppliers.

I don't have a good answer here.

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

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 8 Oct 2019 09:37:43 +0200

Hi Laurence,

thanks for the clarification! If you nest a pre-defined submod in an 
EAT, I assume the key is defined in the same specification.

If I nest an EAT in an EAT (Michael gave two good examples that can be 
combined), where do I define the key for that? In the nested EAT 
specification or in the nesting EAT specification? I'd assume in the 
nested EAT specification?

A special (or actualy the currently most common) case would be the 
current base EAT specification. Should that come with its own 
"self-nesting" key then?

Viele Grüße,

Henk

On 08.10.19 03:57, Laurence Lundblade wrote:
>     _Nested EATs_
>     One signed EAT is embedded in another signed EAT. The signature of
>     the top-level one is across full COSE structure of the nested EAT.
>     This is important to bind the nested EAT (perhaps EATs) with the
>     top-level one and all it claims.
> 
>     _submods_
>     These are subordinate maps of claims that are not separately signed.
>     The relation to the attester is explicitly labeled. For example an
>     EAT may span 4 chips each of which has its own OEM and HW Version.
>     There would probably be 3 submods plus the chip doing the attester.
>     Each would have an OEM claim and a HW Version claim.
> 
>     _Custom Claims_
>     There’s no preclusion to some complex claim with many levels of
>     nesting of maps and arrays.  So, no it is not true that an EAT can
>     only include a nested EAT.
> 
> 
> As Ned says, the Verifier is likely to expect a lot of this and fail if 
> not as required. The profile it adheres to might be liberal about lots 
> of extra unknown submods, nested eats and custom claims or not liberal 
> at all.
> 
> I after a good structure for all of these that is flexible and useful. 
> Would be interested in folks trying to use these to construct EATs for 
> use cases as examples.
> 
> LL
> 
> 
>> On Oct 7, 2019, at 11:45 AM, Henk Birkholz 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>> On Mon, Oct 7, 2019 at 8:32 AM Michael Richardson <[email-masked] 
>>> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>> <mailto:[email-masked]>
>>> I would guess a nested claim structure so that you could 'wrap'  a 
>>> claim set and signature of code that is relied upon.  Having a 
>>> standard format and evaluation method (TEEP) for this use case is 
>>> then very important across vendors int he supply chain.  Your other 
>>> suggestion could work as well, but the consistent ablity to validate 
>>> will be very important.  I'd like to follow the discussion and 
>>> thoughts of others.
>>> Best regards,
>>> Kathleen
>>>    ] [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 8 Oct 2019 09:56:40 +0200

p.s. I am aware of the submod_name claim as a value inside a submod EAT 
flavor to identify it when you are already parsing the map. I also 
assume that the string "submods" is probably going to be replaced and 
being registered as a key for the array of submod claim sets at some 
point. What I am trying to ask is: is it intended and if so, how, to 
provide for simplified parsing of the root map by associating specific 
keys other than the to be defined submods key in order to identify a 
nested EAT flavor before parsing a sequence of maps?

To stay concise and easy to parse, I'd rather like to define a key for 
my EAT flavor instead of putting it in an array of other maps, I think.

Viele Grüße,

Henk

On 08.10.19 09:37, Henk Birkholz wrote:
>> As Ned says, the Verifier is likely to expect a lot of this and fail 
>> if not as required. The profile it adheres to might be liberal about 
>> lots of extra unknown submods, nested eats and custom claims or not 
>> liberal at all.
>>
>>>> <mailto:[email-masked]>

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 8 Oct 2019 07:04:48 -0400

On Mon, Oct 7, 2019 at 2:33 PM Smith, Ned <[email-masked]> wrote:

> See inline [nms]
>
>
>
> On 10/7/19, 9:09 AM, "RATS on behalf of Kathleen Moriarty" <
> [email-masked] on behalf of [email-masked]>
> wrote:
>
>
>
>
>
>
>
> set and signature of code that is relied upon.
>
> [nms] In a decomposition of a device there can be components that are
> ‘attested’ and components that are ‘attesting’. The architecture expects
> that for every attested component there SHOULD be at least one attesting
> component. Nesting and decomposition logic needs to preserve these trust
> relationships. The expectation of a Verifier is the/a correct decomposition
> is known and will be the basis for assessing Evidence where Evidence
> nesting structure should provide proof that the expected trust
> relationships are intact. Otherwise, that could be a condition for Verifier
> to fail the attestation assessment.
>
>
>
>    1. Subcomponent(s) that are Attested by a parent component (single
>    layer attestation of a multi-layered decomposition)
>    2. Subcomponent(s) that are Attested by a parent component  and
>    Attesting other subcomponents (layered attestations)
If you are just talking about the TEE case and not the manufacturer signing
use case, then the signatures do build from the base.  But for what I would
call supply chain, the manufacturer or software developing organization is
the one to provide the signature and they know what software, modules. or
components they rely upon.  Therefore, the 3 classes are not painting the
right picture for what I would call the supply chain use case.  That's why
your nesting module looks different than what I stated, where I was talking
about what you are calling "endorsements'.

>
>    1.
>
>
>
> Having a standard format and evaluation method (TEEP) for this use case is
> then very important across vendors int he supply chain.
>
> [nms] A TEE can be both an Attesting and an Attested environment. The same
> TEE can’t be both unto itself however. A manufacturer issued device
>

I was referring to the protocol from TEEP, OrTPv2, not the TEE.  There are
a few use cases and the parties shift for the use cases, I believe there
are some use cases that do not require a TEE.

> certificate, attribute certificate or manifest can be used to capture
> claims about the attested (TEE) environment that has no other attesting
> environment. (FYI - Much of the industry would call this a root of trust).
> The mfg issued cert / manifest is considered by the architecture to be
> “Endorsement” values since there isn’t an Attesting environment (on the
> platform) that produces Evidence. The architecture draws a line between
> devices as principal entities and manufacturers as principal entities. The
> former relating to Attestation Evidence and the latter to Asserters and
> Endorsements.
>

Best regards,
Kathleen

>
>
> Your other suggestion could work as well, but the consistent ablity to
> validate will be very important.  I'd like to follow the discussion and
> thoughts of others.
>
>
>
> Best regards,
>
> Kathleen
>
> --

-- 

Best regards,
Kathleen

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 8 Oct 2019 07:27:50 -0700

submods is an array of maps, each map containing the claims for that submod. Each of these maps also has a text string that is the submod_name.

The submods array itself has a key defined by the standard.

So you can do 
   (eat (submods (submod) (submod) (submod) )) where submod looks a lot like an eat except it is not individually signed and has the submod_name claim

You can also have all the combos:

   (eat (eat) (submods (submod) (submod)))
  
   (eat (eat) (submods (submod (eat) (eat) (submod)) (submod (submods (submod) (submod (eat))))

As the document stands now there is one key for a nested eat. It is different than submods. To do (eat (eat)(eat)(eat)) all the nested eats would have the same key. That is probably not the best and it should go to the array like submods.

We do need better examples for all this.

Probably the main eat doc should allow all of this, but profiles should narrow it for particular use cases.

I see submods as used when the two entities are physically connected together by wires that can’t be easily attacked. For example they are on the same PCB on subsystems in a SoC. Also the submod is likely to be dumb and incapable of making an eat.  Putting the signing key to a device in a secure way is hard so lack of a key is probably why it can make an eat.

LL

> On Oct 8, 2019, at 12:37 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Laurence,
> 
> thanks for the clarification! If you nest a pre-defined submod in an EAT, I assume the key is defined in the same specification.
> 
> If I nest an EAT in an EAT (Michael gave two good examples that can be combined), where do I define the key for that? In the nested EAT specification or in the nesting EAT specification? I'd assume in the nested EAT specification?
> 
> A special (or actualy the currently most common) case would be the current base EAT specification. Should that come with its own "self-nesting" key then?
> 
> Viele Grüße,
> 
> Henk
> 
>>> On Oct 7, 2019, at 11:45 AM, Henk Birkholz <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>> On Mon, Oct 7, 2019 at 8:32 AM Michael Richardson <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>    Oliver, Ian (Nokia - FI/Espoo) <[email-masked] <mailto:[email-masked]>

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 8 Oct 2019 17:17:13 +0000

On 10/8/19, 4:05 AM, "Kathleen Moriarty" <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Oct 7, 2019 at 2:33 PM Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:
See inline [nms]

a.       Subcomponent(s) that are Attested by a parent component (single layer attestation of a multi-layered decomposition)

b.      Subcomponent(s) that are Attested by a parent component  and Attesting other subcomponents (layered attestations)

c.       Subcomponent(s) that are Attested by more than one parent component (e.g. countersigned or co-signed)

If you are just talking about the TEE case and not the manufacturer signing use case, then the signatures do build from the base.  But for what I would call supply chain, the manufacturer or software developing organization is the one to provide the signature and they know what software, modules. or components they rely upon.  Therefore, the 3 classes are not painting the right picture for what I would call the supply chain use case.  That's why your nesting module looks different than what I stated, where I was talking about what you are calling "endorsements'.

I’m referring to ways to decompose a device and attest (create evidence). TEEP architecture anticipates a device could consist of multiple attesting environments. DICE also anticipates multiple attesting environments per device.

The use cases for how a supply chain works might be under represented based on the groups charter. The charter expects architecture will be informed by use cases and that architecture is not limited to interactions involving Attester<---->Verifier<---->RelyingParty. Verifiers expect to receive reference values that can be compared to Evidence. So, clearly Evidence and Endorsements have to be related. However, vendors may only generate reference values in a piecemeal fashion. Walking the device to collect attestation evidence seems to be something the Attester would normally do.

a.

Having a standard format and evaluation method (TEEP) for this use case is then very important across vendors int he supply chain.
[nms] A TEE can be both an Attesting and an Attested environment. The same TEE can’t be both unto itself however. A manufacturer issued device

I was referring to the protocol from TEEP, OrTPv2, not the TEE.  There are a few use cases and the parties shift for the use cases, I believe there are some use cases that do not require a TEE.

certificate, attribute certificate or manifest can be used to capture claims about the attested (TEE) environment that has no other attesting environment. (FYI - Much of the industry would call this a root of trust). The mfg issued cert / manifest is considered by the architecture to be “Endorsement” values since there isn’t an Attesting environment (on the platform) that produces Evidence. The architecture draws a line between devices as principal entities and manufacturers as principal entities. The former relating to Attestation Evidence and the latter to Asserters and Endorsements.

Best regards,
Kathleen

Best regards,
Kathleen

--

Best regards,
Kathleen

--

Best regards,
Kathleen