[Nfd-dev] KEY in certificate names

[Junxiao Shi]

Hi Peter

This question does not belong to nfd-dev, because it relates to trust model design and not NFD.
I will forward the message to another mailing list and CC you.

NFD’s automatic prefix propagation feature will use the shortest identity available in the KeyChain, which is /ndn/edu/ucla/remap/mrfoo in your example.
Longer, application generated identities do not affect NFD operations.

Yours, Junxiao

> On Mar 30, 2016, at 2:14 PM, Gusev, Peter <peter at remap.ucla.edu> wrote:
> 
> Thanks! this clarifies a bit…
> 
> i think it’s a good time to ask of the “canonical” way applications should behave in terms of generating certificates/identities.
> 
> here’s how I see it now (with the example of user “mrfoo” form remap institution):
> 
> • User gets testbed certificate (which reflects her identity - can I say that?):
> –/ndn/edu/ucla/remap/mrfoo
> • his public key is:
> –/ndn/edu/ucla/remap/mrfoo/ksk-12345…
> 
> • user launches app for the first time and (based on user’s identity) it generates “app identity” for signing instance certificates:
> –/ndn/edu/ucla/remap/mrfoo/ndncon
> • app’s public key and certificate:
> –/ndn/edu/ucla/remap/mrfoo/ndncon/ksk-<timestamp>
> –/ndn/edu/ucla/remap/mrfoo/ndncon/KEY/ksk-<timestamp>/ID-CERT
> 
> • app uses app certificate to create an “instance identity”:
> –/ndn/edu/ucla/remap/mrfoo/ndncon/instance<timestamp>
> • app instance public key and cert:
> –/ndn/edu/ucla/remap/mrfoo/ndncon/instance<timestamp>/dsk-<timestamp>
> –/ndn/edu/ucla/remap/mrfoo/ndncon/instance<timestamp>/KEY/dsk-<timestamp>/ID-CERT
> 
> • app instance registers prefix and serves data under this prefix:
> –/ndn/edu/ucla/remap/mrfoo/ndncon/instance<timestamp>
> 
> • app’s data packets are signed with instance certificate and keylocator is:
> –/ndn/edu/ucla/remap/mrfoo/ndncon/instance<timestamp>/KEY/dsk-<timestamp>/ID-CERT
> 
> • app adds instance certificate to its’ memory content cache so that it can answer incoming interests with keylocator name 
> 
> looking forward for your feedback. 
> 
> Thanks, 
> 
> -- 
> Peter Gusev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160330/87841c1f/attachment.html>