<div dir="ltr">Hi Jeff<div><br></div><div>Currently, the validator is responsible for collecting all certificates by sending Interests. This requires the certificates to be reachable, before prefix registration command can be fulfilled.</div><div><br></div><div>#<a href="https://redmine.named-data.net/issues/2766">2766</a> designs key-bundle, which shifts the responsibility of collecting certificates from the validator to the signer. The "ping server" should collect all certificates, and send them along with the prefix registration command (which would carry three certificates, /A /A/B /A/B/C).</div><div>This does not depend on you running a 24x7 server to publish your sub-certificates. This also has lower latency because there aren't multiple round-trips for certificates retrievals. The drawback is that every command carrying a key-bundle would be larger.<br></div><div><br></div><div>#<a href="https://redmine.named-data.net/issues/2237">2237</a> has a different proposal specifically for /localhop prefix registrations: NFD-RIB can direct Interest for certificate retrievals to the end host who sends the commands.</div><div>However, there's security concern in #<a href="https://redmine.named-data.net/issues/2237#note-3">2237-3</a>, and operational difficulty in #<a href="https://redmine.named-data.net/issues/2237#note-8">2237-8</a>.</div><div><br></div><div>Yours, Junxiao<br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 11, 2016 at 8:21 PM, Burke, Jeff <span dir="ltr"><<a href="mailto:jburke@remap.ucla.edu" target="_blank">jburke@remap.ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">







<div bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Hi Junxiao,
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Thanks.  I understand the mechanism now, based on your explanation, but not the motivation.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Why shouldn’t the device publishing /A/B/C be able to provide its cert (claimed proof of being able to publish in /A/B/C) to the upstream forwarder directly at the time of registration
 of /A/B/C (if necessary), rather than relying that some <i>other</i> node be up and available to provide its own certificate? 
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Jeff<u></u><u></u></span></p>
<p class="MsoNormal"><br></p></div></div></blockquote></div></div></div></div>