Subject: [Rats] About (E)UID's

From: "Salz, Rich" <[email-masked]>
Date: Thu, 6 Feb 2020 16:34:41 +0000

I made a proposal during yesterday’s interim about EUID’s and I want to explain it here in more detail to the whole WG. I have made some clarifications.

We need ID’s.  Laurence has done a lot of good analysis on how many bits an ID needs to be to accommodate various users, devices, etc.  The TL;DR is that 128bits seems good for the size for now and at least the short-term future.

I suggest that the UID stays at 128bits. But in order to compare UID’s, relying parties should consider an “expanded” UID, which includes the SHA2 signature of the public signing key. For most cases, the “small” UID of 128 bits is sufficient to put into data structures, transport on the wire, and so on. Applications which present “unsigned” UID’s should either include a “key context” element, containing the hash. If not present, receiving applications should consider treat the key-id part as the SHA2 hash of the single zero byte.

One feature of this, as pointed out on the call, is that when a device gets a new owner, the expanded UID changes.

Hope this is useful.

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 7 Feb 2020 12:14:09 +0000

While not stated overtly in the draft, UEIDs are intended to be the sole identifier needed to universally identify a device. This is to make life easiest for the relying party. They do not have to combine it with any other claims to uniquely identify a device. (Maybe I should add text explaining this)

This makes life simpler for the device maker and for us, as we don’t have to specify any rules that say what combination of claims must be used to get proper global uniqueness and device maker doesn’t have to figure how some system for uniqueness.

Generally, interdependency between claims seems like something to avoid for the sake of simplicity.

I’m reluctant to rely on public keys for anything but signature verification because I think we must support a variety of signing schemes some of which don’t have a typical public key. One of these will be HMAC for which there is no pubic key. Another is likely to be ECDAA or such where the verification key material is a bit more complex than a public key.

The vendor is also allowed to change signing schemes and the means of creating UEIDs in their manufacturing process.

Also, as described in the draft, the UEID as defined is very permanent. It never changes over the life of the device. Some of the UEID options are based on identifiers that are specifically not to change with owner, IMEI for example.

LL

> On Feb 6, 2020, at 4:34 PM, Salz, Rich <[email-masked]> wrote:
> 
> _______________________________________________
> RATS mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Feb 2020 13:32:07 +0100

Laurence Lundblade <[email-masked]> wrote:
    > While not stated overtly in the draft, UEIDs are intended to be the
    > sole identifier needed to universally identify a device. This is to
    > make life easiest for the relying party. They do not have to combine it
    > with any other claims to uniquely identify a device. (Maybe I should
    > add text explaining this)

...

    > I’m reluctant to rely on public keys for anything but signature
    > verification because I think we must support a variety of signing
    > schemes some of which don’t have a typical public key. One of these
    > will be HMAC for which there is no pubic key. Another is likely to be
    > ECDAA or such where the verification key material is a bit more complex
    > than a public key.

HMAC is a symmetric signature system, and I don't know how that would be used
in practice.

    > The vendor is also allowed to change signing schemes and the means of
    > creating UEIDs in their manufacturing process.

I think that this is the bigger problem.

Making the UEIDs unique only within a manufacturer means that relying parties
and verifiers have to become aware of when manufacturers roll things.
Will TPM modules be updated with new keys?  I didn't think so, but they could
wind up with renewed certificates, and the signing chain to get there could
change.

This puts a lot of burden on the relying party.

So I think that 128-bit UEIDs are good enough for this decade, but I think
that they are not good enough for my lifetime, so I want 256-bit UEIDs
supported.  I don't want anything in between, because two sizes are enough.
The document should say that ::128-bit-UEID is acceptable as a 256-bit UEID.
That is, leading zeros can always be assumed.

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

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 7 Feb 2020 12:55:23 +0000

> On Feb 7, 2020, at 12:32 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

Pretty sure it has been used in by some vendors and has certainly been considered by others. You’d better to use HSMs to store the secrets to be secure.

> wind up with renewed certificates, and the signing chain to get there could

UEIDs are carefully described in the draft so the manufacturer can change the means by which they are generated without affecting the relying party. The draft instructs the relying party to always treat them as an opaque blob of bits.

A change in signing scheme obviously would affect the verifier, but the relying party might not be the verifier and might not be affected.

