Support explicitly partial appraisals

[thomas-fossati]

Looking only at the ear.status claim, there is no way to tell an RP (or a downstream verifier) that the appraisal conducted by the verifier is incomplete. For example, if some relevant reference values have not been provisioned.

This is the case for CCA realms when no RIM/REMs/RPV reference values are provided, but the identity of the realm world can still be appraised by checking the RAK signature over the realm token and the RAK attestation made by the platform. In such case, the realm-specific appraisal submod will be populated with some but not all of the TV claims, and the ear.status computed accordingly, maybe with an "affirming" (but partial!) score, if the RAK checks out.

In that scenario, it'd be helpful to a relying party that does not inspect the TV to know that the appraisal is incomplete. The risk otherwise is it'd be tricked into thinking that everything is good when only something is good.

[yogeshbdeshpande]

ear.status, which represent the overall status of Appraisal for an attester is intended to accomplish the same objective.

As per EAR specification Section 3.2.2 Trust Tiers:
The trust tier type represents one of the equivalency classes in which the $ar4si-trustworthiness-claim space is partitioned. See Section 2.3.2 of [I-D.ietf-rats-ar4si] for the details.

Reading Section 2.3.2 Enumerated Encoding of [I-D.ietf-rats-ar4si]:

`Value 1: The Evidence received contains unknown elements which the Verifier is unable to evaluate.

An example might be that the wrong type of Evidence has been delivered. Another case is that of Evidence coming from a composite Attester:`

a Verifier may understand only part of it and leave as "unknown" the Trustworthiness claims related to features it can't appraise.

What we have not encoded and grasped fully is the semantics for Value 1:

We should say, For SubMod: Realm Appraisal, we should state that PartAppraisal conducted, with each Vector Element
been indicated accordingly..

Also one thing to note is that $ar4si.trust-tier inside the EAR specification is capable of
extensibility within its own right, so we should revisit the code space and recommend correctly,
instead of polluting by inserting such indicators outside as suggested to avoid duplication and confusion!

[thomas-fossati]

I don't really get what you are proposing. We probably need a chat.

Noting that we could just get rid of ear.status - which is a conceptually wrong object in AR4SI land - and be done with the problem described in this issue.

[yogeshbdeshpande]

I am ok, to get rid of tight coupling of status to 2.3.2. Enumeration Encoding which is really for each trust vector like instance identity etc.

If we get rid of status all together, means RP needs to inspect each of the Trust Vectors and make its own judgement, without any overall feedback from the Verifier, which is painful!

[yogeshbdeshpande]

I don't really get what you are proposing. We probably need a chat.

What I meant was : Have we explored:

Option a) Possibly using status value : 1 to indicate the same ??

Option b) Affirming has range 2 to 31, could we say for this Attester, 30 ==> "Affirming with Partial Evaluation"

[thomas-fossati]

I am ok, to get rid of tight coupling of status to 2.3.2. Enumeration Encoding which is really for each trust vector like instance identity etc.

That's not what I was proposing.

If we get rid of status all together, means RP needs to inspect each of the Trust Vectors and make its own judgement, without any overall feedback from the Verifier, which is painful!

That's AR4SI - which hopefully is not particularly painful (otherwise there would be little sense to use it in the first place.)

The conceptual problem with ear.status is it flattens 8 dimensions into 1.
And in the process obviously lose vital information.
That's the main reason to avoid basing any decision on its value, and an excellent reason to get rid of it.

[thomas-fossati]

Option a) Possibly using status value : 1 to indicate the same ??

What "same"?
Where is value "1" taken from?

Option b) Affirming has range 2 to 31, could we say for this Attester, 30 ==> "Affirming with Partial Evaluation"

affirming is a string:

ar4si.trust-tier-none = "none"
ar4si.trust-tier-affirming = "affirming"
ar4si.trust-tier-warning = "warning"
ar4si.trust-tier-contraindicated = "contraindicated"

[yogeshbdeshpande]

Value 1: is from https://ietf-rats-wg.github.io/draft-ietf-rats-ar4si/draft-ietf-rats-ar4si.html#name-enumeration-encoding

[yogeshbdeshpande]

Value 1: The Evidence received contains unknown elements which the Verifier is unable to evaluate. An example might be that the wrong type of Evidence has been delivered. Another case is that of Evidence coming from a composite Attester: a Verifier may understand only part of it and leave as "unknown" the Trustworthiness claims related to features it can't appraise

[thomas-fossati]

Not sure what the proposal is. If you look at the outer context of that sentence you'll notice that 1 is part of the None bucket. So it's currently mapped to ar4si.trust-tier-none = "none".