search

ietf-rats-wg / eat

Entity Attestation Token IETF Draft Standard
Other
18 stars 15 forks source link

UEID claim should be opaque with clear minimum and maximums #290

Closed mcr closed 2 years ago

mcr commented 2 years ago 
> 8) length of UEID:

> _UEIDs are variable length. All implementations MUST be able to receive
> UEIDs that are 33 bytes long (1 type byte and 256 bits). No UEID longer
> than 33 bytes SHOULD be sent._

> Sounds a bit like Mr.Ford. You can have your model-T in any colour, as
> long as it's black.  I had to read it three times.  May I suggest:

> _UEIDs are variable length fields between X and 33 bytes in size.  All
> implementations MUST be able to receive UEIDs that are up to 33 bytes
> long.  33 bytes accomordates 1 type byte and 256 bits.  UEIDs SHOULD
> NOT be longer than 33 bytes.

This text in section 4.2.1 did not address this change.

mcr commented 2 years ago 
> _The consumer of a UEID MUST treat a UEID as a completely opaque string
> of bytes and not make any use of its internal structure_ if that's the
> case, why do you need the type field? :-)
laurencelundblade commented 2 years ago

The type field is necessary on generation to guarantee no collision between two UEIDs of different types that have accidentally have the same value. For example, suppose a MAC address happened to have the same value as an IMEI. There's no coordination between IEEE MAC address allocation and 3GPP IMEI allocation.

It is also true that none of the three types defined could collide because none are ever the same length. Type 1 is 16, 24 or 32 bytes. Type 2 is 6 or 8 bytes. Type 3 is 14 bytes. So can we remove the type byte because of that?

Not really, because more types may be defined in the future and one of them may have the same length.

So it only a factor on generation to assure uniqueness. The receiver still treats it as opaque.

(This doesn't answer everything mentioned in this issue. Will get back on the other stuff).

mcr commented 2 years ago

I want to suggest that the normative part of the document limit itself to what the receiver/processor of the claim can expect. Then provide some non-normative text on generating the UEID. If you anticipate future types might exist, then it seems that an IANA Registry would be required. Also be aware that there is now a uuidrev WG, and perhaps it enough to say that the UEID is UUID, and then describe ways in which an MAC address or an IMEI may be transformed into an UUID (there definitely is a mac address formula).

laurencelundblade commented 2 years ago

New types require standards action. I think that removes the need for a registry.

I don't think we can move the use of the type byte to non-normative because the guarantee of uniqueness would be lost.

I noticed the uuidrev WG, but don't think we want to delay EAT for it's outcome (and don't think UUID as defined today works here. Rich Salz agreed with some of this.

laurencelundblade commented 2 years ago

Your suggestion 8) for improved text on the length of a UEID was good and there were changes to 4.2.1 in draft-14 to address it. Do you have specific comments on 4.2.1 in draft-14?

mcr commented 2 years ago

Laurence Lundblade @.***> wrote:

I noticed the uuidrev WG, but don't think we want to delay EAT for it's outcome (and don't think UUID as defined today works here. Rich Salz agreed with some of this.

You don't have to wait. You just define the UEID as a UUID, and then any revisions that uuidrev does are automatically include. UUIDs already have a type in them.

(MAC->UUID is already a thing. EAT might need to ask uuidrev to map IMEI to UUID, but that wouldn't delay EAT)

-- Michael Richardson @.***>, Sandelman Software Works -= IPv6 IoT consulting =-

mcr commented 2 years ago

Laurence Lundblade @.***> wrote:

Your suggestion 8) for improved text on the length of a UEID was good and there were changes to 4.2.1 in draft-14 to address it. Do you have specific comments on 4.2.1 in draft-14?

I dunno. The way-too-wide iddiff situation keeps me from seeing the changes.

laurencelundblade commented 2 years ago

Hopefully you can find a diff and see the improved wording now that the long lines are fixed.

UEID has characteristics that go beyond what a UUID is defined to be. We'd still have to describe what a UUID identifies, the nature of its permanence and such. There's still be a lot of text.

We can't make normative reference to a draft. We need a normative reference. It would have to be to 4122. What is in 4122 today isn't sufficient.

An important characteristic of MAC-based UEIDs is that they can be very short (7 bytes in total). IMEI is also shorter than a full random UEID. A future type could also be short (e.g., PEN + serial number). UUIDs are not accommodating that. These are short because they are based on central registration and assignment. The main points of UUID is to not need any registration or assignment.

UEIDs have been in the document for years now. They have always been distinct from UUIDs. There seems to be good consensus around them.

carl-wallace commented 2 years ago

You can use this form to upload txt versions of the doc and set the column width and do a diff: https://www.ietf.org/rfcdiff, i.e., to diff between -14 and -16 for example.

From: Laurence Lundblade @.> Reply-To: ietf-rats-wg/eat @.> Date: Wednesday, October 12, 2022 at 1:29 PM To: ietf-rats-wg/eat @.> Cc: Subscribed @.> Subject: Re: [ietf-rats-wg/eat] UEID claim should be opaque with clear minimum and maximums (Issue #290)

Hopefully you can find a diff and see the improved wording now that the long lines are fixed.

UEID has characteristics that go beyond what a UUID is defined to be. We'd still have to describe what a UUID identifies, the nature of its permanence and such. There's still be a lot of text.

We can't make normative reference to a draft. We need a normative reference. It would have to be to 4122. What is in 4122 today isn't sufficient.

An important characteristic of MAC-based UEIDs is that they can be very short (7 bytes in total). IMEI is also shorter than a full random UEID. A future type could also be short (e.g., PEN + serial number). UUIDs are not accommodating that. These are short because they are based on central registration and assignment. The main points of UUID is to not need any registration or assignment.

UEIDs have been in the document for years now. They have always been distinct from UUIDs. There seems to be good consensus around them.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

gmandyam commented 2 years ago

All required changes addressed in drafts -14 and beyond