> That is, leading zeros can always be assumed.

Generally agree.

I don’t think we need to discuss leading zeros in the draft.  A 128-bit UEID is never equal to a 256-bit UEID. Map keys in CBOR with different lengths are never equivalent  We don’t write “___tent” to distinguish it from “portent” and such. 

Agreed on the size quanta, but was thinking 128, 192 and 256, in case someone super keen on saving bits wants to use 192 which is enough for all the use scenarios.

LL

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

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 7 Feb 2020 14:12:17 +0000

> On Feb 7, 2020, at 12:55 PM, Laurence Lundblade <[email-masked]> wrote:
> 
> 
>> 

Also note that UEIDs may be of a variety of lengths because the IMEI and EUI based versions of them. The shortest is 7 bytes for the EUI-48 (6 bytes for EUI-48 and 1 byte for UEID type).  They are unique because they rely on sequential assignment not on pure randomness.

If you want to save bytes in your IoT device, this is a good way to make UEIDs.
 
LL

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Feb 2020 16:32:13 +0100

Laurence Lundblade <[email-masked]> wrote:
    >> Agreed on the size quanta, but was thinking 128, 192 and 256, in case
    >> someone super keen on saving bits wants to use 192 which is enough for
    >> all the use scenarios.

    > Also note that UEIDs may be of a variety of lengths because the IMEI
    > and EUI based versions of them. The shortest is 7 bytes for the EUI-48
    > (6 bytes for EUI-48 and 1 byte for UEID type).  They are unique because
    > they rely on sequential assignment not on pure randomness.

I really would rather have 128 and 256, and not three options.

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

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 7 Feb 2020 15:39:37 +0000

>    I really would rather have 128 and 256, and not three options.
  
Strong agreement.  Those that can use shorter can just zero-pad.

---

From: Simon Frost <[email-masked]>
Date: Fri, 7 Feb 2020 16:14:42 +0000

> While not stated overtly in the draft, UEIDs are intended to be the sole identifier needed to universally identify a device.

I think there’s a problem with the expectation here. The current UEID test says.

UEID's must be universally and globally unique across manufacturers and countries.
  <snip>
No two products anywhere, even in completely different industries made by two different manufacturers in two different countries should have the same UEID (if they are not global and universal in this way, then relying parties receiving them will have to track other characteristics of the device to keep devices distinct between manufacturers).

How do we expect this to be realised in practice? It implies that all manufacturers must cooperate to guarantee there are no dups, which will quickly break down. I think the most that can be expected for a UEID is that it be unique to a manufacturer and that the bracketed part of the second sentence will apply (e.g. considering origination / OEMID) unless the relying party is aware that their use case is satisfied by a dedicated supply chain.

Note that the signing key may be able to derive the locus for this in some use cases, but not all – there are circumstances with unique keys per instance.

Thanks
Simon

From: Laurence Lundblade <[email-masked]>
Sent: 07 February 2020 12:14
To: Salz, Rich <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] About (E)UID's

LL

On Feb 6, 2020, at 4:34 PM, Salz, Rich <[email-masked]<mailto:[email-masked]>> wrote:

Hope this is useful.

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

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: "Salz, Rich" <[email-masked]>
Date: Fri, 7 Feb 2020 16:18:11 +0000

*   How do we expect this to be realised in practice?

I share this concern.  What will break if an adversary spoofs an UEID?

If “everyone in the world cooperates” is part of the trust model, we’re doomed.

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 7 Feb 2020 21:50:35 +0000

It was noted in the meeting that globally unique identifiers have privacy implications. One technique for protecting privacy is to limit the use of a particular identifier to a specific domain. Use in a different domain uses a different identifier making it hard to correlate transactions from Domain A with transactions in Domain B. This is essential to systems designed for privacy.

The IEEE802.1AR defines the notion of an IDevID and LDevID where the device receives a different identity following onboarding. Issuance of an LDevID has been used to protect privacy because within the community of devices sharing the same local context, they don’t recognize the device in terms of its IDevID identity. Not unless there is a UEID that is shared between the IDevID and the various LDevID credentials.

If UEID is defined to be globally unique, then it can’t be required for use if privacy is also needed.

