[Nfd-dev] Who's serving application certificates?

Muhammad Hosain Abdollahi Sabet mhasabet at gmail.com
Tue Oct 11 08:05:02 PDT 2016


Lixia,

You mean in addition to LINK objects, NDNS will be responsible for storing
and maintaining keys? Then there may be different types of Interests for
querying LINKs or certificates? Currently we don't have *type* for
Interests.

Thanks,
Sabet
On Oct 11, 2016 5:59 PM, "Lixia Zhang" <lixia at cs.ucla.edu> wrote:

> Peter,
>
> thanks for the question.
> this should be one of those we are collecting for the retreat discussion.
> My 2 cents: whoever generates a cert should not be the only place to
> retrieve the cert.
> This seems related to the repo use question Patrick brought up already.
> We also have a new student looking into reviving NDNS.
>
> On Oct 10, 2016, at 12:57 PM, Gusev, Peter <peter at remap.ucla.edu> wrote:
>
> Hi architects,
>
> I have an "NDN applications eco-system”-related question which came up
> recently while preparing the new release of *ndncon.*
>
> Right now, according to previous discussions w/ Junxiao, Alex, I see the
> right way to manage application identity is the following:
>
> - on the first launch, application is supplied with the * signing
> identity* by the user (i.e. */ndn/edu/ucla/remap/peter*)
> - application creates long-lived *app identity and KSK certificate* (i.e.
> *…/peter/ndncon)*
> - application generates short-lived *instance identity and DSK
> certificate* (i.e. *…/peter/ndncon/instance-id*) and implements the
> certificate roll-over
> - application publishes data under instance identity namespace
> - application is responsible for serving *instance certificate*.
>
> That said, the question is -- is it the application who’s responsible for
> serving *app certificate* as well? Or is some kind of local NDN-app
> infrastructure (think, NDN repo) will be responsible (in the future?) for
> serving all app certificates installed on the end host?
> This seems to be related to the cases when several instances of the same
> app can be run simultaneously.
>
> Thanks,
>
> --
> Peter Gusev
>
> peter at remap.ucla.edu
> +1 213 5872748
> peetonn_ (skype)
>
> Software Engineer/Programmer Analyst @ REMAP UCLA
>
> Video streaming/ICN networks/Creative Development
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20161011/a23711b0/attachment.html>


More information about the Nfd-dev mailing list