Handling device mode in RP

[dkumar-nv]

A device may support multiple modes such as Standard, CC-bounce-buffer, CC-TDISP etc. and may be only in one mode at a given point in time. Each of the device modes may have its own set of corresponding reference values causing ear.status and ear.trustworthiness-vector to possibly be reported as "good" in each of the modes. Therefore, if a Relying Party (RP) only ever looked at ear.status and ear.trustworthiness-vector, it may make an erroneous decision to proceed when device is not in the intended mode. Does it make sense to standardize a mode or state claim to be added to EAR-appraisal? If not, is using a non-standardized claim name (mode or state) under submods (which has a non-standardized name) the recommended approach?

[thomas-fossati]

Hi @dkumar-nv and welcome!

The core tenet of the AR4SI information model is to abstract the attester as much as possible to the RP in order to stabilise and simplify the RP's policies.

EAR, which is based on AR4SI, aims to achieve this noble goal while also acknowledging that reality may be slightly more complicated 😄

So, assuming your RPs are somewhat coupled to (at least some parts) of the attester (e.g., one or more specific devices attached to the “lead” attester) and that the appraisal policy for attestation results needs to make decisions based on device-specific claims, I suggest adding your device-specific claims to the $$ear-appraisal-extension socket.
(For a concrete example of how to do that, see the TEEP extensions described in §4.4 of the draft).

You may also wish to look at the work we are doing at https://datatracker.ietf.org/doc/draft-poirier-rats-eat-da/ to see if anything can be reused from (or needs to be added to) the defined claims-set.
In fact, another option would be to use the $$ear-appraisal-extension to just republish the EAT DA claims-set as-is for the appraised device.

[dkumar-nv]

Thanks @thomas-fossati
I understand that I can extend. However, this is a case where I am expecting a lot of devices to need the same concept and hence desire for standardization. Let me present the case in a slight different manner before I go implement custom extension: EAR/AR4SI tell the RP whether the device is good. But RP needs to know whether the device is good for purpose X. The same device may be good for multiple purposes. For example: A device supporting confidential compute (CC) typically needs to be configured before it is considered good for CC (the "purpose"). But that does not mean that device is good for nothing until its set up for CC i.e. EAR/AR4SI are applicable even when device has not yet been configured for CC (Standard mode).

[thomas-fossati]

Another way to look at this is to consider the other dimension of extensibility offered by AR4SI: the ability to use the negative codepoint space to describe deployment- or implementation-specific tiered semantics.

For example, if you want to inform your RPs that a device is ”good for purpose X” using the trustworthiness vector, you could select a codepoint in the range [-2, -32].

[dhawalfs1]

@thomas-fossati ,
The purpose is a global characteristic. So, I am not following usage of AR4SI in this context. Are you suggesting creation of a new trust vector called Purpose?