I suspect implementations will ignore the wording in the EAT spec that asserts the value is globally unique and encode a value that is unique enough for their purposes. If there is some service out there that assumes global uniqueness but discovers collisions, then it will be a business decision whether or not to accept them.

Otherwise, the conversation for UEID should revolve around whether or not there are large domains that need an identifier that is unique within its domain. Based on the analysis there is enough space in 128-bits to allow for a domain of all people in the world being a member of the domain each bringing 100 – 100,000 things and where the things can be shared and exchanged within the domain context. I’m not aware of a real world use case for that domain. Hence, 128-bits with the flexibility to make them larger seems right. I like the suggestion to allow larger values in 8-bit increments because it allows the domain (of use) to optimize the cost/benefit trade-offs.

-Ned

From: RATS <[email-masked]> on behalf of Simon Frost <[email-masked]>
Date: Friday, February 7, 2020 at 8:15 AM
To: Laurence Lundblade <[email-masked]>, "Salz, Rich" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Rats] About (E)UID's

Thanks
Simon

LL

Hope this is useful.

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 8 Feb 2020 23:24:54 +0000

Responding to Simon, manufacturers only have to follow the the specification. They don’t have to cooperate beyond that.

I think the bottom line on UEID uniqueness is that we can’t do much better in an IETF standard. We have no means of enforcement in the IETF. Note that there are IMEI and MAC address options which have some good uniqueness characteristics. There’s lots of things in IETF standards that people can get wrong and we live with them.

To really have enforcement a certification program is needed. There is one covering EAT partly in PSA certified <https://www.psacertified.org/>, though I don’t know if there are requirements on the UEID.

The PR I just merged allows lengths of 128, 192 and 256 bits. 8 byte increments should be enough and 192 bits is enough for all use scenarios.

The privacy issue is already mentioned in the draft.

I think we have to have UEID in the standard even though it may not used when privacy preservation is necessary. Note that the verifier could be the guarantor of privacy in some use cases and filter it out. 

I think it is possible to design a system where UEIDs are unique per relying party if you strongly authenticate the relying party. That is complex to do and probably not for the first round.

LL

> On Feb 7, 2020, at 9:50 PM, Smith, Ned <[email-masked]> wrote:
> 
> From: RATS <[email-masked] <mailto:[email-masked]>> on behalf of Simon Frost <[email-masked] <mailto:[email-masked]>>
> To: Laurence Lundblade <[email-masked] <mailto:[email-masked]>>, "Salz, Rich" <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> From: Laurence Lundblade <[email-masked] <mailto:[email-masked]>> 
> To: Salz, Rich <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
>> On Feb 6, 2020, at 4:34 PM, Salz, Rich <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Simon Frost <[email-masked]>
Date: Tue, 11 Feb 2020 15:39:29 +0000

The PSA Certification program doesn’t include any proofing on the identities but devices are expected to follow the PSA Security model in that they can be uniquely identified within their manufacturing and/or provisioning chain. The PSA attestation report (see https://tools.ietf.org/html/draft-tschofenig-rats-psa-token-04) includes a claim for the unique instance identity but also an implementation ID (claim) that identifies this manufacturer origin, quoted in the specs as identifying the immutable PSA Root of Trust for the implementation. There is a logical extension to use a group identity with an Implementation ID for use cases where an individual instance identity may not be appropriate.

I agree that there should have a UEID claim within the standard and also with the proposed bitlength representations.

I suggest we should change the description of the UEID claim to allow the standard to support more interpretations of what the locus of uniqueness might be to an implementation.

HTH
Simon

From: Laurence Lundblade <[email-masked]>
Sent: 08 February 2020 23:25
To: Smith, Ned <[email-masked]>
Cc: Simon Frost <[email-masked]>; Salz, Rich <[email-masked]>; [email-masked]
Subject: Re: [Rats] About (E)UID's

To really have enforcement a certification program is needed. There is one covering EAT partly in PSA certified<https://www.psacertified.org>, though I don’t know if there are requirements on the UEID.

LL

On Feb 7, 2020, at 9:50 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

-Ned

From: RATS <[email-masked]<mailto:[email-masked]>> on behalf of Simon Frost <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 7, 2020 at 8:15 AM
To: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>, "Salz, Rich" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] About (E)UID's

