<div dir="ltr">Hi Junxiao,<div><br></div><div>Since I will graduate in 3 months and will be busy with my dissertation and defense, our lab is now deciding who will take over the NDNCERT project and discussing topics like whether the current C++ NDNCERT codebase requires a refactor.</div><div>I think the new maintainer will send us an email soon.</div><div><br></div><div>Best,</div><div>Zhiyi</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 9, 2021 at 4:24 PM Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Zhiyi<div><br></div><div>I have updated v0.3 specification.</div><div><br></div><div>Regarding configuration: you do not need a configuration option for forwarding hint yet.</div><div>When the CA is configured to serve the certificate on its own, the forwarding hint would be /ca-prefix/CA/DOWNLOAD, which is a sub-namespace within the CA's own announcement (i.e. /ca-prefix/CA). The last "DOWNLOAD" component is for identification purposes.</div><div>When the CA is configured to use an external repo, the forwarding hint configuration might be needed. However, there isn't a compatible repo that can serve issued certificates, so that it's too early to design this.</div><div><br></div><div>Regarding deployment: although the testbed has only partial support for forwarding hint, the existing features are sufficient for this scheme to work.</div><div>Thus, it is deployable today and does not need testbed upgrades.</div><div><br></div><div>Yours, Junxiao</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 9, 2021 at 6:55 PM Zhiyi Zhang <<a href="mailto:zhiyi@cs.ucla.edu" target="_blank">zhiyi@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p style="text-align:center"><font color="red"><strong>External Email</strong><br></font></p><div dir="ltr">Hi Junxiao,<div><br></div><div>That's a neat solution. I like this approach. </div><div>Accordingly, in the CA configuration, there should be an optional forwarding hint field. And this field does not to be included in the CA profile data packet.</div><div><br></div><div>The only issue (not a real issue) is to wait until the forwarding hint is enabled on the NDN testbed. But we don't need to wait for it. You or I can first update the spec accordingly.</div><div><br></div><div>Best,</div><div>Zhiyi</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 9, 2021 at 3:38 PM Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu" target="_blank">shijunxiao@email.arizona.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Zhiyi</div><div><br></div><div>The DOWNLOAD step, used in NDNCERT v0.2, is essentially an encapsulation.</div><div><br></div><div>In light of recent presentation about forwarding hint, I propose solving this problem with forwarding hint:</div><div><ol><li>In the CHALLENGE response packet, add an optional ForwardingHint field after IssuedCertName. The CA MAY specify a forwarding hint required to reach itself or its repo.</li><li>If the ForwardingHint field is present, the request MUST add this forwarding hint when it expresses an Interest to retrieve the issued certificate.</li><li>After the initial retrieval, publishing the certificate during usage remains the responsibility of the certificate owner i.e. requester.</li></ol></div><div>The benefit of this approach is that it decouples certificate retrieval from the certificate request transaction. For example, it enables the CA to delegate certificate publishing to a compatible repo.</div><div>In case the CA chooses to publish the certificate itself, it could specify /ca-prefix/CA/DOWNLOAD as the ForwardingHint delegation, so that the Interest would be forwarded to the CA program.</div><div><br></div><div>What do you think?</div><div><br></div><div>Yours, Junxiao</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 19, 2021 at 12:26 AM Zhiyi Zhang <<a href="mailto:zhiyi@cs.ucla.edu" target="_blank">zhiyi@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p style="text-align:center"><font color="red"><strong>External Email</strong><br></font></p><div dir="ltr">No. It has nothing to do with IP.<div>Since in NDNCERT, the certificate is named with the hierarchy, the certificate is also under the prefix of CA.</div><div>This allows certificate fetch when it's a new certificate issued (thus the requester's prefix has not been registered).</div><div>I know this cannot guarantee the Interest can reach the CA considering the long prefix match and other scenarios like renew.</div><div>That's why in the original NDNCERT design, I also designed a download step with the name: /CA-prefix/CA/download/request-id to get the certificate back.</div><div>This avoids the complexity of handling NLSR.</div><div><br></div><div>Best,</div><div>Zhiyi</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 18, 2021 at 5:56 PM Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu" target="_blank">shijunxiao@email.arizona.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Hi Zhiyi<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><br></div><div><font size="4">Missing prefix registration of issued certificate</font></div><div>Currently, it's impossible to retrieve an issued certificate unless the requester is directly connected to the CA host.</div>To solve this issue, the CA needs to perform a prefix registration for each certificate, and use Origin=0x41 in the registration. This would cause local NLSR to initiate a routing announcement on each certificate name, so that the certificate is reachable from anywhere on the network.<div>This prefix registration should be deleted when the certificate falls out of CA's issued certificate cache, which also withdraws the routing announcement.</div></div></div></blockquote><div><br></div><div>I think this is not an issue given the requester will directly contact the CA?</div><div>After fetching the certificate, the requester should take responsibility to make his certificate available to the network.</div></div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">No, you should not assume a direct IP connection. "The requester will directly contact the CA" should mean an Interest sent directly to the CA's name prefix, not a direct IP connection. In NDN we think about names, not host addresses.</div><div dir="auto"><br></div><div dir="auto">The CA profile packet should contain all the information needed to complete a certificate issuance procedure, and "IP address of the CA" is not in the CA profile.</div><div dir="auto"><br></div><div dir="auto">Case A: an end host could be IPv6-only but <i>suns</i> is IPv4-only, so that it's impossible to establish a direct connection. The end host would have to connect to udp6://<a href="http://ndnhub.ipv6.lip6.fr" target="_blank">ndnhub.ipv6.lip6.fr</a> that is the only IPv6-enabled router, and rely on testbed routing to reach your CA.</div><div dir="auto"><br></div><div dir="auto">Case B: a recent measurement indicates that <i>suns</i> does not accept packets from end hosts in Europe. Once again, they'll have to connect to another testbed router, and rely on testbed routing to reach your CA.</div><div dir="auto"><a href="https://atlas.ripe.net/measurements/29136922/#probes" target="_blank">https://atlas.ripe.net/measurements/29136922/#probes</a></div><div dir="auto"><br></div><div dir="auto">Case C: the requester could be on a web page using QUIC transport, and relies on a QUIC-to-NDN gateway to reach the testbed.</div><div dir="auto"><br></div><div dir="auto">Yours, Junxiao</div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>