Subject: Re: [Rats] UEID where an instance is a group member

From: "Smith, Ned" <[email-masked]>
Date: Wed, 25 Mar 2020 16:29:34 +0000

Is a GEID structurally different from a EUID? I think currently a EUID is either a 128-bit or 256-bit bstr. I assume the semantics of uniqueness differ.

From: RATS <[email-masked]> on behalf of Simon Frost <[email-masked]>
Date: Wednesday, March 25, 2020 at 8:47 AM
To: Laurence Lundblade <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Rats] UEID where an instance is a group member

We had an internal discussion in response to some changes in PSA which have elaborated the definition of an Instance Attestation Key (IAK) so that it may either be “unique to each device or a collection of identical devices”. The definition of the Identity claim is now a value that identifies the IAK. This has been done to support entity grouping for (some) privacy scenarios.

While we have an EAT Profile for PSA that uses a full set of custom claims, our intent has always been to be to migrate as many claims as possible to the standard once the RATS work is complete. Previously, there has been a direct analogy between arm_psa_UEID and the standard UEID. With this change though, we would have to move away from this. The current description of UEID makes it clear that it must be device world unique. There is some discussion (https://ietf-rats-wg.github.io/eat/draft-ietf-rats-eat.html#name-ueid-privacy-considerations) of the group scenario, but the only statement about the claim situation is that “It will often be the case that tokens will not have a UEID for these reasons”.

In the privacy scenario, it is still desirable to have an entity identity claim, for use by a verifier or for general usage. The options seem to be:

a/ If the entity is unique, include an UEID claim, otherwise include a custom group claim. It seems a pity to encourage diversification between profiles.

b/ If the entity is unique, include an UEID claim, otherwise use a new standard GEID claim

c/ punt this problem out to the kid of the COSE wrapper. This would ignore any more general uses of group identities.

Of these, b/ (introduce a new standard GEID claim) seems to make the most sense and is the option we would propose to the WG.

Thoughts?

Thanks
Simon

Simon Frost
Senior Principal Systems Solution Architect, ATG, Arm
Mob: +44 7855 265691

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: Laurence Lundblade <[email-masked]>
Date: Wed, 25 Mar 2020 09:46:46 -0700

A GEID of similar structure to a UEID  seems like a possibility, but what exactly is purpose of such a GEID? What does the RP do with it? What does the verifier do with it?

An RP will use the UEID to track the unique, specific device. That is its clearly stated purpose.

In some designs, a verifier may use the UEID to identify the verification key, but that is not the UEID’s purpose. It a useful side-effect.

If the purpose of a GEID is solely for the verifier to identify the verification key, then I don’t think it is should be a GEID. It should be key id.

So for me this kind of hinges on what a GEID will mean for the RP. What are the groupings it gives and how are they meaningful to an RP?

LL

> On Mar 25, 2020, at 9:29 AM, Smith, Ned <[email-masked]> wrote:
> 
> While we have an EAT Profile for PSA that uses a full set of custom claims, our intent has always been to be to migrate as many claims as possible to the standard once the RATS work is complete. Previously, there has been a direct analogy between arm_psa_UEID and the standard UEID. With this change though, we would have to move away from this. The current description of UEID makes it clear that it must be device world unique. There is some discussion (https://ietf-rats-wg.github.io/eat/draft-ietf-rats-eat.html#name-ueid-privacy-considerations <https://ietf-rats-wg.github.io/eat/draft-ietf-rats-eat.html#name-ueid-privacy-considerations>) of the group scenario, but the only statement about the claim situation is that “It will often be the case that tokens will not have a UEID for these reasons”.
>

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 25 Mar 2020 17:54:28 +0100

Hi Laurence,

potentially, I just realized, it could serve the purpose of matching the 
Authenticator Moodel of a FIDO Authenticator and therefore might help 
the peer that the Atttester is talking to understand the format it has 
to expect being incoming based on the additional input of a FIDO 
Metadata-Service (aka the Authentcator-Model that is called, IIRC?). Any 
structure of that kind would help a Verifier to better... "guess" 
(well.. it probably is the output of some kind of negotiation), whether 
it is, e.g. FIDO or RIV?

Viele Grüße,

Henk

On 25.03.20 17:46, Laurence Lundblade wrote:
> A GEID of similar structure to a UEID  seems like a possibility, but 
> what exactly is purpose of such a GEID? What does the RP do with it? 
> What does the verifier do with it?
> 
> In some designs, a verifier may use the UEID to identify the 
> verification key, but that is not the UEID’s purpose. It a useful 
> side-effect.
> 
> If the purpose of a GEID is solely for the verifier to identify the 
> verification key, then I don’t think it is should be a GEID. It should 
> be key id.
> 
> So for me this kind of hinges on what a GEID will mean for the RP. What 
> are the groupings it gives and how are they meaningful to an RP?
> 
> LL
> 
> 
> 
>> On Mar 25, 2020, at 9:29 AM, Smith, Ned <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Is a GEID structurally different from a EUID? I think currently a EUID 
>> is either a 128-bit or 256-bit bstr. I assume the semantics of 
>> uniqueness differ.
>> *From:*RATS <[email-masked] <mailto:[email-masked]>> on 
>> behalf of Simon Frost <[email-masked] <mailto:[email-masked]>>
>> *Date:*Wednesday, March 25, 2020 at 8:47 AM
>> *To:*Laurence Lundblade <[email-masked] 
>> <mailto:[email-masked]>>, "[email-masked] 
>> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> *Subject:*[Rats] UEID where an instance is a group member
>> We had an internal discussion in response to some changes in PSA which 
>> have elaborated the definition of an Instance Attestation Key (IAK) so 
>> that it may either be “unique to each device or a collection of 
>> identical devices”. The definition of the Identity claim is now a 
>> value that identifies the IAK. This has been done to support entity 
>> grouping for (some) privacy scenarios.
>> While we have an EAT Profile for PSA that uses a full set of custom 
>> claims, our intent has always been to be to migrate as many claims as 
>> possible to the standard once the RATS work is complete. Previously, 
>> there has been a direct analogy betweenarm_psa_UEIDand the standard 
>> UEID. With this change though, we would have to move away from this. 
>> The current description of UEID makes it clear that it must be device 
>> world unique. There is some discussion 
>> (https://ietf-rats-wg.github.io/eat/draft-ietf-rats-eat.html#name-ueid-privacy-considerations) 
>> of the group scenario, but the only statement about the claim 
>> situation is that “It will often be the case that tokens will not have 
>> a UEID for these reasons”.
>> In the privacy scenario, it is still desirable to have an entity 
>> identity claim, for use by a verifier or for general usage. The 
>> options seem to be:
>> a/ If the entity is unique, include an UEID claim, otherwise include a 
>> custom group claim. It seems a pity to encourage diversification 
>> between profiles.
>> c/ punt this problem out to the kid of the COSE wrapper. This would 
>> ignore any more general uses of group identities.
>> Of these, b/ (introduce a new standard GEID claim) seems to make the 
>> most sense and is the option we would propose to the WG.
>> Thoughts?
>> Thanks
>> Simon
>> Simon Frost
>> 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]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 25 Mar 2020 17:39:22 +0000

Hi Laurence,

> What does the verifier do with it?

[ copy-pasted+edited from a bit of an internal discussion ]

The idea is that a clear split between unique v group identity would
serve as a hint to the relying party and the verifiers about the nature
of the token, which might affect how they proceed with the overall
protocol.  What exactly they will end up doing with that information is
context specific, the relevant thing here is that they will be given a
way to clearly distinguish the two cases.
--

---

From: Simon Frost <[email-masked]>
Date: Wed, 25 Mar 2020 17:43:50 +0000

The immediately obvious use for a verifier is in key identification but it need not be limited to that. Off the top of my head I could imagine that an RP could perhaps use a GEID to be able to identify a device type that receives some trustworthy stance.

I’m not sure we can or should predict all uses up front, but in terms of being a potentially useful data item that could be used in policy evaluation, having a consistent manner to establish identity seems useful

Cheers
Simon
From: Laurence Lundblade <[email-masked]>
Sent: 25 March 2020 16:47
To: Smith, Ned <[email-masked]>
Cc: Simon Frost <[email-masked]>; [email-masked]
Subject: Re: [Rats] UEID where an instance is a group member

LL

On Mar 25, 2020, at 9:29 AM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

From: RATS <[email-masked]<mailto:[email-masked]>> on behalf of Simon Frost <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 25, 2020 at 8:47 AM
To: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Rats] UEID where an instance is a group member

Thoughts?

Thanks
Simon

Simon Frost

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 25 Mar 2020 18:34:02 +0000

It seems the purpose for using group ID (GEID) instead of a device ID (UEID) is for privacy reasons. UEIDs can be used to track device instance. This violates the pseudonymity/unlinkability requirement (https://tools.ietf.org/html/rfc6973#page-18). Therefore, if the device is operating in a privacy protected mode it might opt to use a GEID instead of a UEID as its identity claim/evidence. 

Keep in mind that keyID is also potentially privacy sensitive. Therefore, the keyID in privacy sensitive mode should refer to a privacy preserving / group key. For example, in FIDO there is support for DAA keys (I think?). 

The use of identifier claims and key IDs should be consistent with the privacy protection requirements. Either GEID is a privacy preserving equivalent to UEID (and a group attestation key is used to attest when in privacy protected modes). Or key IDs double as identifiers which seems to suggest UEID and GEID are unnecessary. 

However, since a device may have multiple keys over its lifetime (and therefore multiple key IDs) the value of identifiers (UEID / GEID) being distinct from key IDs is that the device / group identity persists even though keys are revoked/replaced/refreshed.

-Ned

On 3/25/20, 9:55 AM, "RATS on behalf of Henk Birkholz" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Laurence,

    Viele Grüße,
    
    Henk

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 26 Mar 2020 10:35:07 -0700

The claims giving characteristics of the device should really just focus on the characteristics of the device, not the scheme for securing the evidence and results. Seems like overloading could result in trouble. For example, you need to change the grouping scheme because of some manufacturing problem, but you can’t because you are using it to represent some type or model info. Or maybe there’s a proxy necessary for securing attestation evidence. It would be best if it didn’t need to look into and/or modify the claims.

Here’s a few schemes I think are likely to get used to secure evidence and results:
Basic flat per-device public key
Some X.509 hierarchy that may have X.509 certs carried in COSE headers
ECDAA and other variants of DAA that may have other things in COSE headers
Group keys like FIDO, Android and this proposal
Symmetric schemes, either per-device or group
TLS (particularly for attestation results)
Other new crypto protocol...

COSE, JOSE, TLS, CMS and such all provide headers / parameters to carry things like key IDs to make all of these schemes work.

Using UEID for the key ID for per-device keys is probably mostly OK because it is exactly using the semantics of the UEID. There’s not really any overloading.

GEID used for a key ID and something else would be overloading. Better to clearly define separate claims for device types, models and such.

I’d suggest defining a group key ID header for COSE (and JOSE) and using that instead of inventing the GEID claim. It would be even cooler and more useful to write a draft and standardize privacy-preserving attestation signing for COSE. It would be really beneficial for lots of people doing attestation that need to solve the privacy problem. Maybe FIDO and Android would eventually adopt it someday.

If using the group key ID header, you’d leave out the UEID, so the number of bytes transmitted is the same (if you put the UEID in you’d break the privacy preservation).

Keeping claims separate from security header parameters also keeps the SW stack simpler and cleaner. To verify typical COSE:
- Parse the COSE headers to get the key ID and look up the key
- Verify the signature and get the payload
- Decode the sig-checked claims in the payload

If you depend on the claims to verify the signature:
- Decode the COSE structure to get the unverified payload
- Decode the unverified claims to get the key ID and look up the key
- Verify the signature and get the payload
- Decode the sig-checked claims in the payload again

LL

> On Mar 25, 2020, at 11:34 AM, Smith, Ned <[email-masked]> wrote:
>

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 26 Mar 2020 21:58:31 +0000

Laurence,
The point I was making is that EUID and keyID are not always synonymous. In a case where a device only ever has one key, then maybe they are synonymous. Otherwise, they should be treated differently. My assumption is UEID identifies an entity (device) while keyID identifies a key.

A GEID has the same semantics in terms of being an entity identifier (vs. key identifier) only the GEID points to an entity that is pseudonymously named. I agree it might be a useful to write a draft that defines how attestation for privacy sensitivity should be accomplished.

The other observations seems accurate but I don’t see how they relate to the discussion about whether entity identifiers differ from key identifiers.

Thanks,
Ned

From: Laurence Lundblade <[email-masked]>
Date: Thursday, March 26, 2020 at 10:35 AM
To: "Smith, Ned" <[email-masked]>
Cc: Henk Berkholz <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Rats] UEID where an instance is a group member

  *   Basic flat per-device public key
  *   Some X.509 hierarchy that may have X.509 certs carried in COSE headers
  *   ECDAA and other variants of DAA that may have other things in COSE headers
  *   Group keys like FIDO, Android and this proposal
  *   Symmetric schemes, either per-device or group
  *   TLS (particularly for attestation results)
  *   Other new crypto protocol...

LL

On Mar 25, 2020, at 11:34 AM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

-Ned

On 3/25/20, 9:55 AM, "RATS on behalf of Henk Birkholz" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

   Hi Laurence,

   Viele Grüße,

   Henk

An RP will use the UEID to track the unique, specific device. That is
its clearly stated purpose.

LL

On Mar 25, 2020, at 9:29 AM, Smith, Ned <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>> wrote:

*From:*RATS <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> on
behalf of Simon Frost <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
*To:*Laurence Lundblade <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
b/ If the entity is unique, include an UEID claim, otherwise use a new
standard GEID claim

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

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

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

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 26 Mar 2020 18:14:41 -0700

I was trying to make the case that the bits in the secured attestation that the verifier uses to verify the signature (key ID, X.509 cert chain, ECDAA parameters and such) are not always the same as UEID, as a device identifier. Seems like we agree on this, as you say a key ID identifies a key and UEID identifies a device.

I’m quite sure that Simon’s proposal is to use GEID to identify keys. I say it’s find to have such an identifier, but put it in the COSE headers where key IDs should go and just use it as a key ID.

If we want some other thing that is a claim that is for groups of devices, define that separately and say what the purpose and rules for grouping are.

LL

> On Mar 26, 2020, at 2:58 PM, Smith, Ned <[email-masked]> wrote:
> 
> Laurence,
>> On Mar 25, 2020, at 11:34 AM, Smith, Ned <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> It seems the purpose for using group ID (GEID) instead of a device ID (UEID) is for privacy reasons. UEIDs can be used to track device instance. This violates the pseudonymity/unlinkability requirement (https://tools.ietf.org/html/rfc6973#page-18 <https://tools.ietf.org/html/rfc6973#page-18>). Therefore, if the device is operating in a privacy protected mode it might opt to use a GEID instead of a UEID as its identity claim/evidence. 
>> 
>> On 3/25/20, 9:55 AM, "RATS on behalf of Henk Birkholz" <[email-masked] <mailto:[email-masked]> on behalf [email-masked] <mailto:[email-masked]>> wrote:
>> 
>>    Hi Laurence,
>> 
>>>> On Mar 25, 2020, at 9:29 AM, Smith, Ned <[email-masked] <mailto:[email-masked]> 
>>>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>> 
>>>> *From:*RATS <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> on 
>>>> behalf of Simon Frost <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>>>> *To:*Laurence Lundblade <[email-masked] <mailto:[email-masked]> 
>>>> <mailto:[email-masked] <mailto:[email-masked]>>>, "[email-masked] <mailto:[email-masked]> 
>>>> <mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>>>> (https://ietf-rats-wg.github.io/eat/draft-ietf-rats-eat.html#name-ueid-privacy-considerations <https://ietf-rats-wg.github.io/eat/draft-ietf-rats-eat.html#name-ueid-privacy-considerations>) 
>>> [email-masked] <mailto:[email-masked]>
>>    [email-masked] <mailto:[email-masked]>
>>    https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 27 Mar 2020 01:35:02 +0000

What is wrong with using keyID to identify a group key?

From: Laurence Lundblade <[email-masked]>
Date: Thursday, March 26, 2020 at 6:14 PM
To: "Smith, Ned" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Henk Berkholz <[email-masked]>
Subject: Re: [Rats] UEID where an instance is a group member

LL

On Mar 26, 2020, at 2:58 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

Laurence,

Thanks,
Ned

From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 26, 2020 at 10:35 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: [Rats] UEID where an instance is a group member

LL

-Ned

On 3/25/20, 9:55 AM, "RATS on behalf of Henk Birkholz" <[email-masked]<mailto:[email-masked]> on behalf [email-masked]<mailto:[email-masked]>> wrote:

   Hi Laurence,

   Viele Grüße,

   Henk

LL

behalf of Simon Frost <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 27 Mar 2020 10:06:28 +0100

Hi Laurence,

I am having a hard time to follow the discussion. What does "secured 
attestation" mean in this context, an EAT that is Evidence or something 
else? I am really not sure, because I cannot parse your first paragraph.

It could also be an Endorsement, such as a Metadata-Service Certificate?

Viele Grüße,

Henk

On 27.03.20 02:14, Laurence Lundblade wrote:
> I was trying to make the case that the bits in the secured attestation 
> that the verifier uses to verify the signature (key ID, X.509 cert 
> chain, ECDAA parameters and such) are not always the same as UEID, as a 
> device identifier. Seems like we agree on this, as you say a key ID 
> identifies a key and UEID identifies a device.
> 
> I’m quite sure that Simon’s proposal is to use GEID to identify keys. I 
> say it’s find to have such an identifier, but put it in the COSE headers 
> where key IDs should go and just use it as a key ID.
> 
> If we want some other thing that is a claim that is for groups of 
> devices, define that separately and say what the purpose and rules for 
> grouping are.
> 
> LL
> 
> 
> 
>> The point I was making is that EUID and keyID are not always 
>> synonymous. In a case where a device only ever has one key, then maybe 
>> they are synonymous. Otherwise, they should be treated differently. My 
>> assumption is UEID identifies an entity (device) while keyID 
>> identifies a key.
>> A GEID has the same semantics in terms of being an entity identifier 
>> (vs. key identifier) only the GEID points to an entity that is 
>> pseudonymously named. I agree it might be a useful to write a draft 
>> that defines how attestation for privacy sensitivity should be 
>> accomplished.
>> The other observations seems accurate but I don’t see how they relate 
>> to the discussion about whether entity identifiers differ from key 
>> identifiers.
>> Thanks,
>> Ned
>> *From:*Laurence Lundblade <[email-masked] 
>> <mailto:[email-masked]>>
>> *Date:*Thursday, March 26, 2020 at 10:35 AM
>> *To:*"Smith, Ned" <[email-masked] <mailto:[email-masked]>>
>> *Cc:*Henk Berkholz <[email-masked] 
>> <mailto:[email-masked]>>, "[email-masked] 
>> *Subject:*Re: [Rats] UEID where an instance is a group member
>> The claims giving characteristics of the device should really just 
>> focus on the characteristics of the device, not the scheme for 
>> securing the evidence and results. Seems like overloading could result 
>> in trouble. For example, you need to change the grouping scheme 
>> because of some manufacturing problem, but you can’t because you are 
>> using it to represent some type or model info. Or maybe there’s a 
>> proxy necessary for securing attestation evidence. It would be best if 
>> it didn’t need to look into and/or modify the claims.
>> COSE, JOSE, TLS, CMS and such all provide headers / parameters to 
>> carry things like key IDs to make all of these schemes work.
>> Using UEID for the key ID for per-device keys is probably mostly OK 
>> because it is exactly using the semantics of the UEID. There’s not 
>> really any overloading.
>> GEID used for a key ID and something else would be overloading. Better 
>> to clearly define separate claims for device types, models and such.
>> I’d suggest defining a group key ID header for COSE (and JOSE) and 
>> using that instead of inventing the GEID claim. It would be even 
>> cooler and more useful to write a draft and standardize 
>> privacy-preserving attestation signing for COSE. It would be really 
>> beneficial for lots of people doing attestation that need to solve the 
>> privacy problem. Maybe FIDO and Android would eventually adopt it someday.
>> If using the group key ID header, you’d leave out the UEID, so the 
>> number of bytes transmitted is the same (if you put the UEID in you’d 
>> break the privacy preservation).
>> Keeping claims separate from security header parameters also keeps the 
>> SW stack simpler and cleaner. To verify typical COSE:
>>> It seems the purpose for using group ID (GEID) instead of a device ID 
>>> (UEID) is for privacy reasons. UEIDs can be used to track device 
>>> instance. This violates the pseudonymity/unlinkability requirement 
>>> (https://tools.ietf.org/html/rfc6973#page-18). Therefore, if the 
>>> device is operating in a privacy protected mode it might opt to use a 
>>> GEID instead of a UEID as its identity claim/evidence.
>>>
>>> Keep in mind that keyID is also potentially privacy sensitive. 
>>> Therefore, the keyID in privacy sensitive mode should refer to a 
>>> privacy preserving / group key. For example, in FIDO there is support 
>>> for DAA keys (I think?).
>>>
>>> The use of identifier claims and key IDs should be consistent with 
>>> the privacy protection requirements. Either GEID is a privacy 
>>> preserving equivalent to UEID (and a group attestation key is used to 
>>> attest when in privacy protected modes). Or key IDs double as 
>>> identifiers which seems to suggest UEID and GEID are unnecessary.
>>>
>>> However, since a device may have multiple keys over its lifetime (and 
>>> therefore multiple key IDs) the value of identifiers (UEID / GEID) 
>>> being distinct from key IDs is that the device / group identity 
>>> persists even though keys are revoked/replaced/refreshed.
>>>
>>> -Ned
>>>
>>> On 3/25/20, 9:55 AM, "RATS on behalf of Henk Birkholz" 
>>> <[email-masked] <mailto:[email-masked]>on behalf 
>>> [email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>>
>>>    Hi Laurence,
>>>
>>>>> <mailto:[email-masked]>
>>>>> *From:*RATS <[email-masked] 
>>>>> <mailto:[email-masked]><mailto:[email-masked]>> on
>>>>> behalf of Simon Frost <[email-masked] 
>>>>> <mailto:[email-masked]><mailto:[email-masked]>>
>>>>> <mailto:[email-masked]>
>>>>> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>
>>>>> <mailto:[email-masked]>" <[email-masked] 
>>>>> <mailto:[email-masked]><mailto:[email-masked]>>

---

From: Simon Frost <[email-masked]>
Date: Fri, 27 Mar 2020 10:45:30 +0000

> If we want some other thing that is a claim that is for groups of devices, define that separately and say what the purpose and rules for grouping are.

That’s one use for what I was proposing, which was the creation of a GEID because for a group use case, the UEID claim from the current definition is not suitable. The intent was to try and avoid divergence by forcing the use of custom claims. I believe is that it’s impossible to predict the usage of such a claim and thus was not anticipating any constraint on how an implementation could consume it. I wanted to raise the key association possibility to make sure it was properly discussed, but it’s entirely possible that the signing and identity don’t go hand in hand.

Cheers
Simon

From: Laurence Lundblade <[email-masked]>
Sent: 27 March 2020 01:15
To: Smith, Ned <[email-masked]>
Cc: [email-masked]; Henk Birkholz <[email-masked]>
Subject: Re: [Rats] UEID where an instance is a group member

LL

Laurence,

Thanks,
Ned

LL

-Ned

   Hi Laurence,

   Viele Grüße,

   Henk

LL

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 27 Mar 2020 11:03:42 +0000

On 26/03/2020, 21:58, Ned Smith <[email-masked]> wrote:
> they are synonymous. Otherwise, they should be treated differently.

I'd go a bit further than that: they are never synonyms, at least at a
conceptual level.

In particular, there might be attributes of an attesting endpoint which
are not necessarily related to the signing key.  For example, the
linking to certification data, and more generally anything that has a
chance to change during the lifetime of the device (or is not known at
manufacturing time) is more easily supplied via endorsements to the
verifier.  In my view, EUID/EGID is the handle to all this data, which
MAY include the key used to verify the signature.

((Also, there might be more than one key associated with an attesting
endpoint. But maybe this is too exotic an use case to be relevant in
this discussion.))

cheers, t
--

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 27 Mar 2020 10:17:04 -0700

> On Mar 27, 2020, at 2:06 AM, Henk Birkholz <[email-masked]> wrote:
> 
> I am having a hard time to follow the discussion. What does "secured attestation" mean in this context, an EAT that is Evidence or something else? I am really not sure, because I cannot parse your first paragraph.

secured attestation evidence / results examples:
 — EAT that is signed like a normal CWT
 — Unprotected CWT Claims Set (UCCS) is transferred by TLS 
 — Unprotected CWT Claims Set (UCCS) signed by a TPM (seems to be on the radar in the bow-tie diagram)

unsecured attestation evidence / results examples:
  —  Unprotected CWT Claims Set (UCCS)
  —  Unprotected JWT Claims Set (UJCS) (I just made this up)

There is a layer that is the claim set (UCCS) and a layer that secure it (COSE, TLS…). They should be independent so you don’t have to fiddle with your claim set when you change the layer that secures it.

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 27 Mar 2020 10:24:43 -0700

Nothing. 

I assume you are referring to the COSE/JOSE kid header parameter.

Sorry if this is violent agreement.

LL

> On Mar 26, 2020, at 6:35 PM, Smith, Ned <[email-masked]> wrote:
> 
>> On Mar 26, 2020, at 2:58 PM, Smith, Ned <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> Laurence,
>> From: Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
>> 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]>>

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 27 Mar 2020 10:33:12 -0700

> On Mar 27, 2020, at 4:03 AM, Thomas Fossati <[email-masked]> wrote:
> 

Ahhh. There’s the source of the issue: what bits in attestation evidence give the binding to the endorsement?

Since I didn’t understand endorsements very well until Berlin, there’s nothing that I’ve (consciously) put into EAT to handle that.

Seems like a critical point to be addressed in EAT and in architecture. :-)

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 27 Mar 2020 18:19:30 +0000

From: Laurence Lundblade <[email-masked]>
Date: Friday, March 27, 2020 at 10:33 AM
To: Thomas Fossati <[email-masked]>
Cc: "Smith, Ned" <[email-masked]>, "[email-masked]" <[email-masked]>, Henk Berkholz <[email-masked]>
Subject: Re: [Rats] UEID where an instance is a group member

On Mar 27, 2020, at 4:03 AM, Thomas Fossati <[email-masked]<mailto:[email-masked]>> wrote:

Ahhh. There’s the source of the issue: what bits in attestation evidence give the binding to the endorsement?
Nms> Agree, there should be a conscious effort to identify how Evidence, Endorsement and Policy for Evidence are ‘bound’. If we are using database terminology these ‘bits’ would be called a database ‘composite key’ and the ‘binding’ function would be called a ‘join’ operation. In most of the examples I’ve seen the ‘binding bits’ are things like {vendor, productid/product_name, version or security_version_number} it could also be a digest of code where the digest value is used like an index to look up a record containing other claims that may include vendor, productid, version.

I included policy as well because the Verifier also needs to know which claims (though substantiated to be authentic) are relevant to the application or network in which the Attester resides or seeks residence. In essence, the policy is saying ‘this claim set is relevant’ according to the owner; call it claims set P. The Endorser is saying ‘this claim set is valid’ according to the supplier; call it claim set E. And the Attester is saying ‘this claim set exists for a particular device’; call it claim set A.

Appraisal then is the intersection of A, E and P. If the result is the empty set then clearly the appraisal result is rejection. Other results may be less easily concluded as accepted or rejected.

LL