Thanks
Simon

From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Sent: 07 February 2020 12:14
To: Salz, Rich <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Rats] About (E)UID's

LL

Hope this is useful.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Feb 2020 22:22:37 +0100

Simon Frost <[email-masked]> wrote:
    > I agree that there should have a UEID claim within the standard and
    > also with the proposed bitlength representations.

    > I suggest we should change the description of the UEID claim to allow
    > the standard to support more interpretations of what the locus of
    > uniqueness might be to an implementation.

What are the implications to the Verifier and Relying Party of these differences?

If you intend there to be code path differences based upon the locus of
uniqueness, then I would prefer that value of the UEID claim be opaque, and
if we need to have semantic differences, that we register multiple UEID key
values.

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 12 Feb 2020 08:53:44 +0000

Hi Michael,

On 11/02/2020, 21:22, Michael Richardson wrote:
> > I suggest we should change the description of the UEID claim to
> > allow the standard to support more interpretations of what the locus
> > of uniqueness might be to an implementation.
>
> If you intend there to be code path differences based upon the locus
> of uniqueness, then I would prefer that value of the UEID claim be
> opaque, and if we need to have semantic differences, that we register
> multiple UEID key values.

This is exactly what the PSA token does: it reuses UEID RAND semantics
and encodes it with a custom arm_psa_UEID key id.

Cheers!

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 12 Feb 2020 12:32:48 +0000

> On Feb 11, 2020, at 3:39 PM, Simon Frost <[email-masked]> wrote:
> 

Hi Simon,

Can you say more and / or give an example?

The design goal of UEID is global / universal uniqueness — the locus is everything. It offers the vendor two paths to achieving this.

1) Probabilistically unique large random values that need to central authority and involve no money.

2) Global values assigned and managed by a central authority like IEEE or GSMA. This usually involves money.

1) is flexible in that it allows creation of the value by hashing together enough random bits from sources ready-to-hand (which Thomas points out, PSA is using). 

We can add other global registries if needed (and they truly are global).

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 12 Feb 2020 12:43:32 +0000

Correction to sentence below
> 
> 
> 1) Probabilistically unique large random values that need no to central authority and involve no money.
>

---

From: Simon Frost <[email-masked]>
Date: Wed, 12 Feb 2020 14:02:37 +0000

I wasn't suggesting that the UEID claim be structured, rather that the description be changed to describe a value unique within the target context. This makes the standard claim more useful for any implementation that doesn't fit a global viewpoint, rather than that automatically needing a custom claim.

The assumption here is that a given implementation of Remote Attestation based on the standard will be prepared such that the policies applied by the verifier and the relying party take into account the locus to which that implementation is targeted. Within that, they can follow a standard definition for an (opaque) UEID claim as identifying a unique instance. However, it can be specific to that implementation context whether other claims, standard or custom, may be required to apply the policy. For example: if an implementation is built for a closed ecosystem with a dedicated single supplier then evidence appraisal may need only consider the UEID claim. Alternatively, if it is known there may be multiple suppliers then evidence appraisal could also consider, say, OEMID or Origination claims along with the UEID claim.

Going back to PSA Security Model, the InstanceID uniquely identifies the Attestation Key and which in turn must be unique to an Implementation of the PSA RoT, hence to establish locus the (custom) ImplementationID claim is also required.

On a related note, the PSA token proposes a 'Profile' claim to be included in the token, being a reference to a document that defines the set of claims used and any semantic details.  This wouldn't be required to satisfy the above but could be used to remove any ambiguity for the verifier implementer / policy writer. This proposed claim is captured as part of the EAT issues: https://github.com/ietf-rats-wg/eat/issues/32

HTH
Simon

-----Original Message-----
From: Michael Richardson <[email-masked]>
Sent: 11 February 2020 21:23
To: [email-masked]
Subject: Re: [Rats] About (E)UID's

If you intend there to be code path differences based upon the locus of uniqueness, then I would prefer that value of the UEID claim be opaque, and if we need to have semantic differences, that we register multiple UEID key values.

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

---

From: Simon Frost <[email-masked]>
Date: Wed, 12 Feb 2020 14:08:20 +0000

Sorry, missed this while replying to Michael – see my just posted response which should enlarge on my original comment.

