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

> On Feb 7, 2020, at 12:32 PM, Michael Richardson <mcr@sandelman.ca> wrote:
> 
> 
> Laurence Lundblade <lgl@island-resort.com> wrote:
> ...
>> 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.

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.

> 
>> 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.

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.

> 
> 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.

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

> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats