Subject: [Rats] Second attempt at early allocation of CWT Labels (PR #152)

From: Yogesh Deshpande <[email-masked]>
Date: Thu, 17 Feb 2022 19:27:03 +0000

Hi Laurence,

I just notice you merged the PR: https://github.com/ietf-rats-wg/eat/pull/152

There are still few unresolved comments on the PR.

Was curious to know is there a plan to address these open issue via a sperate PR ?

Regards,
Yogesh
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: Yogesh Deshpande <[email-masked]>
Date: Thu, 17 Feb 2022 19:28:14 +0000

Adding Laurence in the To: list and Cc: rats organization

From: Yogesh Deshpande
Sent: 17 February 2022 19:27
To: [email-masked]
Subject: Second attempt at early allocation of CWT Labels (PR #152)

Hi Laurence,

Regards,
Yogesh

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 17 Feb 2022 11:37:04 -0800

Hi Yogesh,

I think you are referring to Henk’s comments? Those comments are very large in scope, much larger than the humble PR for CWT labels. It isn’t suitable to block the IANA Claim Key assignment work for the existential questions Henk has posed. We need to get out a new draft.

My request is that Henk file those as several independent issues against EAT as a whole.  

LL

> On Feb 17, 2022, at 11:27 AM, Yogesh Deshpande <[email-masked]> wrote:
> 
> Hi Laurence,
>  
> I just notice you merged the PR: https://github.com/ietf-rats-wg/eat/pull/152 <https://github.com/ietf-rats-wg/eat/pull/152>
>  
> 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. _______________________________________________
> RATS mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: Yogesh Deshpande <[email-masked]>
Date: Thu, 17 Feb 2022 19:50:27 +0000

Hello Laurence,

Thanks for the clarification. Understood it fully now!

Regards,
Yogesh

From: Laurence Lundblade <[email-masked]>
Sent: Thursday, February 17, 2022 7:37 PM
To: Yogesh Deshpande <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] Second attempt at early allocation of CWT Labels (PR #152)

Hi Yogesh,

LL

On Feb 17, 2022, at 11:27 AM, Yogesh Deshpande <[email-masked]<mailto:[email-masked]>> wrote:

Hi Laurence,

Regards,
Yogesh
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. _______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 17 Feb 2022 21:36:46 +0100

Hi Laurence,

that is an reasonable request, but I was taking into account Mike's 
comment that stated:

> Please remove any claims for which the definitions are not definitely immutable at this point from the pre-registration request.

And that is why I raised the issues. What you phrase as "existential 
questions" I'd phrase as reasonable arguments against the indifferent 
applications of Claims defined by EAT to the RATS Conceptual Messages 
that are Evidence and Attestation Results.

Yes, we need to get out a new draft. I am okay with a draft that makes 
that distinctions. Obviously, the recent development made me very 
cautious about mixing these definitions wrt the CWT registry in general 
and EAT, specifically.

Mixing both Evidence Claims and Attestation Claims into the same bucket 
seems to be not feasible to me.

Viele Grüße,

Henk

On 17.02.22 20:37, Laurence Lundblade wrote:
> Hi Yogesh,
> 
> I think you are referring to Henk’s comments? Those comments are very 
> large in scope, much larger than the humble PR for CWT labels. It isn’t 
> suitable to block the IANA Claim Key assignment work for the existential 
> questions Henk has posed. We need to get out a new draft.
> 
>> On Feb 17, 2022, at 11:27 AM, Yogesh Deshpande 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi Laurence,
>> I just notice you merged the 
>> PR:https://github.com/ietf-rats-wg/eat/pull/152 
>> <https://github.com/ietf-rats-wg/eat/pull/152>
>> 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. 
>> _______________________________________________
>> RATS mailing list
>> <https://www.ietf.org/mailman/listinfo/rats>
> 
> 
> _______________________________________________
> RATS mailing list
> [email-masked]

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 17 Feb 2022 12:54:38 -0800

At the request of the RATS chairs, the upcoming draft is published as a proposed list of candidates. This is so there is a published draft that everyone can look at and discuss. 

This is published draft is not a response to Mike’s request. The next one should fulfill Mike’s request and should be based on a consensus for early allocation established by the RATS chairs.

The mixing of evidence and attestation claims seems a different topic than early allocation to me. Let’s have a different thread for that.

LL

> On Feb 17, 2022, at 12:36 PM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Laurence,
> 
> that is an reasonable request, but I was taking into account Mike's comment that stated:
> 
> And that is why I raised the issues. What you phrase as "existential questions" I'd phrase as reasonable arguments against the indifferent applications of Claims defined by EAT to the RATS Conceptual Messages that are Evidence and Attestation Results.
> 
> Yes, we need to get out a new draft. I am okay with a draft that makes that distinctions. Obviously, the recent development made me very cautious about mixing these definitions wrt the CWT registry in general and EAT, specifically.
> 
> Mixing both Evidence Claims and Attestation Claims into the same bucket seems to be not feasible to me.
> 
> Viele Grüße,
> 
> Henk
> 
> 
>>> On Feb 17, 2022, at 11:27 AM, Yogesh Deshpande <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Laurence,
>>> I just notice you merged the PR:https://github.com/ietf-rats-wg/eat/pull/152 <https://github.com/ietf-rats-wg/eat/pull/152>

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 17 Feb 2022 21:59:26 +0100

I am sorry, I omitted a vital word:

I meant: Evidence Claims and Attestation Result Claims.

Nevertheless, I politely disagree with the assessment that this issue is 
"a different topic than early allocation". Taking into account the 
recent discussions, it honestly seems essential to the entire EAT 
layout, to me.

Viele Grüße,

Henk

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 17 Feb 2022 23:39:41 +0000

If the same claim is intended to be used for different conceptual messages, then it is reasonable that the claim could have different semantics (given the different context). Possibly, the meaning does not change, but unless it is considered, we wouldn't know. 

Alternatively, a claim could be defined in terms of a specific conceptual message. If a claim is used for a different conceptual message, then an I-D that describes the specific conceptual message could define the semantics for that context. 

The RATS criteria for early allocation might want to specifying a conceptual message context? That way any discussion about claim semantics can be qualified accordingly and the list can assess whether its meaning in a different conceptual message might differ.

-Ned

On 2/17/22, 1:01 PM, "RATS on behalf of Henk Birkholz" <[email-masked] on behalf of [email-masked]> wrote:

    Viele Grüße,

    Henk

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 18 Feb 2022 15:00:35 +0100

Hi Ned,

I'd agree with the notion that "the same claim in different conceptual 
messages" requires separate definitions for each conceptual messages. 
Alternatively, Claims could be explicitly restricted to one type of 
conceptual messages. This is the reason why I am so cautious about early 
allocation recently, as I afraid their definition has to change in the 
future in order to address the issue.

In essence, the fashion the Claim's semantic scope is specified today 
has to change, I think.

And even if that would be cleared, I am missing a clear way how to 
express which type of conceptual message an EAT is supposed to 
represent. Plus, I am missing a clear way how to express what Attesting 
Environment is expressing Claims about a certain target environment when 
the EAT is reflecting Evidence.

Viele Grüße,

Henk

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 18 Feb 2022 18:02:06 +0000

(not as chair)
My personal view is it only takes one conceptual message context definition for which there is consensus to justify making a pre-allocation request. If different semantics apply in a different conceptual message context, then a subsequent definition would sufficiently qualify it such that the definition in context A would not be confused with context B. This may be in the gray area of the criteria, but reusing a payload defined for protocol A in protocol B (where its use in protocol B has different semantics) is not a common occurrence IMHO.

(as chair)
The primary motivation for pre-allocation is because there is a schedule dependency and needs to be locked down in advance of official RFC status. I'm not certain that condition exists for the three more recent pre-allocation requests. In general, claims can be defined in any I-D and they can be defined as needed.

-Ned

On 2/18/22, 6:01 AM, "RATS on behalf of Henk Birkholz" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Ned,

    Viele Grüße,

    Henk

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 19 Feb 2022 18:15:32 -0800

Branching the thread away from early allocation...

I’d like to understand the motivation and principles behind restricting claims to either evidence or results.

Maybe you can describe some principles that govern when a claim can be in evidence and when it can be in results?

What about claims like GPS location or UEID that originate in the Attester and often need to end up at the RP? How would those be handled?

This seems to be really about allowed Verifier behavior. It seems that if certain types of claims can only be in evidence and other only in results, then you are starting to narrow Verifier behavior. A change to RATS architecture?

Is there anything wrong with a pure passthrough Verifier. One that only verifies the signature? I can’t think of anything wrong with that and I think it is allowed by the descriptions in RATS architecture.

Maybe some examples of claims that are evidence-only and results-only?

LL

> On Feb 18, 2022, at 6:00 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Ned,
> 
> I'd agree with the notion that "the same claim in different conceptual messages" requires separate definitions for each conceptual messages. Alternatively, Claims could be explicitly restricted to one type of conceptual messages. This is the reason why I am so cautious about early allocation recently, as I afraid their definition has to change in the future in order to address the issue.
> 
> In essence, the fashion the Claim's semantic scope is specified today has to change, I think.
> 
> And even if that would be cleared, I am missing a clear way how to express which type of conceptual message an EAT is supposed to represent.
...

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 21 Feb 2022 20:22:23 +0000

(not as chair)
Laurence,
I wasn't advocating for limiting the scope of certain claims to a specific conceptual message. I'm suggesting that for a claim to be fully defined its definition should consider what the claim means in each conceptual message context.

For example, a computer that consists of a main board, cpu complex and nic / radio might have 3 UEIDs. Each component would be considered a 'device' by its manufacturer hence the requirement that only one UEID be used can be met. However, upon integration of these components, there are 3 UEIDs in the computer that could be reported in evidence. However, one of them will be considered the unique identifier for the computer from the perspective of identifying and authenticating the computer to a Verifier. Possibly the OEM would assert the OEM provided UEID is the computer identity or alternatively, the NIC UEID would be used considering it could be the logical endpoint of a secure connection. 

This is just a simple example, but it highlights that context matters.

The EAT text "(Note that while devices with multiple network interfaces have multiple MAC addresses, there is only one UEID for a device)" if interpreted as normative could have profound impact on the supply chain if "device" is interpreted as "computer", in the above example, as it would require all the component vendors to remove their use of UEIDs. But in the context of the Verifier producing attestation results, the UEID that was used to establish the secure channel over which the computer was authenticated and appraised, then that UEID would likely be the right identifier to represent to the Relying Party - since that was the identifier that had the attestation credential.

There are other apparent contradictions in the UEID definition that require context to sort out. In the context of this wording "Several types are allowed to accommodate different industries and different manufacturing processes" it seems the intended context is Endorser / RVP. While another line "The consumer (the Relying Party) of a UEID MUST treat a UEID as a completely opaque string of bytes and not make any use of its internal structure." strongly implies Relying Party context. 

The type 2 UEID indicates the Endorser / RVP identity is included: "This makes use of the IEEE company identification registry." A type 2 UEID could be used to avoid having to use a separate vendor identity claim. But if the relying party must treat it as opaque, then something has to supply a vendor identity claim in some other way. Possibly, the Verifier extracts the vendor ID from the UEID and recasts it in some other form? 

Another apparent contradiction is:
 	"Device manufacturers are allowed to change from one type of UEID to another anytime they want." 
And 
	"The UEID is permanent. It never change for a given device / entity."

If a manufacturer changes the device identity, say because they re-manufactured the device after deployment by retiring an embedded key that possibly has worn out or was compromised, and therefore wanted to give the device a new identity. Then it is unclear which of these statements normatively applies. Possibly, the first statement applies in the context of Endorsement / Reference Values while the second statement applies in the context of Evidence collection (where an observed change in UEID would be a red flag if it changed from one attestation event to the next).

It might make sense for EAT draft to clarify that "the claims definitions focus on an encoding. Their use in conceptual messages may introduce additional semantics."
Including a caveat like this would make the scope of the EAT draft clearer and possibly easier to make progress toward RFC.

BTW: I noticed the definition of type 3 UEID refers to "SVN" but doesn't (apparently?) define it.

Thx,
Ned

On 2/19/22, 6:15 PM, "Laurence Lundblade" <[email-masked]> wrote:

    LL

    ...

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 22 Feb 2022 09:32:40 -0800

> On Feb 21, 2022, at 12:22 PM, Smith, Ned <[email-masked]> wrote:
> 
> (not as chair)
> Laurence,

Ahh, now I understand.

I can see that wording might need adjustment in some cases. For example, the UEID definition refers to the Relying Party.

This wording is from before the separation of Verifier from Relying Party.

I have filed an issue  <https://github.com/ietf-rats-wg/eat/issues/169>to go look at the all the claims wording for this. So far they just seem like simple wording issues to me, not anything big that would affect early allocation.

That said, all of the issues you mention below seem to apply whether UEID is in Evidence or Results. I will respond to them in a separate thread.

LL

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 22 Feb 2022 18:37:50 +0100

Hi Laurence,

I am not trying to beat a dead horse here, but one input for "can it be 
both" or "is it one or the other" I provided in the now unfortunately 
closed:

> https://github.com/ietf-rats-wg/eat/pull/152

Which was closed with the reason that it "isn't suitable to block the 
IANA Claim Key assignment work for the existential questions Henk has 
posed".

I still beg to differ ;-)

Viele Grüße,

Henk

On 22.02.22 18:32, Laurence Lundblade wrote:
> 
>> On Feb 21, 2022, at 12:22 PM, Smith, Ned <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> (not as chair)
>> Laurence,
>> I wasn't advocating for limiting the scope of certain claims to a 
>> specific conceptual message. I'm suggesting that for a claim to be 
>> fully defined its definition should consider what the claim means in 
>> each conceptual message context.
> 
> Ahh, now I understand.
> 
> I can see that wording might need adjustment in some cases. For example, 
> the UEID definition refers to the Relying Party.
> 
> I have filed an issue <https://github.com/ietf-rats-wg/eat/issues/169>to 
> go look at the all the claims wording for this. So far they just seem 
> like simple wording issues to me, not anything big that would affect 
> early allocation.
> 
> 
> That said, all of the issues you mention below seem to apply whether 
> UEID is in Evidence or Results. I will respond to them in a separate thread.
> 
> LL
> 
> 
> 
>>
>> For example, a computer that consists of a main board, cpu complex and 
>> nic / radio might have 3 UEIDs. Each component would be considered a 
>> 'device' by its manufacturer hence the requirement that only one UEID 
>> be used can be met. However, upon integration of these components, 
>> there are 3 UEIDs in the computer that could be reported in evidence. 
>> However, one of them will be considered the unique identifier for the 
>> computer from the perspective of identifying and authenticating the 
>> computer to a Verifier. Possibly the OEM would assert the OEM provided 
>> UEID is the computer identity or alternatively, the NIC UEID would be 
>> used considering it could be the logical endpoint of a secure connection.
>>
>> The EAT text "(Note that while devices with multiple network 
>> interfaces have multiple MAC addresses, there is only one UEID for a 
>> device)" if interpreted as normative could have profound impact on the 
>> supply chain if "device" is interpreted as "computer", in the above 
>> example, as it would require all the component vendors to remove their 
>> use of UEIDs. But in the context of the Verifier producing attestation 
>> results, the UEID that was used to establish the secure channel over 
>> which the computer was authenticated and appraised, then that UEID 
>> would likely be the right identifier to represent to the Relying Party 
>> - since that was the identifier that had the attestation credential.
>>
>> There are other apparent contradictions in the UEID definition that 
>> require context to sort out. In the context of this wording "Several 
>> types are allowed to accommodate different industries and different 
>> manufacturing processes" it seems the intended context is Endorser / 
>> RVP. While another line "The consumer (the Relying Party) of a UEID 
>> MUST treat a UEID as a completely opaque string of bytes and not make 
>> any use of its internal structure." strongly implies Relying Party 
>> context.
>>
>> The type 2 UEID indicates the Endorser / RVP identity is included: 
>> "This makes use of the IEEE company identification registry." A type 2 
>> UEID could be used to avoid having to use a separate vendor identity 
>> claim. But if the relying party must treat it as opaque, then 
>> something has to supply a vendor identity claim in some other way. 
>> Possibly, the Verifier extracts the vendor ID from the UEID and 
>> recasts it in some other form?
>>
>> If a manufacturer changes the device identity, say because they 
>> re-manufactured the device after deployment by retiring an embedded 
>> key that possibly has worn out or was compromised, and therefore 
>> wanted to give the device a new identity. Then it is unclear which of 
>> these statements normatively applies. Possibly, the first statement 
>> applies in the context of Endorsement / Reference Values while the 
>> second statement applies in the context of Evidence collection (where 
>> an observed change in UEID would be a red flag if it changed from one 
>> attestation event to the next).
>>
>> It might make sense for EAT draft to clarify that "the claims 
>> definitions focus on an encoding. Their use in conceptual messages may 
>> introduce additional semantics."
>> Including a caveat like this would make the scope of the EAT draft 
>> clearer and possibly easier to make progress toward RFC.
>>
>> On 2/19/22, 6:15 PM, "Laurence Lundblade" <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>    I’d like to understand the motivation and principles behind 
>> restricting claims to either evidence or results.
>>
>>    Maybe you can describe some principles that govern when a claim can 
>> be in evidence and when it can be in results?
>>
>>    What about claims like GPS location or UEID that originate in the 
>> Attester and often need to end up at the RP? How would those be handled?
>>
>>
>>    This seems to be really about allowed Verifier behavior. It seems 
>> that if certain types of claims can only be in evidence and other only 
>> in results, then you are starting to narrow Verifier behavior. A 
>> change to RATS architecture?
>>
>>    Is there anything wrong with a pure passthrough Verifier. One that 
>> only verifies the signature? I can’t think of anything wrong with that 
>> and I think it is allowed by the descriptions in RATS architecture.
>>
>>> On Feb 18, 2022, at 6:00 AM, Henk Birkholz 
>>> <[email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>>
>>> Hi Ned,
>>>
>>> I'd agree with the notion that "the same claim in different 
>>> conceptual messages" requires separate definitions for each 
>>> conceptual messages. Alternatively, Claims could be explicitly 
>>> restricted to one type of conceptual messages. This is the reason why 
>>> I am so cautious about early allocation recently, as I afraid their 
>>> definition has to change in the future in order to address the issue.
>>>
>>> express which type of conceptual message an EAT is supposed to represent.
>>    ...
>>
>>
>>
>>
>>
>>
>

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 22 Feb 2022 10:07:21 -0800

Henk,

Seems to me this is up to the chairs to sort out.

If they think that this issue is enough to block early allocation, that there isn’t enough consensus and that the claim definitions are changing too much, then they should indicate that.

LL

> On Feb 22, 2022, at 9:37 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Laurence,
> 
> I am not trying to beat a dead horse here, but one input for "can it be both" or "is it one or the other" I provided in the now unfortunately closed:
> 
> Which was closed with the reason that it "isn't suitable to block the IANA Claim Key assignment work for the existential questions Henk has posed".
> 
>>> On Feb 21, 2022, at 12:22 PM, Smith, Ned <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> (not as chair)
>>> Laurence,
>>> On 2/19/22, 6:15 PM, "Laurence Lundblade" <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>> On Feb 18, 2022, at 6:00 AM, Henk Birkholz <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> Hi Ned,
>>>>

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 22 Feb 2022 10:28:58 -0800

Hi Ned,

Forking this discussion to focus on the UEID issues.

> The EAT text "(Note that while devices with multiple network interfaces have multiple MAC addresses, there is only one UEID for a device)" if interpreted as normative could have profound impact on…

There are issues like this for every claim in an EAT that is used to represent a composite device, not just UEIDs.

These composite device issues arise whether the EAT is Attestation Results or Evidence too. It is perfectly OK for some EATs to pass the deep structure of a complex device to a RP and for others to only pass a summary to the RP.

We’re not going to create any kind of protocol or system definition language here in RATS that can describe all composite devices. All we can do is provide basic constructs. Submods is the main construct for that.

Attestation systems based on EAT will vary widely. We can’t expect an attestation system that fully represents a complex mobile phone to also do small high-value IoT devices. Even on a mobile phone, there could be multiple implementations of EAT for different use cases that the mobile phone supports. Perhaps one for FIDO, one for the Android key store, several for content protection in different content handling apps...

> 
> There are other apparent contradictions in the UEID definition that require context to sort out. In the context of this wording "Several types are allowed to accommodate different industries and different manufacturing processes" it seems the intended context is Endorser / RVP.

All claims can be discussed from the manufacturer’s view separately from the consumer’s view. Someone has to generate them and someone has to consume them. Discussing the manufacturer’s view separately doesn’t imply semantics vary depending on who consumes them.

The three types of UEID are from the manufacturer view only.

> While another line "The consumer (the Relying Party) of a UEID MUST treat a UEID as a completely opaque string of bytes and not make any use of its internal structure." strongly implies Relying Party context.

If we make the text “The consumer (e.g., the Verifier or the RP) of a UEID…” then the text is fine. It is a minor adjustment to the text.

The text still holds. The consumer, be it the Verify or the RP, still treats the UEID exactly the same. There is no variance by context for UEID.

> The type 2 UEID indicates the Endorser / RVP identity is included: "This makes use of the IEEE company identification registry." A type 2 UEID could be used to avoid having to use a separate vendor…

The separate vendor ID claims exists. It is the HW OEM ID. The document mentions this explicitly. There is no issue here.

> If a manufacturer changes the device identity, say because they re-manufactured the device after deployment by retiring an embedded key that possibly has worn out or was compromised, and therefore…

There is no contradiction here.

A manufacturer can’t change the UEID of a device once it is made, but it can switch to a new type of UEID for new devices it makes in the future.

I filed an issue  <https://github.com/ietf-rats-wg/eat/issues/170>to clarify this.

> BTW: I noticed the definition of type 3 UEID refers to "SVN" but doesn't (apparently?) define it.

SVN is defined by 3GPP. It is part of the IMEI encoding thing like the Luhn check. While you can’t easily get the 3GPP document referenced, you can see it here https://en.wikipedia.org/wiki/International_Mobile_Equipment_Identity.

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 22 Feb 2022 18:44:57 +0000

> That said, all of the issues you mention below seem to apply whether UEID is in Evidence or Results. I will respond to them in a separate thread.
Yes, but some of the descriptions apply when claim is an Endorsement / RV.
My suggestion was that it would be better to provide a caveat that additional semantics may be captured when considering the claim in a specific conceptual message. Then you don’t have to position that all the semantics are defined in the EAT draft. The set of description text that is true across all the conceptual message types would be the best language to include. Language that is conditional / contradictory would likely not be best to include as it requires more context. I think less is more in this case.
-Ned

From: Laurence Lundblade <[email-masked]>
Date: Tuesday, February 22, 2022 at 9:32 AM
To: "Smith, Ned" <[email-masked]>
Cc: Henk Berkholz <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Same claim in Evidence and Results (was Re: [Rats] Second attempt at early allocation of CWT Labels (PR #152))

On Feb 21, 2022, at 12:22 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

(not as chair)
Laurence,

Ahh, now I understand.

I have filed an issue <https://github.com/ietf-rats-wg/eat/issues/169> to go look at the all the claims wording for this. So far they just seem like simple wording issues to me, not anything big that would affect early allocation.

LL

Thx,
Ned

On 2/19/22, 6:15 PM, "Laurence Lundblade" <[email-masked]<mailto:[email-masked]>> wrote:

   LL

On Feb 18, 2022, at 6:00 AM, Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ned,

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 22 Feb 2022 18:46:13 +0000

It's really up to the working group. The chairs just assess consensus (or not).
-Ned

On 2/22/22, 10:07 AM, "Laurence Lundblade" <[email-masked]> wrote:

    Henk,

    LL

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 22 Feb 2022 10:54:18 -0800

> Yes, but some of the descriptions apply when claim is an Endorsement / RV.

Hmmm, expand EAT or EAT claims to Endorsements and/or to Reference Values? That would be a new thing.

Maybe that’s a good idea. Maybe it’s not. Not sure yet. :-)

> My suggestion was that it would be better to provide a caveat that additional semantics may be captured when considering the claim in a specific conceptual message. Then you don’t have to position…

Understood. When I go through the all the claims to address this issue <https://github.com/ietf-rats-wg/eat/issues/169>, I’ll get a better understanding of whether I think their semantics vary by context. So far I don’t see that much variance, but will keep an open mind. Appreciate the discussion.

LL

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 22 Feb 2022 19:59:54 +0100

Hi Ned & Laurence,

my assumption still is that my comments for each of the Claims are 
highlighting how a reader of the EAT spec would remain in the unclear 
about how "limiting the scope of certain claims to a specific conceptual 
message" is established via the existing text.

And by extension, how a reader is quite possible in the unclear how the 
current strategy to allow for each Claim to appear in any type of 
conceptual message, indifferently, is a feasible approach.

Viele Grüße,

Henk

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 22 Feb 2022 19:12:43 +0000

There is language in EAT that describes a manufacturers point of view. A claim that expresses a manufacturer point of view is either an endorsement or a RV.

If the claim is from the device’s point of view, then it is a device claim and not a manufacturer’s claim. Device claims are believed either because they have matching reference values or because the verifier has concluded the device is trustworthy so it believes these additional claims based on an attestation result from appraising the claims that match reference value claims.

But if EAT is being written from the perspective of claims being either evidence or attestation results, then that clarification should be included in the draft somewhere (and any language that captures the manufacturer or supply chain perspective probably needs to be reworded somehow).
-Ned

Date: Tuesday, February 22, 2022 at 10:54 AM

Understood. When I go through the all the claims to address this issue<https://github.com/ietf-rats-wg/eat/issues/169>, I’ll get a better understanding of whether I think their semantics vary by context. So far I don’t see that much variance, but will keep an open mind. Appreciate the discussion.

LL

-Ned

From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 22, 2022 at 9:32 AM
To: "Smith, Ned" <[email-masked]<mailto:[email-masked]>>
Cc: Henk Berkholz <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Same claim in Evidence and Results (was Re: [Rats] Second attempt at early allocation of CWT Labels (PR #152))

(not as chair)
Laurence,

Ahh, now I understand.

LL

Thx,
Ned

   LL

Hi Ned,

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 22 Feb 2022 20:19:44 +0100

You are kidding, right?

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 22 Feb 2022 11:51:13 -0800

Absolutely do not want to expand the EAT doc to cover Endorsement and Reference Values in any way, but maybe another draft might make use of some stuff that is in EAT.

Ned suggested it, not me. :-)

LL

> On Feb 22, 2022, at 11:19 AM, Henk Birkholz <[email-masked]> wrote:
> 
> You are kidding, right?
>

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 22 Feb 2022 20:17:58 +0000

My comments in green font. -Ned

From: Laurence Lundblade <[email-masked]>
Date: Tuesday, February 22, 2022 at 10:29 AM
To: "Smith, Ned" <[email-masked]>
Cc: Henk Berkholz <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: UEID comments (was Re: Same claim in Evidence and Results (was Re: [Rats] Second attempt at early allocation of CWT Labels (PR #152)))

Hi Ned,

(not as chair)
Laurence,

There are issues like this for every claim in an EAT that is used to represent a composite device, not just UEIDs.
There could be clearer language about what constitutes a device, composite device, entity or a sub-module. I’ll use ‘entity’ to mean any of the above.  There are multiple structures that can represent the set of claims that belong to an entity.  For example, a token (CWT/JWT), UCCS or a submod could be used for the same or different entities.

But the language used to describe the claim (in some cases) implies a particular scope. I just picked on UEID as an example. Debug and hardware version are others as well. Since scope is defined by the entity that asserts the claims, it would be better to describe claims using terminology that doesn’t assume scope IMHO.

All claims can be discussed from the manufacturer’s view separately from the consumer’s view. Someone has to generate them and someone has to consume them. Discussing the manufacturer’s view separately doesn’t imply semantics vary depending on who consumes them.
I guess I disagree. Someone implementing the spec wears the hat of one of the roles. It will be confusing if the descriptions randomly  switch hats.
The three types of UEID are from the manufacturer view only.
This then means the claims are asserted from an Endorser or RVP perspective. However, if the identifier was used to construct an identity (meaning the device could authenticate the identifier) then it is also a claim from the point of view of the device (entity).

Here are 4 examples:

(1)     a device might have an IMEI (UEID-A) and a type 1 random UEID (UEID-B). UEID-B is used in a device-id certificate while UEID-A is a value that exists in a NIC (and for the purposes of this example, doesn’t have an exposed interface to the code that is authenticating using UEID-B). A secure session between Verifier and Entity-B uses the certificate to associate UEID-B to entity-B. The UEID-B might not exist on the device at all. But the device is asserting UEID-B by using the private key of the certificate that contains UEID-B. Hence, there is both a mfg and a device perspective.

(2)     UEID-A exists on the device, but doesn’t appear in any evidence that entity-B generates. However, it could be included in a manifest or as an attribute to the certificate stating that the device (containing entity-A) has UEID-A. This is an endorsement since it doesn’t appear in evidence or a certificate. The fact that UEID-A exists on the device (even though the value wasn’t reported) means there is a device perspective.

(3)     Entity-A has an attesting environment that collects UEID-A as evidence. It isn’t used to authenticate the channel to the verifier so from the verifier’s perspective it isn’t an identity. From the device’s perspective it is evidence. This means the verifier should have a reference value claim for UEID-A, otherwise, it isn’t going to pass appraisal. This is a device perspective.

(4)     As a variation on (3), instead of including UEID-A in Evidence. It is included in a protocol data unit for a management interface that dumps configuration data. It isn’t endorsement or RV because it wasn’t signed by an Endorser / RVP. It isn’t evidence because it wasn’t signed by an Attesting Environment. But it did come from the device (entity), hence there’s a device perspective.

The text still holds. The consumer, be it the Verify or the RP, still treats the UEID exactly the same. There is no variance by context for UEID.
Since verifier and RP are supposed to treat UEID as opaque, there is nothing they can (should) do other than check binary equivalence. That means they only care about the number of bytes and byte order convention. Everything in the UEID type tables should be regarded as informative. But since the typing exists and the language for how the various types of UEIDs are constructed exists, it seems to contradict the idea that UEID values are opaque. It appears the normative language is aimed at manufacturers (Endorsers or RVPs), but there is no way to verify these properties are valid. A description of the properties in a document isn’t enforcement.

The separate vendor ID claims exists. It is the HW OEM ID. The document mentions this explicitly. There is no issue here.
The issue is that the draft requires a type 2 UEID to include a manufacturer identifier. If it isn’t used (at the end of the day) why put it in the document? It should at least be marked as informative.

A manufacturer can’t change the UEID of a device once it is made, but it can switch to a new type of UEID for new devices it makes in the future.
A manufacture can change a UEID value. Writing text in a document doesn’t enforce the behavior described in the text.
But this wasn’t my point above. There are valid use cases for changing the identity of an entity from the manufacturers perspective. However, changing a device identity from the entity’s perspective is an indication that an unauthorized change was made to an identifier.

IMO, given the EAT authors were not intending to describe Endorsement / RVP perspectives or requirements, it makes sense to revisit the text that describes claims from a manufacturers perspective.

I filed an issue <https://github.com/ietf-rats-wg/eat/issues/170> to clarify this.

LL

Thx,
Ned

   LL

Hi Ned,

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 22 Feb 2022 20:30:42 +0000

I asked for clarification about what attestation roles' perspectives were assumed when describing the various claims. This was because there is language that suggests Endorser / RVP roles were considered. There is language that suggests RP, Verifier and Attester roles are considered too. But it isn't clear that all roles are considered for all claims. 

I suggested that if the goal was not to consider all roles for all claims, that the claims be described based on a least common denominator assumption. That is, only wording that is true for all roles would be included. It is a bit of a trick question in that you have to consider all roles in order to know what attributes will be common. It also means anything that is specific to a role or nuanced would not be included so as to avoid special case descriptions. 
 
That means, terminology that is aimed at manufacturers, relying party, verifier, attester should be removed or clearly identified as informative. My guess is the result will be that the CDDL most closely captures normative expression and most everything else is informative. 

On 2/22/22, 11:51 AM, "Laurence Lundblade" <[email-masked]> wrote:

    LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 22 Feb 2022 21:00:48 +0000

Thanks Ned for your last two emails.   

I have been trying to track the overall conversation across forks.   I see your comments/questions on the UEID thread as coupled to the thoughts below.  (I.e., "Since scope is defined by the entity that asserts the claims, it would be better to describe claims using terminology that doesn’t assume scope IMHO.")

I agree with this sentiment.  For me this set of threads keeps coming back to establishing claim context to the Relying Party.   If the Policy for Attestation Results doesn't simply and unambiguously know the identity/source of a claim, the architectural role making the claim, and the freshness, then we are wasting our time here.   

So we need to minimize Relying Party policy language ambiguity.

For me, I like separating the names of claims which might come from different architectural roles.   Things are easier for Policy programming on the Relying Party this way.

And we won't suddenly find a claim from a Verifier which now can also come from an Attester.   

There are alternatives to doing this with namespaces.  But we no proposals going down this path yet.

Eric

> -----Original Message-----

> From: RATS <[email-masked]> On Behalf Of Smith, Ned

> Sent: Tuesday, February 22, 2022 3:31 PM

> To: Laurence Lundblade <[email-masked]>; Henk Birkholz

> <[email-masked]>

> Subject: Re: [Rats] Same claim in Evidence and Results (was Re: Second attempt

> at early allocation of CWT Labels (PR #152))

> I asked for clarification about what attestation roles' perspectives were

> assumed when describing the various claims. This was because there is language

> that suggests Endorser / RVP roles were considered. There is language that

> suggests RP, Verifier and Attester roles are considered too. But it isn't clear that

> all roles are considered for all claims.

> I suggested that if the goal was not to consider all roles for all claims, that the

> claims be described based on a least common denominator assumption. That is,

> only wording that is true for all roles would be included. It is a bit of a trick

> question in that you have to consider all roles in order to know what attributes

> will be common. It also means anything that is specific to a role or nuanced

> would not be included so as to avoid special case descriptions.

> That means, terminology that is aimed at manufacturers, relying party, verifier,

> attester should be removed or clearly identified as informative. My guess is the

> result will be that the CDDL most closely captures normative expression and

> most everything else is informative.

> On 2/22/22, 11:51 AM, "Laurence Lundblade" < <mailto:[email-masked]> [email-masked]> wrote:

>     Absolutely do not want to expand the EAT doc to cover Endorsement and

> Reference Values in any way, but maybe another draft might make use of some

> stuff that is in EAT.

>     > On Feb 22, 2022, at 11:19 AM, Henk Birkholz

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

>  <mailto:[email-masked]> [email-masked]

>  <https://www.ietf.org/mailman/listinfo/rats> https://www.ietf.org/mailman/listinfo/rats

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 23 Feb 2022 01:22:31 +0000

Eric,
From Mike Bursell’s book – “Trust in computer systems and the cloud”, its suggested that trust can be represented in a 2Xn table where the right column lists the trust assumptions of the trustee and the left column trust assumptions of the trustor. If the assumptions map / are corelated / from trustor to trustee then trust exists. In RATS arch context an Attester is a trustor and Verifier is a trustee. Or Verifier is trustor and RP is trustee. In a background check model, an Attester is a trustor and the RP is a trustee, but only if a Verifier agrees. In general, the Attester • RP trust relationship is the primary objective behind attestation. The other interactions support aspects of the trust ingredients.

The trust relationship has the following ingredients:
Context(s), Time-specifics, Action(s), Expectation(s) and Assurance(s).

Claims are just the building blocks for making statements in each of the 5 ingredients.

Using Mike Bursell’s model, the ingredients are what defines “scope” in the thread below.

The other RATS roles (Endorser, RVP, Verifier, Verifier Owner, RP Owner) qualify some aspect of the table ingredients. But ultimately, the RP needs to do the mapping exercise: Attester • RP in order to establish trust. That implies the table is fleshed out. Maybe some reduction of claims is applied to change the level of abstraction, granularity etc… but that doesn’t mean the context of who asserted what is filtered / removed.

From a standardization perspective, having commonly understood building block claims is a bit like agreeing on the words we use to make sentences. But if a claim could be used in more than one ingredient in the table above, then knowing which ingredient the sentence describes is important context. We wouldn’t expect to deduce the ingredient statement simply by looking at the claim any more than we should expect to deduce the meaning of a multi-word sentence simply by looking at one word.

The environment to which evidence measurements belong is an important context about the Attester. The context of which Attesting Env. Collects claims about which Target Env. Establishes an expectation that the Attester didn’t lie about its measurements. A RVP asserting claims that match evidence claims establishes assurance that the claims are correct. Etc…

The RATS RP role is essentially only half of a role because it doesn’t define application / use case specific elements; only attestation specific. That means some of the table ingredients (such as actions and possibly expectations) are out of scope for RATS. But RATS work creates a place to fill-in-the-blank for the parts that are app specific.

From: RATS <[email-masked]> on behalf of "Eric Voit (evoit)" <evoit=[email-masked]>
Date: Tuesday, February 22, 2022 at 1:02 PM
To: "Smith, Ned" <[email-masked]>, Laurence Lundblade <[email-masked]>, Henk Berkholz <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Rats] Same claim in Evidence and Results (was Re: Second attempt at early allocation of CWT Labels (PR #152))

Eric

> On 2/22/22, 11:51 AM, "Laurence Lundblade" <[email-masked]<mailto:[email-masked]>> wrote:

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

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 23 Feb 2022 12:43:36 -0800

> On Feb 22, 2022, at 1:00 PM, Eric Voit (evoit) <[email-masked]> wrote:
> 
> I have been trying to track the overall conversation across forks.

I fork discussions to try to keep focused on the topic at hand so the topic at hand can close out.

>    I see your comments/questions on the UEID thread as coupled to the thoughts below.  (I.e., "Since scope is defined by the entity that asserts the claims, it would be better to describe claims using terminology that doesn’t assume scope IMHO.”)

Not completely sure, but I think I agree too.

> So we need to minimize Relying Party policy language ambiguity.

I don’t quite understand this comment. Maybe my last few paragraphs address this? Maybe my answer is that creating broad general unambiguous RP policy language is a rat hole we don’t want to address in the IETF?

> And we won't suddenly find a claim from a Verifier which now can also come from an Attester.   

Using string labels, would you want something like this?

   “evidence.location”
   “results.location”
   “evidence.ueid”
   “results.ueid"

to separate the location and UEID claims in evidence from results? 

Then maybe when “evidence.location” occurs in an attestation results token you know it was passed through?

In this idea, the structure (e.g., the CDDL) for evidence.location and results.location would be identical.

I’m pretty sure I’m not in favor of this. I’m just given an example to try to understand.

Where this rat holes for me is that the behaviors of the Attester and the Verifier are so widely varying here that it seems not possible to pin them down in an IETF standard. Instead you as an RP must understand on a case by case basis what the Attester and Verifier are doing to know how to trust it. For example,
  
 — The location evidence could come from a US satellite, a Russian satellite, WiFi location maps created by Google, Cellular triangulation from Verizon and/or combinations of the above
 — The Verifier could just verify the signature and pass it on, could cross check the location against the IP address based location service, could ask the carrier for triangulation based on the IMEI,...

There’s no way we here in RATS can sort this variation in trustworthiness for location, nor for most other claims. Maybe there are a few claims we can lock this down for, but in general we shouldn’t even try.

As an RP you have to go read the marketing description, service agreements and such for a verifier service to know what it is going to do for you, not the IETF standard.

LL

> > From: RATS <[email-masked] <mailto:[email-masked]>> On Behalf Of Smith, Ned
> > To: Laurence Lundblade <[email-masked] <mailto:[email-masked]>>; Henk Birkholz
> > <[email-masked] <mailto:[email-masked]>>
> > Cc: [email-masked] <mailto:[email-masked]>
> > On 2/22/22, 11:51 AM, "Laurence Lundblade" <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > <[email-masked] <mailto:[email-masked]>> wrote:
> >     >
> >     > You are kidding, right?
> >     >

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 23 Feb 2022 21:50:24 +0100

Hi Laurence,

while that is a crude way to do it, I guess, it would address some of 
the problem, I think. If you would find “evidence.location” in AR, then 
you at least know it was a pass-through and not the output of an 
appraisal procedure. You'd still not know what that means to you as you 
are not necessarily aware of the the semantics of the Evidence, but at 
least you can choose to ignore it, as you might only trust the 
Verifier's AR and not the Attester's Evidence.

Probably there are better ways to express this, but your example is not 
bad per se.

Viele Grüße,

Henk

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 23 Feb 2022 13:24:38 -0800

> On Feb 23, 2022, at 12:50 PM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Laurence,
> 
> while that is a crude way to do it, I guess, it would address some of the problem, I think. If you would find “evidence.location” in AR, then you at least know it was a pass-through and not the output of an appraisal procedure. You'd still not know what that means to you as you are not necessarily aware of the the semantics of the Evidence, but at least you can choose to ignore it, as you might only trust the Verifier's AR and not the Attester's Evidence.
> 
> Probably there are better ways to express this, but your example is not bad per se.

And I also said I think this is probably not a good thing to do because there is so much variance in the level of trustworthiness for claim from an Attester and in cross-checking a Verifier can do on it.

I don’t really think it is possible to write down in an IETF standard the broad range of trustworthiness levels a claim might have in all the contexts.

But if we were to try, what do you think about something like an Attestation Results claim that tells you something about the origin and Verifier processing of each claim in the AR? For example it would tell you these about each claim in the AR:
  - origin — evidence, endorsement, computed by verifier
  - verification level - authenticated, authenticated and confirmed to be in expected range (what ever that is), ?

I’m not sure this is a good idea either, but trying to explore the space to understand...

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 23 Feb 2022 21:58:51 +0000

Hi Laurence,
 
> From: Laurence Lundblade, February 23, 2022 3:44 PM
> 
> On Feb 22, 2022, at 1:00 PM, Eric Voit (evoit) <mailto:[email-masked]> wrote:
> 
> <snip>
> 
> I don’t quite understand this comment. Maybe my last few paragraphs address
> this? Maybe my answer is that creating broad general unambiguous RP policy
> language is a rat hole we don’t want to address in the IETF?

Building an entire policy language is the IETF is not necessary.  But if we can agree to unambiguous object names, life is easier.

>  For me, I like separating the names of claims which might come from different
> architectural roles.   Things are easier for Policy programming on the Relying
> Party this way.

This is a reasonable way to build things bottoms up.  But being unambiguous can be hard -- this is one reason why namespaces are defined top down.  (E.g., what if you have two Verifiers for different aspects of the appraisal.  Should objects be able to prepend each claim with a (maskable) uuid for a specific asserting identity?)
 
> results.location would be identical.

I think by structure you mean that ".location" is strongly typed, and the domain of assignable values is consistent between Attester and Verifier.  And I like this approach as it enables interworking/portability of data object definitions.
 
> Where this rat holes for me is that the behaviors of the Attester and the Verifier
> are so widely varying here that it seems not possible to pin them down in an IETF
> standard. Instead you as an RP must understand on a case by case basis what
> the Attester and Verifier are doing to know how to trust it.

This is exactly the case.  The RP needs to understand what claims it might trust from a specific Verifier, and what claims it might trust from a type of Attester.  If we can't agree on *some* generalized unambiguously named claims across the domain of RATS use cases, there is little reason for RATS to be a single WG.

> For example,
> 
>  — The location evidence could come from a US satellite, a Russian satellite,
> WiFi location maps created by Google, Cellular triangulation from Verizon
> and/or combinations of the above
>  — The Verifier could just verify the signature and pass it on, could cross check
> the location against the IP address based location service, could ask the carrier
> for triangulation based on the IMEI,...
> 
> There’s no way we here in RATS can sort this variation in trustworthiness for
> location, nor for most other claims. Maybe there are a few claims we can lock
> this down for, but in general we shouldn’t even try.

Agree.  It is up to the RP to determine which objects it accepts as trustworthy from a specific Verifier.

> As an RP you have to go read the marketing description, service agreements and
> such for a verifier service to know what it is going to do for you, not the IETF
> standard.

The object names can be consistent.  It is the identity of a specific Verifier which drives you to trust it or not.

Eric

> > From: RATS <mailto:[email-masked]> On Behalf Of Smith, Ned
> > To: Laurence Lundblade <mailto:[email-masked]>; Henk Birkholz
> > <mailto:[email-masked]>
> > Cc: mailto:[email-masked]
> > On 2/22/22, 11:51 AM, "Laurence Lundblade" <mailto:[email-masked]>
> wrote:
> >
> > <mailto:[email-masked]> wrote:
> >     >
> >     > You are kidding, right?
> >     >
> > mailto:[email-masked]

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 23 Feb 2022 23:01:15 +0100

Hi Laurence,

now I am confused :-) I thought the topic is believable Claim provenance 
and not level of trustworthiness. Maybe I should not have stated the 
obvious: that a relying party maintains trust relationships to 
Verifiers. That might just have been distracting.

I am not commenting on any trustworthiness levels. I solely commenting 
on the "origin" part that is about the provenance of claims processed by 
remote attestation procedures (literally, that's why it's RATS).

Instead I let others comment on the feasibility of trustworthiness 
levels in AR :-)

It also feels like I have to point out now that "structuring your 
Evidence and AR well, so you are not confused by the origin of their 
contents" and "introducing a concise taxonomy for attestation results in 
the form of a trustworthiness vectors" are separate different things :-)

So personally, I am steering clear from "verification level" in the 
context of EAT as that seems to overload the scope of the EAT space 
quite a bit, but I am very in favor of improve on the "origin" part.

Viele Grüße,

Henk

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 23 Feb 2022 22:45:20 +0000

> From: Laurence Lundblade, February 23, 2022 4:25 PM
> 
> > while that is a crude way to do it, I guess, it would address some of the
> problem, I think. If you would find “evidence.location” in AR, then you at least
> know it was a pass-through and not the output of an appraisal procedure. You'd
> still not know what that means to you as you are not necessarily aware of the
> the semantics of the Evidence, but at least you can choose to ignore it, as you
> might only trust the Verifier's AR and not the Attester's Evidence.
> >
> And I also said I think this is probably not a good thing to do because there is so
> much variance in the level of trustworthiness for claim from an Attester and in
> cross-checking a Verifier can do on it.

Claims are always contextual.  I trust my spouse completely.  But I wouldn't trust her to write this email.  There is no conflict in the short sentences as the domains of relevance will never overlap. 

So for an RP to evaluate any claim, the RP needs to understand how easy/hard it was for a Verifier to do its job.  E.g., if the firmware on an old Attester chip can be spoofed to provide KGVs, the Verifier can never assert a level of trust in an Attester equivalent to that of newer chips which can do real measurements of firmware.   

I.e.,
 
> I don’t really think it is possible to write down in an IETF standard the broad
> range of trustworthiness levels a claim might have in all the contexts.

draft-ietf-rats-ar4si has eight claims with four course levels of trustworthiness (Affirming, Warning, Contraindicated, None).  Each level is extensible for standards and non-standards based values/details.  This approach might not work for claims coming from an Attester.  But I would love to see counter-examples/feedback/etc. for assertions that might come from a Verifier. 

> But if we were to try, what do you think about something like an Attestation
> Results claim that tells you something about the origin and Verifier processing of
> each claim in the AR?

The RP still needs to understand to verified Identity of the Attester.  And with that identity, you should know the equipment type, and therefore what could legitimately claimed about the type of Attester.  Or the type of Verifier.  Anything not legitimately be claimed should be discarded before being used by the RP in its policy.

Eric

> For example it would tell you these about each claim in the
> AR:

---

From: Giridhar Mandyam <[email-masked]>
Date: Wed, 23 Feb 2022 23:26:44 +0000

Sorry to change topics, but I thought it would be beneficial to see how other group documents describe attestation results and their semantics, and distinguish them from evidence.  So I referred to https://datatracker.ietf.org/doc/draft-ietf-rats-tpm-based-network-device-attest/.  It should be exemplary, as the group has decided to forward it for IESG review.  So there must be zero ambiguity in the document with regards to how attestation results are formed, whether attestation evidence can ever be reflected in attestation results, and if so how the context is established to the recipient (verifier or RP).  

As per https://datatracker.ietf.org/doc/html/draft-ietf-rats-tpm-based-network-device-attest-12#section-1.5, Attestation Results are clearly within scope of the document and are the result of a verifier matching attestation evidence against an appraisal policy ("Finally, Appraisal of Evidence occurs.  This is the process of verifying the Evidence received by a Verifier from the Attester, and using an Appraisal Policy to develop an Attestation Result, used to inform decision making.")

There is a discussion on the PCR maps used in conveyance of attestation evidence in https://datatracker.ietf.org/doc/html/draft-ietf-rats-tpm-based-network-device-attest-12#section-2.1.  But as per https://datatracker.ietf.org/doc/html/draft-ietf-rats-tpm-based-network-device-attest-12#section-3.1.3:  "While there must be an Appraisal Policy, this document does not specify the format or mechanism to convey the intended policy, nor does RIV specify mechanisms by which the results of applying the policy are communicated to the Relying Party.".  

So I guess the verifier could convey the straight PCR map (attestation evidence) to the RP along with a Boolean value describing whether the evidence met the appraisal policy. Or maybe the verifier could send a thumb's-up emoji to the RP and that could be a possible attestation result.  The document does not prohibit either approach. And the document provides no guidance on how to distinguish context when evidence is reflected in results.

So should draft-ietf-rats-tpm-based-network-device-attest be withdrawn from IESG review until the draft clearly defines how attestation results are formed and when a pass through of evidence is acceptable?  Or would be EAT be better off replacing the existing text in https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat#section-1.3.2 and staying silent on how evidence is reflected in results (e.g. passthrough of claims, pass/fail indication, conveying attestation results as an EAT)?  At very least it would be nice to establish consistency among the documents produced by the WG.

-Giri

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Henk Birkholz
Sent: Wednesday, February 23, 2022 12:50 PM
To: Laurence Lundblade <[email-masked]>; Eric Voit (evoit) <[email-masked]>
Cc: [email-masked]; Smith, Ned <[email-masked]>
Subject: Re: [Rats] Same claim in Evidence and Results (was Re: Second attempt at early allocation of CWT Labels (PR #152))

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

Hi Laurence,

Viele Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 24 Feb 2022 00:36:52 +0100

Hi Giri,

the second clause "While there must be an Appraisal Policy, this 
document does not specify the format or mechanism to convey the intended 
policy, nor does RIV specify mechanisms by which the results of applying 
the policy are communicated to the Relying Party." is not intended to 
circumvent or conflict with the axiom that is "Finally, Appraisal of 
Evidence occurs. This is the process of verifying the Evidence received 
by a Verifier from the Attester, and using an Appraisal Policy to 
develop an Attestation Result, used to inform decision making.".

In consequence, I disagree with your statement that: "So I guess the 
verifier could convey the straight PCR map (attestation evidence) to the 
RP along with a Boolean value describing whether the evidence met the 
appraisal policy.". I think that is simply incorrect.

I am under the impression that my assessment is also reflected by the 
RATS architecture very precisely: Evidence does not go to the Relying 
Party. I am pretty sure that every arch i-d editor will agree with me 
instantly here. If you still want to do a "pass-through" that has to be 
annotated very precisely in the corresponding nested RATS conceptual 
message AND you need a Verifer role co-located on the entity that takes 
on the role of a Relying Party - so pass-through evidence can be 
appraised by that Entity.

The only wriggle room I can see here are statements about freshness, 
which you could use an Attesting Environment for to produce them, and 
these could be included in AR, while they technically they could be 
interpreted as Evidence. I think that flexibility is intentionally baked 
into the architecture, as freshness is a complex topic and you need 
every help to support that.

I am pretty confident that I am correct.

Still, I'd welcome any arguments why I am stating that incorrectly.

Viele Grüße,

Henk

---

From: Giridhar Mandyam <[email-masked]>
Date: Thu, 24 Feb 2022 00:20:45 +0000

> In consequence, I disagree with your statement that: "So I guess the verifier could convey the straight PCR map (attestation evidence) to the RP along with a Boolean value describing whether the evidence met the appraisal policy.". I think that is simply incorrect.

The above examples were tongue-in-cheek.  My point was that the spec was not definitive on the format or presentation of attestation results, and therefore conveyance of evidence in attestation results is not expressly prohibited.  Granted, maybe the bar for defining interoperability is lower because this doc is Informational rather than Standards-Track.

> I am under the impression that my assessment is also reflected by the RATS architecture very precisely: Evidence does not go to the Relying Party. I am pretty sure that every arch i-d editor will agree with me instantly here. If you still want to do a "pass-through" that has to be annotated very precisely in the corresponding nested RATS conceptual message AND you need a Verifer role co-located on the entity that takes on the role of a Relying Party - so pass-through evidence can be appraised by that Entity.

Please cite the appropriate section(s) in the arch. doc.  I tried looking into https://datatracker.ietf.org/doc/html/draft-ietf-rats-architecture#section-8.4 for the annotation requirement and couldn't find one. I also have another question:  given that the RP and verifier have a trusted relationship where their roles are clearly identified, wouldn't context be established by inference?  In other words, any information that the verifier conveys to the RP should be considered as being distinct from evidence as conveyed by the attester, even if said information contains claims that originated from the attester.

> The only wriggle room I can see here are statements about freshness, which you could use an Attesting Environment for to produce them, and these could be included in AR, while they technically they could be interpreted as Evidence. I think that flexibility is intentionally baked into the architecture, as freshness is a complex topic and you need every help to support that.

Not sure I understand how this relates to pass through evidence.  Freshness is meaningful to the RP when it originates the challenge data and can verify the signature over it.  If the verifier is the source of the challenge then I am not sure how freshness is meaningful for pass through results.  

-----Original Message-----
From: Henk Birkholz <[email-masked]> 
Sent: Wednesday, February 23, 2022 3:37 PM
To: Giridhar Mandyam <[email-masked]>; Laurence Lundblade <[email-masked]>; Eric Voit (evoit) <[email-masked]>
Cc: [email-masked]; Smith, Ned <[email-masked]>
Subject: Re: [Rats] Same claim in Evidence and Results (was Re: Second attempt at early allocation of CWT Labels (PR #152))

Hi Giri,

the second clause "While there must be an Appraisal Policy, this document does not specify the format or mechanism to convey the intended policy, nor does RIV specify mechanisms by which the results of applying the policy are communicated to the Relying Party." is not intended to circumvent or conflict with the axiom that is "Finally, Appraisal of Evidence occurs. This is the process of verifying the Evidence received by a Verifier from the Attester, and using an Appraisal Policy to develop an Attestation Result, used to inform decision making.".

In consequence, I disagree with your statement that: "So I guess the verifier could convey the straight PCR map (attestation evidence) to the RP along with a Boolean value describing whether the evidence met the appraisal policy.". I think that is simply incorrect.

I am under the impression that my assessment is also reflected by the RATS architecture very precisely: Evidence does not go to the Relying Party. I am pretty sure that every arch i-d editor will agree with me instantly here. If you still want to do a "pass-through" that has to be annotated very precisely in the corresponding nested RATS conceptual message AND you need a Verifer role co-located on the entity that takes on the role of a Relying Party - so pass-through evidence can be appraised by that Entity.

The only wriggle room I can see here are statements about freshness, which you could use an Attesting Environment for to produce them, and these could be included in AR, while they technically they could be interpreted as Evidence. I think that flexibility is intentionally baked into the architecture, as freshness is a complex topic and you need every help to support that.

Viele Grüße,

Henk

On 24.02.22 00:26, Giridhar Mandyam wrote:
> As per 
> https://datatracker.ietf.org/doc/html/draft-ietf-rats-tpm-based-networ
> k-device-attest-12#section-1.5, Attestation Results are clearly within 
> scope of the document and are the result of a verifier matching 
> attestation evidence against an appraisal policy ("Finally, Appraisal 
> of Evidence occurs.  This is the process of verifying the Evidence 
> received by a Verifier from the Attester, and using an Appraisal 
> Policy to develop an Attestation Result, used to inform decision 
> making.")
>
> Subject: Re: [Rats] Same claim in Evidence and Results (was Re: Second 
> attempt at early allocation of CWT Labels (PR #152))
>

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 24 Feb 2022 07:57:26 +0100

Hi Giri,

> The above examples were tongue-in-cheek.  My point was that the spec was not definitive on the format or presentation of attestation results, and therefore conveyance of evidence in attestation res…

Yes, conveyance of Evidence in Attestation Results is not prohibited. 
That does not imply that you can just "mix the corresponding Claims" so 
that it is not clear anymore which Claims are produced by the Attester 
and which Claims are produced by the Verifier. The "buckets" these 
Claims are in must stay intact - if not via encoding, then via other means.

> Please cite the appropriate section(s) in the arch. doc.  I tried looking into https://datatracker.ietf.org/doc/html/draft-ietf-rats-architecture#section-8.4 for the annotation requirement and coul…

Simplest section to point to is Section 3 (that also includes a very 
clear Figure 1):

> The Attester role is assigned to entities that create Evidence that is conveyed to a Verifier.

and

> Subsequently, the Verifier role generates Attestation Results for use by Relying Parties.

Then, Section 4 is very explicit again on what each role does.

Attester:

> Produces: Evidence

Verifier:

> Consumes: Evidence, Reference Values, Endorsements, Appraisal Policy for Evidence
> Produces: Attestation Results

Relying Party:

> Consumes: Attestation Results, Appraisal Policy for Attestation Results

As the Relying Party is not consuming Evidence and also does not consume 
Appraisal Policy for Evidence, it is obviously not suited to understand 
that Claims it receives are not Attestation Results produced by a Verifier.

A place in the Architecture where "pass-through of Evidence" is 
described is:

> https://www.ietf.org/archive/id/draft-ietf-rats-architecture-15.html#name-background-check-model

Here, Evidence is relayed to a Verifier by a Relying Party and it is 
made very clear that the Relying Party "treats it as opaque and simply 
forwards it on to a Verifier.". In this case the Verifier can be certain 
that the Claim's origin is always an Attester - there is no confusion 
about Claim origin. That's the point.

Now - you can co-locate the roles of Verifier and Relying Party on one 
entity. Still the "Evidence nested in Attestation Results" must be:

a.) clearly separated from each other; and
b.) addressed to the corresponding role taken on by the entity

If you do not make that clear in the message layout (in this case EAT), 
the receiving entity that is both a Relying Party and a Verifier cannot 
be certain where each Claim originates from and they cannot be address 
to the dedicated roles taken on by the entity.

> Not sure I understand how this relates to pass through evidence.  Freshness is meaningful to the RP when it originates the challenge data and can verify the signature over it.  If the verifier is t…

Challenge Response Remote Attestation (CHARRA) is just one interaction 
model to convey conceptual messages. There are others. In the 
architecture, that is discussed in Appendix A that lists eleven events 
that relate to the assessment of freshness and presents five selected 
examples (out of many) to illustrate when these events become relevant 
for the assessment of freshness:

> https://www.ietf.org/archive/id/draft-ietf-rats-architecture-15.html#name-appendix-a-time-considerati

Viele Grüße,

Henk

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 24 Feb 2022 12:43:32 -0800

Reviewed all the EAT claims in the light of this discussion and would like to try for this distinction:

Claim Semantics
I think we can define semantics precisely for claims in a way that doesn’t vary by context.

A UEID is always the UEID of the target device of the attestation. Same for SUEID, HW OEM ID, HW Model, HW Version, uptime, boot seed. Probably also SW name, version, manifests and evidence (CoWIDS).

I believe we can clearly lock these definitions down in EAT in way that they are invariant by context.

Claim Trustworthiness
Each of the above-mentioned claims may be more or less trustworthy depending on how the Attester and Verifier are implemented. 

A UEID always identifies the target device, but may be very easy to attack and for some Attesters and not for others. Ease of attack is roughly the same as trustworthiness.

Similarly, a location may be easier to spoof on some device and with some Verifiers than others. Maybe the Android location debug is enabled, maybe the location comes from TrustZone. Maybe the Verifier does a sanity check based on cellular triangulation. But the location claim is still the location of the device, the semantics haven’t changed.

Every claim has varying trust. There is no such thing as a perfectly trustable claim that can never be attacked.

Just because the trust in a claim varies doesn’t mean its semantics are variable. We can still lock down semantics.

I believe EAT should NOT define claim trustworthiness. It should steer very far away from trustworthiness.

EAT Meta Data
Some claims are EAT meta data and not about the device: profile and intended use. These are fine in either evidence or results as they always refer to the EAT they immediately occur in.

Nonce
This is an interesting one. Multiple nonces are allowed in EAT. As and RP, you can always tell which is the nonce you sent because you remember it. You may not know if the nonce went all the way to the device and was signed in Evidence. Maybe some more thinking and text is needed here.

Driving a wedge between claim semantics and claim trustworthiness, I don’t see a need to use name spaces or such in EAT to distinguish a claim in evidence from a claim in results.
 - The claim has the same semantics whether they are in evidence or results
 - EAT is silent about their trustworthiness because there is no practical way to characterize it

Almost all EAT claims will not have a definition that is conditional on the context. If an EAT claim does vary by context, there is probably something wrong with its conception or definition.

(There are also claims that define attestation results; we can discuss them in another thread).

LL

> On Feb 23, 2022, at 2:01 PM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Laurence,
> 
> now I am confused :-) I thought the topic is believable Claim provenance and not level of trustworthiness. Maybe I should not have stated the obvious: that a relying party maintains trust relationships to Verifiers. That might just have been distracting.
> 
> I am not commenting on any trustworthiness levels. I solely commenting on the "origin" part that is about the provenance of claims processed by remote attestation procedures (literally, that's why it's RATS).
> 
> Instead I let others comment on the feasibility of trustworthiness levels in AR :-)
> 
> It also feels like I have to point out now that "structuring your Evidence and AR well, so you are not confused by the origin of their contents" and "introducing a concise taxonomy for attestation results in the form of a trustworthiness vectors" are separate different things :-)
> 
> So personally, I am steering clear from "verification level" in the context of EAT as that seems to overload the scope of the EAT space quite a bit, but I am very in favor of improve on the "origin" part.
> 
> Viele Grüße,
> 
> Henk
> 
>

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 24 Feb 2022 22:03:01 +0100

Hi Laurence,

comments in-line.

On 24.02.22 21:43, Laurence Lundblade wrote:
> _Claim Semantics_
> A UEID is always the UEID of the target device of the attestation. Same 
> for SUEID, HW OEM ID, HW Model, HW Version, uptime, boot seed. Probably 
> also SW name, version, manifests and evidence (CoWIDS).
> 

Not sure how you intend to pull that off, but I am most definitely in 
favor of a simple solution. I'll stay tuned.

> 
> 
> _Claim Trustworthiness_
> Each of the above-mentioned claims may be more or less trustworthy 
> depending on how the Attester and Verifier are implemented.
> 
> A UEID always identifies the target device, but may be very easy to 
> attack and for some Attesters and not for others. Ease of attack is 
> roughly the same as trustworthiness.
> 
> Similarly, a location may be easier to spoof on some device and with 
> some Verifiers than others. Maybe the Android location debug is enabled, 
> maybe the location comes from TrustZone. Maybe the Verifier does a 
> sanity check based on cellular triangulation. But the location claim is 
> still the location of the device, the semantics haven’t changed.
> 
> Every claim has varying trust. There is no such thing as a perfectly 
> trustable claim that can never be attacked.
> 
> Just because the trust in a claim varies doesn’t mean its semantics are 
> variable. We can still lock down semantics.
> 

I agree with respect to Evidence. The policies for appraisal of Evidence 
might yield a different picture, though. To build on you example, 
certain Endorsements for a type of Attester might inform a Verifier via 
corresponding policy not to take an UEID at face value, as the Attester 
is known to be spoof-able. That's a policy decision and therefore any 
statements about that topic must originate from the Verifier and only 
belong into Attestation Results.

> 
> 
> _EAT Meta Data_
> Some claims are EAT meta data and not about the device: profile and 
> intended use. These are fine in either evidence or results as they 
> always refer to the EAT they immediately occur in.

Are these intended to be used to distinguish conceptional messages, too? 
I am under the impression that the I-D does not say anything about that, 
but maybe I am reading it wrong.

> 
> 
> _Nonce_
> This is an interesting one. Multiple nonces are allowed in EAT. As and 
> RP, you can always tell which is the nonce you sent because you remember 
> it. You may not know if the nonce went all the way to the device and was 
> signed in Evidence. Maybe some more thinking and text is needed here.
> 

Why should a Relying Party send a nonce to an Attester? Or is the 
Verifier intended to re-use that nonce for its own challenge-response 
remote attestation interaction? I assume that "the device" is "the 
Attester", but I cannot be sure. Also, neither the Background-Check 
model, nor the Passport model initiate retrieval via the Relying Party 
directly, but that might be a simplification issue and not a problem.

> 
> 
> Driving a wedge between claim semantics and claim trustworthiness, I 
> don’t see a need to use name spaces or such in EAT to distinguish a 
> claim in evidence from a claim in results.
> Almost all EAT claims will not have a definition that is conditional on 
> the context. If an EAT claim does vary by context, there is probably 
> something wrong with its conception or definition.

I wonder why the trustworthiness issue is coming up again and again, 
while that is contained to Attestation Results and I think we agree that 
it is not covered by the EAT I-D. Yet, the differentiation between 
Claims in different conceptual messages ("conditional on context") 
remains to be bit of a neglected topic. In the meantime, I start to be 
under impression that that is the actual, real problem with the Claim 
definitions between -09 and -11(12).

> (There are also claims that define attestation results; we can discuss 

Now I am confused. All the Claims discussed are not for Attestation 
Results? I am surely missing something here.

Viele Grüße,

Henk

> 
> 
>> On Feb 23, 2022, at 2:01 PM, Henk Birkholz 
>> now I am confused :-) I thought the topic is believable Claim 
>> provenance and not level of trustworthiness. Maybe I should not have 
>> stated the obvious: that a relying party maintains trust relationships 
>> to Verifiers. That might just have been distracting.
>>
>> on the "origin" part that is about the provenance of claims processed 
>> by remote attestation procedures (literally, that's why it's RATS).
>>
>> contents" and "introducing a concise taxonomy for attestation results 
>> in the form of a trustworthiness vectors" are separate different 
>> things :-)
>>
>>>> On Feb 23, 2022, at 12:50 PM, Henk Birkholz 
>>>> while that is a crude way to do it, I guess, it would address some 
>>>> of the problem, I think. If you would find “evidence.location” in 
>>>> AR, then you at least know it was a pass-through and not the output 
>>>> of an appraisal procedure. You'd still not know what that means to 
>>>> you as you are not necessarily aware of the the semantics of the 
>>>> Evidence, but at least you can choose to ignore it, as you might 
>>>> only trust the Verifier's AR and not the Attester's Evidence.
>>>>
>>> And I also said I think this is probably not a good thing to do 
>>> because there is so much variance in the level of trustworthiness for 
>>> claim from an Attester and in cross-checking a Verifier can do on it.
>>> I don’t really think it is possible to write down in an IETF standard 
>>> the broad range of trustworthiness levels a claim might have in all 
>>> the contexts.
>>> But if we were to try, what do you think about something like an 
>>> Attestation Results claim that tells you something about the origin 
>>> and Verifier processing of each claim in the AR? For example it would 
>>> tell you these about each claim in the AR:
>>>   - verification level - authenticated, authenticated and confirmed 
>>> to be in expected range (what ever that is), ?

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 24 Feb 2022 13:48:08 -0800

> On Feb 24, 2022, at 1:03 PM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Laurence,
> 
> comments in-line.
> 
> Not sure how you intend to pull that off, but I am most definitely in favor of a simple solution. I'll stay tuned.

I haven’t done the fine-toothed comb review of all the claims yet for this, but will.

Would be really helpful if others also did a review of the claims for any possible variance in semantics between results and evidence. :-)

> I agree with respect to Evidence. The policies for appraisal of Evidence might yield a different picture, though. To build on you example, certain Endorsements for a type of Attester might inform a Verifier via corresponding policy not to take an UEID at face value, as the Attester is known to be spoof-able. That's a policy decision and therefore any statements about that topic must originate from the Verifier and only belong into Attestation Results.

Yes, other RATS documents may define trustworthiness characteristics of claims, claims about trustworthiness and such to go into Attestation Results. Most EAT claim definitions will be neutral about trustworthiness. That doesn’t mean that EAT can’t be used as a format for encoding, securing and conveying Attestation Results. More below.

(Also, the UEID and every other claim is always spoofable in every implementation and for both Evidence and Results. It’s just a matter of degree.) 

> Are these intended to be used to distinguish conceptional messages, too? I am under the impression that the I-D does not say anything about that, but maybe I am reading it wrong.

EAT doesn’t have anything that indicates conceptual message. Seems like you will always know by context and it is not necessary, but maybe we want to add something? 

> Why should a Relying Party send a nonce to an Attester? Or is the Verifier intended to re-use that nonce for its own challenge-response remote attestation interaction? I assume that "the device" is "the Attester", but I cannot be sure. Also, neither the Background-Check model, nor the Passport model initiate retrieval via the Relying Party directly, but that might be a simplification issue and not a problem.

I admit I haven’t thought that all through. Lots of other people were very interested nonces so I didn’t think I needed to. Note that EAT does allow for multiple nonces. Happy to defer on this one.

> I wonder why the trustworthiness issue is coming up again and again, while that is contained to Attestation Results and I think we agree that it is not covered by the EAT I-D.

I see EAT as a base format for both Evidence and Results. It has the necessary characteristics to represent Results well. Fewer formats in RATS are is better.

Lots of claims will be defined for EAT outside of the EAT document. I expect many of them to be for Attention Results.

> Yet, the differentiation between Claims in different conceptual messages ("conditional on context") remains to be bit of a neglected topic.

Just wrote did some analysis of claims in regards to this and wrote a thoughtful and helpful message about it. I have promised further review. Maybe we should have figured that out six months ago, but that doesn’t mean it is currently neglected.

> In the meantime, I start to be under impression that that is the actual, real problem with the Claim definitions between -09 and -11(12).

I really don’t see a big problem here. Maybe some wording adjustments are needed in light of this, but I don’t think there is general problem.  Most EAT claims are just definitions of semantics and always have been.

Maybe after -09 you realized that I intended EAT to used for Attestation Results? 

> Now I am confused. All the Claims discussed are not for Attestation Results? I am surely missing something here.

EAT defines a few claims that are oriented to Attestation Results (swresults, DLOAs) and as I said above, I think EAT is a good format to express AR. Others even agree with me.

LL

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 24 Feb 2022 22:58:29 +0100

Hi Laurence,

it is starting to get late on my side of the globe that is close to... a 
disconcerting event.

So I am gonna focus on just two related items for now:

and you also say this:

> EAT doesn’t have anything that indicates conceptual message.

then you are confusing the heck out of me, because that is literally 
contradicting yourself (I think) and I do not know how to deal with that 
today anymore :-) No offense, I am just tired (by many things).

Please align your Claims with just one intended conceptual message they 
should appear in. Or find another cool solution that facilitates that. 
Or please clearly elaborate how that is not totally confusing to the 
consuming roles of conceptual messages more, so we can have a targeted 
discussion.

Viele Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 24 Feb 2022 23:16:38 +0100

Sorry, I can't help it. One more comment.

> (Also, the UEID and every other claim is always spoofable in every implementation and for both Evidence and Results. It’s just a matter of degree.)

I have no idea how to constructively reply to this. That is a 
contradiction to all what Remote Attestation Procedures are about. To 
quote the architecture:

> In Remote Attestation Procedures (RATS), one peer (the "Attester") produces believable information about itself - Evidence - to enable a remote peer (the "Relying Party") to decide whether to consider that Attester a trustworthy peer or not. RATS are facilitated by an additional vital party, the Verifier.

If you assume, an Attester always produces Claims that can be spoofed 
(aka are not believable information about itself in principle), I think 
you are not doing RATS.

I am probably not comprehending your statement coherently, but... what?

Viele Grü0e,

Henk

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 24 Feb 2022 14:50:43 -0800

On Feb 24, 2022, at 2:16 PM, Henk Birkholz <[email-masked]> wrote:
> I have no idea how to constructively reply to this. That is a contradiction to all what Remote Attestation Procedures are about. To quote the architecture:
> 
> If you assume, an Attester always produces Claims that can be spoofed (aka are not believable information about itself in principle), I think you are not doing RATS.

This is about degree and ease of attack. It is spoofable because every computer or system is attackable, but probably not easily because of all the security in the RATS implementation.

I generally oppose use of absolute language that implies something is “secure", “believable" or “trustworthy" because nothing is every completely so. We need to assume there is always an attacker with a big budget (The United States Government). I kind of stopped using the adjective “secure” a decade ago.

One of the reasons I take this tack is that I want to be sure RATS is for low-security implementations too. No security in RATS (or most of the IETF) should be viewed as binary, as either secure or non-secure. This is particularly true of RATS because the device is often physically in the hands of the attacker. That is not usually true for user authentication or service authentication (TLS).

HW, TPM’s, Secure Elements and such have pretty good security, but they can be attacked. The attack might be on the manufacturing infrastructure, the factory, the private key management, the Verifier’s operations, the cloud the Verifier runs on... so it’s not just the Attester.

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 25 Feb 2022 12:54:36 -0800

Trying for some examples. They are written in JSON without the JWT wrapper so they are easy to read.

First attestation evidence with a CoSWID measurement. The CoSWID is B64 wrapped CBOR. What’s important here is that there are measurements in the evidence, not the format or type of the measurements.
  {
       "OEMID" : "iUWt",
       "UEID" : "AZj1Ck/2wFhhyIYNE6Y4",
       "swevidence": “8sf7xls8kd99s8lc87sd…."
  }

Next, here’s attestation results. The representation of the result is in the EAT swresults claim, but they could be ar4si too. What’s important is that there are claims describing results of verification.
  {
       "OEMID" : "iUWt",
       "UEID" : "AZj1Ck/2wFhhyIYNE6Y4",
       "swresults" : [
            [
                "Trustus Verifications",
                "all",
                "fully-verified"
            ]
       ]
   }

The RP knows that they are getting attestation results because they accessed the Verifier API that only provides attestation results. They know that it’s not attestation evidence because that API doesn’t provide attestation evidence. 

If we wanted to be doubly sure there’s no mix up with conceptual messages, then we could invent a MessageType claim.
    {
       "OEMID" : "iUWt",
       "UEID" : "AZj1Ck/2wFhhyIYNE6Y4",
       "swevidence": “8sf7xls8kd99s8lc87sd….”
       “MessageType” : “Attestation Evidence"
  }

and
    {
       "OEMID" : "iUWt",
       "UEID" : "AZj1Ck/2wFhhyIYNE6Y4",
       "swresults" : [
            [
                "Trustus Verifications",
                "all",
                "fully-verified"
            ]
       ]
       “MessageType” : “Attestation Results"
  }

EAT doesn’t have an a MessageType claim now. It can still be the format for attestation results even if it doesn’t have an explicit indicator of conceptual message.

I hope that shows why there is no contradiction.

To go further, if a Verifier received an evidence EAT with the swresults or ar4si claims, it should kick it out in error.

Similarly, if the RP received an EAT with the swevidence claim, it should kick it out in error, or ignore the claim, or error out because there was no swresults or ar4si claims.

Maybe there are some use cases where it is easy to mix up EATs that are attestation results with ones that are attestation evidence. If so, then we probably would want to define a MessageType claim.

LL

> On Feb 24, 2022, at 1:58 PM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Laurence,
> 
> it is starting to get late on my side of the globe that is close to... a disconcerting event.
> 
> then you are confusing the heck out of me, because that is literally contradicting yourself (I think) and I do not know how to deal with that today anymore :-) No offense, I am just tired (by many things).
> 
> Please align your Claims with just one intended conceptual message they should appear in. Or find another cool solution that facilitates that. Or please clearly elaborate how that is not totally confusing to the consuming roles of conceptual messages more, so we can have a targeted discussion.
> 
> Viele Grüße,
> 
> Henk
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 25 Feb 2022 23:55:31 +0000

Hi Laurence,

From: Laurence Lundblade, February 25, 2022 3:55 PM

  {
       "OEMID" : "iUWt",

  {
       "OEMID" : "iUWt",

<eric>  I hadn’t noticed "Trustus Verifications" in EAT before. This term first appears in EAT v11 Appendix A.6.  I think it is the name of an example Verifier?   If that is the case, shouldn't you have the Verifier making the assertion to span/sign *all* the Attestation Results which it is asserting?  I.e., the signature and identity need to be on the outside of all the Attestation Results asserted. For example, the UEID does not necessarily prove the make and manufacturer of the Attester.  These verifying any such claims should also be signed by the same Verifier as it will affect the treatment below by the RP policy.   (Unless that information has been previously asserted and cached.)  

Side question: can the swresult claim vary in scope of software evaluated?  I.e., can it sometimes be used for one element of code in one context, but the entire system in another?  I thought I saw slides in an earlier IETF that showed individual files could have a "swresult".  In that case it would be necessary to define structures for the domain of software which applied for a particular AR.  (E.g., when "6-partial" is asserted.)

I don't think the two points above are academic as the RP needs to be able to parse the AR received with sufficient assuredness that it can apply the appropriate policy.  Scanning for claim names within a JSON blob will not get you there.

    {

       "OEMID" : "iUWt",

and

    {

       "OEMID" : "iUWt",

<eric> A MessageType might be a good idea, whether it is a claim or simply something which indicates it was generated by a Verifier about an Attester.   

Building on that I am a believer in simplicity, and that only a very few new things need be asserted by a Verifier.  (I.e., the Verifier should generate very little new claim/information.  But that it can certainly copy claims originally from an Attester and include them within the signed AR the inputs behind the conclusions which it is actually vouching for.) 

Eric

 

LL

 

On Feb 24, 2022, at 1:58 PM, Henk Birkholz <[email-masked] <mailto:[email-masked]> > wrote:

Hi Laurence,

See - when you say this:

and you also say this:

Viele Grüße,

Henk

On Feb 24, 2022, at 1:03 PM, Henk Birkholz <[email-masked] <mailto:[email-masked]> > wrote:

Hi Laurence,

comments in-line.

_Claim Trustworthiness_

_EAT Meta Data_

_Nonce_

---

From: Thomas Fossati <[email-masked]>
Date: Sat, 26 Feb 2022 11:53:34 +0000

Just a small note:

> If we wanted to be doubly sure there’s no mix up with conceptual messages, then we could invent a MessageType claim.

This is probably not necessary: the profile claim seems fit for purpose.

cheers,
-- 
Thomas