I don’t think probabilistic uniqueness can be relied upon globally. However it should be reliable where other information, either implicit from the use case or explicit by the use of other information establishes a more reliable locus.

I agree no one will want to pay fees to, or take liability for, a registry for global uniqueness on an instance level.

From: Laurence Lundblade <[email-masked]>
Sent: 12 February 2020 12:33
To: Simon Frost <[email-masked]>
Cc: Smith, Ned <[email-masked]>; Salz, Rich <[email-masked]>; [email-masked]
Subject: Re: [Rats] About (E)UID's

On Feb 11, 2020, at 3:39 PM, Simon Frost <[email-masked]<mailto:[email-masked]>> wrote:

Hi Simon,

LL

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 12 Feb 2020 15:49:51 +0000

I am still concerned about what fails if someone re-uses an EUID, either by accident or maliciously.  If the security of the RATS architecture depends on uniqueness, this seems important.

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 12 Feb 2020 11:01:08 -0500

The security of the RATS architecture does not rely on a single claim. 
It relies in trust anchors that you can put trust into in order to 
believe a certification path and therefore attestation provenance, it 
also relies an Endorsements provided by potential several Supply Chain 
entities.

A single UEID claim that could encounter a collision (maliciously 
intended or by accident) will not necessarily compromise a complete 
instance of a remote attestation procedures. If your Claim set and 
corresponding secret/shielded key material are sparse, this reduces the 
believability of the corresponding evidence and therefore lower the 
level of assurance/security of that implemented RATS architecture.

But that is an implementation choice. The architecture offers suitable 
set of secure methods. If base all you post-process decision, than that 
is a choice and should be aware of the risk involved for not using any 
other secure methods.

Viele Grüße,

Henk

On 12.02.20 10:49, Salz, Rich wrote:
> I am still concerned about what fails if someone re-uses an EUID, either 
> by accident or maliciously.  If the security of the RATS architecture 
> depends on uniqueness, this seems important.
> 
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 12 Feb 2020 16:05:18 +0000

Text derived from this should show up in the architecture document.

On 2/12/20, 11:02 AM, "Henk Birkholz" <[email-masked]> wrote:

    
    
    Viele Grüße,
    
    Henk

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 12 Feb 2020 16:07:35 +0000

On 12/02/2020, 15:50, Salz, Rich <[email-masked]> wrote:
> I am still concerned about what fails if someone re-uses an EUID,
> either by accident or maliciously.  If the security of the RATS
> architecture depends on uniqueness, this seems important.

I agree with you.

If ueid is used to locate the verification key, then verification
would fail.  (BTW, this is what we do in PSA.)

If ueid is disjoint from the verification key, then it *might* result in
impersonation -- this also depends on the verification policy.

The EAT document should warn about the latter.

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Wed, 12 Feb 2020 16:52:19 +0000

> I am still concerned about what fails if someone re-uses an EUID, either by accident or maliciously.  If the security of the RATS architecture depends on uniqueness, this seems important.

Looking at experiences made with past attempts to create globally
uniqueness addresses, it seems that assuming the existence of globally
unique identifiers is somewhat idealistic.

I think truth in advertising is important here so that people are
prepared to handle rare situations in non-catastrophic ways when the
uniqueness assumption may be challenged. There is an important
difference between "generally unique" or "likely unique" and
"guaranteed to be always unique".

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 12 Feb 2020 17:16:43 +0000

> On Feb 12, 2020, at 4:07 PM, Thomas Fossati <[email-masked]> wrote:
> 

Here’s some text we might add:

UEID’s are intended to be globally unique permanent device identifiers, but these characteristics rely on the implementors of device following the specification well. A relying party, particularly one dealing with a very broad variety of devices from different manufacturers, may wish to take into account other data in the token to uniquely identify the device. For example they might consider a hash some or all of the UEID + oemid + hw_version + signing_key as the unique identifier of the device. Note these are all values that are permanently set for a device at time of manufacturer.

> impersonation -- this also depends on the verification policy.

I would like to keep the text in EAT for UEID focused on device identification and not try to build it into a key ID too, so I don’t think the text in the EAT document should consider that use case for UEID. Profiles of EAT can specify that and can doubly insist on uniqueness, proper implementation and have a certification program to check.

