RE: Key Discovery draft

Use Case for multi keys on a single device

A home automation company (HA) installs a web enabled controller (UA) in Fred's house; this controller communicates with the installed automation devices around the home using a home area network (HAN) via secure messaging. The HA company embeds an RSA key pair and certificate (containing the serial number of the device) within each of it devices in the factory. Fred buys various devices and installs them in his home. The controller notices the devices as they are added and asks each device for its public key and certificates over the HAN.

Fred wants to perform a firmware update for all of his devices. On the UA Fred enters the request for firmware updates. The UA contacts the HA web service and asks for the updates. The HA web service therefore needs to send a secure message to each of Fred's connected devices. The HA web service communicates with the UA and asks for all the devices' RSA public keys. The HA web service verifies the associated certificates and send encrypted packets to the UA. The UA forwards the encrypted packet, via the HAN, to the corresponding device. The device decrypts the encrypted packet to get access to the firmware update.
>Michael

From: Mark Watson [mailto:watsonm@netflix.com]
Sent: Tuesday, July 09, 2013 11:32 AM
To: Nick Van den Bleeken
Cc: <public-webcrypto@w3.org>
Subject: Re: Key Discovery draft


On Mon, Jul 8, 2013 at 11:46 PM, Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com<mailto:Nick.Van.den.Bleeken@inventivegroup.com>> wrote:
Hi Mark,

First of all thank you for making Key Discovery API promises based just like the Web Crypto API!

For the other change, I'm not that convinced anymore that there should be only one key with a certain name (I know we discussed this at the FtF but...).

With the current spec someone can choose to deploy multiple keys with the same name and use a particular naming schema for the ID to distinguish the keys. (There is currently no query or list functionality so you need to know the name of the key upfront (you can't for example use a particular naming schema on the name to because then you don't know the exact name for the key)).

In a future version of the Key Discovery API we might add other 'attributes' that could be assigned to keys by the provisioner, which make it even more useful to return multiple keys (but currently implementers could choose to experiment with adding their own extension attributes).

A possible use case could be pre-provisioned keys issued by a particular issuer for a particular usage that have an X.509 certificate associated with them. But even without the certificate, when you are in a trusted environment only having the ID, which encodes the 'subject' will benefit by being able to return multiple keys for the same name.

Yep, I agree with all of the above. What we need, though, is very concrete use-cases and then we can decide if we should add new kinds of pre-provisioned key with attributes and the associated methods to query them.

For the moment, the only use-case we have is when the pre-provisioned keys are associated with the device. So there can be no ambiguity - the application knows exactly the names it is looking for and there is only one key for each name. We should keep the API simple until we have a concrete use-case motivating more complexity.

...Mark


Regards,

Nick


[cid:image001.png@01CE7E52.86F3B660][cid:image002.png@01CE7E52.86F3B660][cid:image003.png@01CE7E52.86F3B660]

On 09 Jul 2013, at 01:51, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:


All,

I updated the Key Discovery editor's draft to use Promises and to support retrieval of a single named key: https://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/Overview.html

(Yes, I know it should be Promise<any> in the IDL, but I don't think respec supports this ...)

There have been some requests for APIs to discover multiple keys, for which I'm waiting on a clear use-case.

...Mark


________________________________

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer