Public ECDH Key characteristic should be per slot

[hakonfam]

The "EID Identity Key" characteristic is defined to be "for the active slot". Hence, it will be different for each EID slot.

The "Public ECDH Key" characteristic is defined as " the beacon's 256-bit public ECDH key". Hence, it will be the same for all EID slots.

In the case where an Eddystone Beacon has multiple EID slots, it will not be possible to register the Beacon as it would require adding the same ECDH Public Key multiple times (one per EID slot), which is not permitted:

{ "error": { "code": 409, "message": "Ephemeral beacon registration failed, please regenerate a new key and retry.", "status": "ALREADY_EXISTS" } }

As the EID Identity Key is directly associated to the ECDH Key, shouldn't the Eddystone Beacon expose a public ECDH key for each EID slot the same way it does for Identiy Keys? In brief terms: The "Public ECDK Key" chacteristic should be per slot, not per beacon.

[adriancretu]

Well, since the Identity Key is computed based on your own ECDH key and the server's public key, it makes sense for the registration to fail (IK used already), which validates your point that ECDH should be stated to be per slot. But the ECDH public key is only useful during the registration (Diffie-Helman exchange) so I don't see a point in storing it as either a "beacon" or "slot" property, but just as temporary data.

[hakonfam]

You would in any case have to expose the public key to the client through the characteristic.

If you want to register an EID with multiple resolvers (not sure if this is a valid use case), or you have to re-register an EID with a resolver, the beacon the ECDH key set would have to be retained in the beacon.

[adriancretu]

You would in any case have to expose the public key to the client through the characteristic.

That happens after you've received the resolver public key, and you computed your new IK, not before. The only problem would be if you register multiple slots at once and you reset the ECDH key before client reads it..

If you want to register an EID with multiple resolvers (not sure if this is a valid use case)...

It's not, unless all resolvers have the same private keys you'll obtain different IKs, hence different EID to advertise. The spec says for this case, to register using the IK directly, its the only way to have same "beacon" in fact.

or you have to re-register an EID with a resolver...

When would this ever make practical sense? Plus, you'll just get back the error from your first post, since it's already registered.

...the beacon the ECDH key set would have to be retained in the beacon.

The spec encourages using ephemeral one-time-use ECDH keys, unless constrained by hardware.

[zonestc]

Ssl

[zonestc]

JAWAL NET FREE