[Nfd-dev] key rollover

[Gusev, Peter]

Hi all,

We talked with Zhehao today about key rollover and he mentioned that there was a proposal from Yingdi. However, I couldn’t find it. Does anyone know where to find it?
Any links on the materials covering the issue would be appreciated as well.

Currently, in ndncon I didn’t plan for writing any special roll-over mechanism/module and wanted to keep things simple (maybe not in a very elegant way - that’s what triggered our discussion about rollover with Zhehao today).

My idea right now is to have ndncon producer to generate new instance certificate every hour. This certificate is installed in the instance keychain, but is not set as a default certificate yet. Media stream packets are always signed with the default certificate. Once new certificate is generated, it is used for signing low-rate data generated by the discovery library. That way, consumers will be able to receive discovery data signed with the new certificate, fetch it according to the certificate chain, verify and have it cached locally. After some delay (60 seconds for instance) producer sets newly generated certificate as a default for the instance keychain and media data packets now will get signed with the new certificate. This won’t trigger fetching certificate on consumer sides as they already have this certificate fetched when they received discovery data earlier. That way, verification won’t trigger delays for the time-sensistive media streaming data.

I’m reaching out for your thoughts on this approach. How does this conflict with the key roll-over concept and whether we want to proceed with this approach (for now/for good)?

Thanks,

--
Peter Gusev
peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748<tel:+1%20213%205872748>
peetonn_ (skype)

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20161011/b3b43e12/attachment.html>