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

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 <rsalz@akamai.com> wrote:
> 
> 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.
>  
> _______________________________________________
> RATS mailing list
> RATS@ietf.org <mailto:RATS@ietf.org>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>