EAT is intended for use with a lot of different key types and signing schemes including things like ECDAA. Android and FIDO attestation use one key across 100,000 device for privacy. One implementation of attestation I’ve seen authenticates the relying party and generates relying-party specific UEIDs that are disjoint from the attestation key.  EAT needs to work for all of these. No strong coupling between the UEID and signing key should be required in the main EAT standard *and* it must allow for strong coupling should a profile wish it.

That is:
- UEIDs are for device identification
- Signing and signing keys are for claims authenticity and integrity, not device identification

> The EAT document should warn about the latter.

Is the text above for the relying party, sufficient warning for the general case?  PSA will probably want stronger words in its profile.

LL

---

From: Simon Frost <[email-masked]>
Date: Wed, 12 Feb 2020 17:52:34 +0000

I think that modification would address this discussion well (though perhaps add ‘or verifier’ as well as relying party in the text).

I agree not making a hard association here with any key selection, any implementor should be considering their particular threat model on how the different claims are protected.

Thanks
Simon

From: Laurence Lundblade <[email-masked]>
Sent: 12 February 2020 17:17
To: Thomas Fossati <[email-masked]>
Cc: Salz, Rich <[email-masked]>; Simon Frost <[email-masked]>; [email-masked]; Smith, Ned <[email-masked]>
Subject: Re: [Rats] About (E)UID's

On Feb 12, 2020, at 4:07 PM, Thomas Fossati <[email-masked]<mailto:[email-masked]>> wrote:

On 12/02/2020, 15:50, Salz, Rich <[email-masked]<mailto:[email-masked]>> wrote:

I agree with you.

That is:

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 12 Feb 2020 18:10:03 +0000

FYI, this text <https://en.wikipedia.org/wiki/International_Mobile_Equipment_Identity#IMEI_and_the_law> about the use of IMEI uses in law enforcement is interesting. 

Also FYI, someone  suggested using UEID as a way to defend against bad Uber drivers. Once an Uber driver was considered “bad”, their UEID was logged. Given that a UEID can’t be changed by factory reset, refreshing and such, they actually had to buy a new phone to re enroll with Uber.

LL

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Feb 2020 07:19:21 +0000

Simon Frost <[email-masked]> wrote:
    > The assumption here is that a given implementation of Remote
    > Attestation based on the standard will be prepared such that the
    > policies applied by the verifier and the relying party take into
    > account the locus to which that implementation is targeted. Within
    > that, they can follow a standard definition for an (opaque) UEID claim
    > as identifying a unique instance.

I don't think that we can make the assumption that there will a locus.
  a) TPMs and other generic parts will need to be built for the entire
     market.
     
  b) The failure of remote attestation to really take off has been to
     the extreme silo nature that has occured to date, and a major purpose
     of this WG is to deal with that.

So, EUIDs either somehow have world-wide uniqueness, or we have to define
them explicitely in terms of manufacturer context, and be clear what provides
that context.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Feb 2020 07:26:48 +0000

> UEID’s are intended to be globally unique permanent device identifiers,
    > but these characteristics rely on the implementors of device following
    > the specification well. A relying party, particularly one dealing with
    > a very broad variety of devices from different manufacturers, may wish
    > to take into account other data in the token to uniquely identify the
    > device. For example they might consider a hash some or all of the UEID
    > + oemid + hw_version + signing_key as the unique identifier of the
    > device. Note these are all values that are permanently set for a device
    > at time of manufacturer.

Since the Relying Party needs to vest trust in the Verifier, it seems that
the verifier out to calculate this hash, and it should be a new claim.

a) it has access to this information.
b) there are fewer Verifiers than Manufacturers
c) the OEMID/HW_Version may well be personally identifier information which
   should not be passed on to the Relying Party.
   (Although I guess, if we are forming a hash over it, it becomes trackable)

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Feb 2020 12:49:55 +0100

> b) there are fewer Verifiers than Manufacturers

Let me restate: a Relying Party has relationships with fewer Verifiers than
there are Manufacturers.  Maybe worst case Manufacturers:Verifiers will be
1:1, but in better cases where a Verifier providers services for many
manufacturers that ratio could be different, and thus in general, the RP will
have fewer relationships with Verifiers than Manufacturers.