<div><div dir="auto">Hi Haitao</div><div dir="auto"><br></div><div class="gmail_quote"></div></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Previously, I used this tool <a href="https://github.com/yoursunny/ndn6-tools/blob/master/remote-register-prefix.md" target="_blank">remote-register-prefix</a> (on Linux machine) and use interest "/localhop/nfd/rib/register/<control parameter>" (on Android) to register back route on NDN testbed edge router, the signing identity/key/certificate (/org/openmhealth/<user-id>) was issued by NDNFit trust anchor (/org/openmhealth); however, it doesn't work any more.</div></div></blockquote></div></div><div><div class="gmail_quote"><div dir="auto">I'm unaware of testbed configuration change affecting this in past 3 months.</div><div dir="auto">It shouldn't have worked previously. </div></div></div><div><div class="gmail_quote"><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:12.8px">I believe it's because the localhop security policy was changed (i.e., localhop_security field of nfd.conf was changed), so only interests signed by identity/key/certificate that can be tracked back to NDN testbed trust anchor could register back route on NDN testbed successfully. It this true, or is there another reason?</div></div></blockquote></div></div><div><div class="gmail_quote"><div dir="auto">Yes, the signing certificate must be issued from the testbed root.</div></div></div><div><div class="gmail_quote"><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:12.8px"></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">If my suspicion is true, could you help to manually issue a cert to NDNFit trust anchor using NDN testbed trust anchor (or could you grant me the privilege to do so), so that my remote register interest can be verified?</div></div></blockquote></div></div><div><div class="gmail_quote"><div dir="auto">No, because the configuration enforces hierarchical certificate names. You can sign /org/openmhealth/haitao with /ndn/edu/ucla/cs/haitao, but it wouldn't be trusted. See <a href="https://yoursunny.com/t/2016/ndncert/" target="_blank">https://yoursunny.com/t/2016/ndncert/</a> "can I impersonate as Google with my intermediate CA" section.</div></div></div><div><div class="gmail_quote"><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:12.8px">I want to manually do this because NDNFit trust anchor was not bound with an email. Another option is to replace NDNFit trust anchor with an identity/key/certificate that is bound with an email (we can create a new email account). I prefer the former choice as we want to keep the identity name "/org/openmhealth".</div><div style="font-size:12.8px"></div></div></blockquote></div></div><div><div class="gmail_quote"><div dir="auto">You don't have to change anything in your application's trust model or trust anchor. You just need a second certificate on each end host that is issued from testbed root.</div><div dir="auto">You will be able to register and readvertise /org/openmhealth/haitao with a testbed-issued certificate for now (until <a href="https://redmine.named-data.net/issues/2856">https://redmine.named-data.net/issues/2856</a> is implemented; I abuse this a lot in my apps so obviously I would not push for 2856 despite it's approved long ago, but I couldn't reject a patch if someone implements it). Eventually, you could only register the prefix same as testbed identity, and you'll have to reach /org/openmhealth/haitao using a forwarding hint.</div><div dir="auto"><br></div><div dir="auto">Also, you should not issue certificates to other users from your email-verified certificate as intermediate CA. I asked testbed operations about this in 2013 and I'm told that I would get into trouble if my end user abuses the testbed.</div><div dir="auto">In other words, if each end host needs a testbed certificate, they should separately request from ndncert system rather than issued from your intermediate CA. You can automate the email part, but it would still be a big headache because the issurance delay of up to 24 hours.</div><div dir="auto">The new ndncert system for certificate v2 seems to only support email at launch. I wish they can have Twitter or OpenID authentication, and immediate issurance.</div><div dir="auto"><br></div><div dir="auto">Yet another solution is to use the same trick as HomeCam <a href="https://yoursunny.com/t/2017/homecam-NDN-prefix/">https://yoursunny.com/t/2017/homecam-NDN-prefix/</a> .</div><div dir="auto">You can deploy a server that holds a testbed certificate, and end hosts only have openmhealth certificate. Whenever an end host wants to register /org/openmhealth/haitao, it sends an Interest which is forwarded to your server. Your server should then sign a registration command using its testbed certificate, encrypt it using end host's openmhealth public key, and return it in the Data payload. The end host can decrypt the payload to get the registration command Interest, and send out the Interest.</div><div dir="auto">This avoids the complexity of adding a second certificate on each end host, but you'll need the server.</div><div dir="auto"><br></div><div dir="auto">Yours, Junxiao</div></div></div>