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

[Michael Richardson <[e-mail]>]

Laurence Lundblade <[e-mail]> 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  [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [