Subject: [Rats] UEID questions

From: "Smith, Ned" <[email-masked]>
Date: Tue, 23 Apr 2019 17:37:41 +0000

The type-1 EUID in draft-manyam-rats-eat-00 lists GUID as consisting of 128 – 256 bits of random number. RFC4122 (https://tools.ietf.org/html/rfc4122) says a UUID is 128-bits with 6 bits of variant/version info. Also the word random can mean different things. (i) selected at random (ii) entropic. RFC4122 doesn’t require entropic UUID values. Does the type-1 EUID intend to be RFC4122 compliant? If not does it make sense to include a variant that is RFC4122 compliant?

Also, the draft indicates the verifier should regard EUID (variants) as opaque. Hence, the way they’re constructed is mostly irrelevant IMO except for the length. The list of EUIDs seems to be selected based on popularity / common use, but there are cases where vendors require larger or smaller values based on a variety of implementation considerations. It might be helpful to have a type for a variable length EUID (as they are already defined to be variable length).

Another approach could be to define the existing types in terms of a starting value (e.g. starts with EUI-48) but allows additional bits to be appended.  Could be represented as variable size structures or fixed size with padding (e.g. EUI-48-64 where first 48 bits is EU-48 and remaining 12 bits is vendor supplied and may include padding bits.)

A side-bar on encoding. If the information model describes these semantics, then some of the guidance in the current draft could be better focused on the relevant data model bindings. For example, a CBOR binding for EUID would not require a base-64 encoding requirement.

Thx,
Ned

---

From: Giridhar Mandyam <[email-masked]>
Date: Tue, 23 Apr 2019 19:36:37 +0000

Thanks Ned for the comments and question.  If you don’t mind, I will enter it as an issue in https://github.com/eat-ietf-wg/eat in order to track it, before preparing a response.

-Giri Mandyam

From: RATS <[email-masked]> On Behalf Of Smith, Ned
Sent: Tuesday, April 23, 2019 10:38 AM
To: [email-masked]
Subject: [Rats] UEID questions

CAUTION: This email originated from outside of the organization.
The type-1 EUID in draft-manyam-rats-eat-00 lists GUID as consisting of 128 – 256 bits of random number. RFC4122 (https://tools.ietf.org/html/rfc4122) says a UUID is 128-bits with 6 bits of variant/version info. Also the word random can mean different things. (i) selected at random (ii) entropic. RFC4122 doesn’t require entropic UUID values. Does the type-1 EUID intend to be RFC4122 compliant? If not does it make sense to include a variant that is RFC4122 compliant?

Thx,
Ned

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 23 Apr 2019 15:51:04 -0700

Hi Ned,

> On Apr 23, 2019, at 10:37 AM, Smith, Ned <[email-masked]> wrote:
> 
> The type-1 EUID in draft-manyam-rats-eat-00 lists GUID as consisting of 128 – 256 bits of random number. RFC4122 (https://tools.ietf.org/html/rfc4122 <https://tools.ietf.org/html/rfc4122>) says a UUID is 128-bits with 6 bits of variant/version info. Also the word random can mean different things. (i) selected at random (ii) entropic. RFC4122 doesn’t require entropic UUID values. Does the type-1 EUID intend to be RFC4122 compliant? If not does it make sense to include a variant that is RFC4122 compliant?

EUID is certainly not UUID. While UUID is what exists, I think it is overly-complex and confusing with its various types and use cases. I want to very purposely avoid it.

The if a random number, the GUID version of EUID must be a cryptographic quality. That is an omission in the draft that should be fixed.

> Also, the draft indicates the verifier should regard EUID (variants) as opaque. Hence, the way they’re constructed is mostly irrelevant IMO except for the length. The list of EUIDs seems to be sele…

I’m not sure what considerations would lead to different lengths. 33 or 17 bytes is not very large and there is no good reason to go larger.

128 bits (16 bytes) is enough for one trillion humans to each have one trillion devices and the probability of collision less than a trillion (log base 10 of 2^ 128 = 38; log base 10 of a trillion is 12; 3 * 12 < 38) So 128 bits seems like enough, but take it out to 256 bits because SHA-256 is popular and good and there is some extra margin. I see no point in allowing anything longer than 33-bytes.

I don’t think it is good to go smaller because of the probability of collision starts to get low.

> Another approach could be to define the existing types in terms of a starting value (e.g. starts with EUI-48) but allows additional bits to be appended.  Could be represented as variable size struc…

Almost any identifier can be turned into a GUID by running it through SHA-256. SHA-256 is about 1KB of object code and less than 200 bytes of context. Probably every device / OS / platform supports SHA-256 and it is easy to use. The draft does say that the GUID can be constructed this way. This seems like enough flexibility to accommodate schemes that don’t have an official type.

The only types included in the draft are well managed truly universal identifiers. We wouldn’t want anything else.

I think it is good to keep the number of types as small as possible so there should be good justification and vetting for all types allowed.

> A side-bar on encoding. If the information model describes these semantics, then some of the guidance in the current draft could be better focused on the relevant data model bindings. For example,…

Yes, agreed.

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 23 Apr 2019 23:36:14 +0000

See inline [nms].

On 4/23/19, 3:51 PM, "Laurence Lundblade" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ned,

On Apr 23, 2019, at 10:37 AM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

EUID is certainly not UUID. While UUID is what exists, I think it is overly-complex and confusing with its various types and use cases. I want to very purposely avoid it.
[nms] Some use UUID and GUID interchangeably. There is an RFC for UUID. I’m not aware of an RFC for GUID. The draft doesn’t disambiguate and it is a reasonable question to ask. Possibly the draft should be more clear?

The if a random number, the GUID version of EUID must be a cryptographic quality. That is an omission in the draft that should be fixed.
[nms] Does the draft intend to differ from GUID semantics? If there is a reference to where it is officially defined, readers could refer to that for guidance regarding expected entropy (if any).

But there is a more important question / consideration at work here; which is why there even needs to be type and formatting semantics in the draft as the relying party/verifier treats them as opaque values. The draft seems to be informing the developers who are constructing the EUID not those who are using it. If that is correct, then there could be less rigid attention to what might be considered an acceptable (normative) EUID construction if it doesn’t affect interoperability.

Also, the draft indicates the verifier should regard EUID (variants) as opaque. Hence, the way they’re constructed is mostly irrelevant IMO except for the length.

The list of EUIDs seems to be selected based on popularity / common use, but there are cases where vendors require larger or smaller values based on a variety of implementation considerations. It might be helpful to have a type for a variable length EUID (as they are already defined to be variable length).

I’m not sure what considerations would lead to different lengths. 33 or 17 bytes is not very large and there is no good reason to go larger.
[nms] It is a question of whether the length constraints are even necessary for interoperability. The draft indicates EUID is a variable length structure. The processing overhead for variable length values is already encompassed, so why would the draft want to place artificial length constraints on top of that?

Almost any identifier can be turned into a GUID by running it through SHA-256. SHA-256 is about 1KB of object code and less than 200 bytes of context.
[nms] Correct. Why not define EUID in terms of hash alg output lengths (e.g. 128b, 256b, 512b etc.)?

Probably every device / OS / platform supports SHA-256 and it is easy to use. The draft does say that the GUID can be constructed this way. This seems like enough flexibility to accommodate schemes that don’t have an official type.

I think it is good to keep the number of types as small as possible so there should be good justification and vetting for all types allowed.
[nms] Agree. The current list could be trimmed if the focus was on a few commonly useful lengths (e.g. 128b, 256b, 512b etc.) or just a single variable length value.

Yes, agreed.

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 29 Apr 2019 10:41:59 -0700

So, yes, now that I look at it again, I think use of the term “GUID” should be removed. 

Yes, most of the draft is giving instructions to the creator of the EUID to help them get it right and those instructions are not really necessary for interop, just so the generator of them gets it right. (Note that most of the UUID draft is such instructions).  I think the instructions are pretty important as some may not even be aware of probabilistic construction and such. The idea is to pick a few simple ways to get it done to give a lot of help to implementors. 

So, types 2 through 6 are already-existing identifier that will work great. If the implementor has those handy, it is super easy for them. The length of them is as the existing identifier’s length.  We can add a few more, but should be conservative about it. Are you OK with the inclusion of these types and the text for them? Are we just discussing type 1?

Type 1 is the open-ended one for implementors that don’t have types 2-6 handy.  It needs to be better described as this (plus mention of crypto quality randomness, minus mention of GUID).

I think a minimum length for type 1 is important so that the probabilistic construction works. The whole thing falls a part if implementation use 4 byte integers or such.

I like having a maximum length to make small tight implementations much easier, especially when the max is one that can fit on the stack of a tiny IoT device. To give an example, in some X.509 implementations I’ve done for embedded use cases, I created a profile that limited the length of many fields so memory was small and memory management code was simple. X.509 of course can’t specify limits because it covers so many use cases, but EUID will work just fine with an upper limit.

LL

> On Apr 23, 2019, at 4:36 PM, Smith, Ned <[email-masked]> wrote:
> 
> See inline [nms].
>  
> On 4/23/19, 3:51 PM, "Laurence Lundblade" <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Ned, 
>  
>  
>> On Apr 23, 2019, at 10:37 AM, Smith, Ned <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 29 Apr 2019 17:49:20 +0000

GUID was first coined by Microsoft as a term instead of UUID.  Perhaps they felt less hubristic at the moment. :) At the time RFC 4122 was written, random didn’t have the shades of meaning it does now.

I think that name-based UUID is appropriate for this.

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 29 Apr 2019 18:15:43 +0000

I think it would help the draft if there was a section or paragraph in the information model that focuses on claim/assertion creation and a different section/paragraph on use and interoperability.

As a practical matter for minimum and maximum length values, the data model encoding technique (e.g. CBOR, JSON, BER) will likely already have some way to exactly capture the size of the value and parser implementations often have worked out the buffer / memory management details. Hence, restrictions on value size should be understood first in terms of information model impact. For example, to set a minimum security bar or to enhance interoperability etc. I can easily see justification for a minimum size for security reasons. I have more difficulty seeing justification for a maximum size restriction – although it seems reasonable to consider limitations imposed by constrained environments. Nevertheless, if larger size values have a beneficial and desirable security impact, it seems inappropriate to arbitrarily restrict anyone from realizing that value.
-Ned

On 4/29/19, 10:42 AM, "RATS on behalf of Laurence Lundblade" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

LL

On Apr 23, 2019, at 4:36 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

See inline [nms].

Hi Ned,

Yes, agreed.

LL

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Tue, 30 Apr 2019 08:44:05 +0000

On 29 Apr 2019, at 19:15, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

I like this approach. Given that GlobalPlatform (and, as far as I am aware, other bodies as well) are developing vertical-specific claims sets and configurations, providing some informative assistance on interoperability for claims such as EUID seems like a good way to go.

I agree for the maxima. At GlobalPlatform we will most likely address this through the concept of a "configuration" (e.g. for a TEE in a constrained device in our case). I am not sure how such things are best addressed at IETF, but this sounds like it might be material for an Annexe.

Looking at the minima, we should be aware that there exist in some cases unique IDs that are rather shorter than might be desirable for cryptographic uniqueness.A good example is in the Secure Element space where the most meaningful unique platform identifier is managed across the industry rather than cryptographically based (uniqueness in this case being checked through the security certification evaluations which are used universally for this class of devices).

Therefore I would suggest that any upper and lower bounds are informative rather than normative.

Jeremy

-Ned

LL

See inline [nms].

Hi Ned,

Yes, agreed.

LL

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