<div dir="auto"><div dir="auto">Hi Zhiyi</div><div dir="auto"><br></div><div dir="auto">I read the code. I see that there's a cachedCertificates structure in the CA profile and it can serve both the CA profile and the issued certificates.</div><div dir="auto"><a href="https://github.com/Zhiyi-Zhang/ndncert/blob/276ba786afc52d404188f6c568ebc735e33c5d9b/tools/ndncert-ca-server.cpp#L132">https://github.com/Zhiyi-Zhang/ndncert/blob/276ba786afc52d404188f6c568ebc735e33c5d9b/tools/ndncert-ca-server.cpp#L132</a></div><div dir="auto"><br></div><div dir="auto">A brief read of this code indicates two problems:</div><div dir="auto">1. cachedCertificates would grow indefinitely until the CA runs out memory.<br></div><div dir="auto">2. After a successful challenge, issued-cert-name contains implicit digest and the client would be retrieving the certificate with an Interest that carry the implicit digest, but the producer code can only handle Interest with exact name.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">From what I can tell, there are two instances of repo-ng running on suns.</div><div dir="auto">The first instance has command prefix /localhost/repo-ng.</div><div dir="auto">The second instance has command prefix /localhost/repo-ng-2.</div><div dir="auto">You can find their configuration in <a href="https://github.com/WU-ARL/NDN_Ansible">https://github.com/WU-ARL/NDN_Ansible</a> repository, roles/repo-ng/templates.</div><div dir="auto"><br></div><div dir="auto">One concerning thing is that, the first repo-ng instance is registering the prefix /ndn/CA, same as your CA. A likely cause is that, your CA program uses TCP bulk insertion to ask repo-ng to publish the CA profile. The registration-subset=3 in <a href="https://github.com/WU-ARL/NDN_Ansible/blob/da31ed28c65c1e94a688070fc9be4ae74e4f6645/roles/repo-ng/templates/repo-ng.conf.j2#L7">https://github.com/WU-ARL/NDN_Ansible/blob/da31ed28c65c1e94a688070fc9be4ae74e4f6645/roles/repo-ng/templates/repo-ng.conf.j2#L7</a> causes the repo to register /ndn/CA. This could lead to forwarding problems.</div><div dir="auto"><br></div><div dir="auto">I think you need another instance of repo-ng with registration-subset=0.</div><div dir="auto">Or you can stick with cachedCertificates but you need to delete the CA profile packet from that repo-ng instance.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">You don't need to worry about certificate publishing after the client has retrieved the certificate. It is producer's responsibility to publish their certificates.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Regarding PyRepo: it's not running on suns. Even if you install it, it's unusable for certificate publishing:</div><div dir="auto">1. While PyRepo supports the same TCP bulk insertion protocol, it lacks prefix registration feature - it would register the root prefix "/", but the certificate name could match a longer prefix in the network.</div><div dir="auto">2. The only way to make PyRepo register a more specific prefix is to use its pseudo pubsub API. You could use this, but you'll have to integrate this protocol in the CA program. Good news is, the protocol is well document. Bad news is, it's fairly complicated.</div><div dir="auto">3. PyRepo will not answer any Interest with implicit digest. It only supports prefix and exact names. Read <a href="https://github.com/UCLA-IRL/ndn-python-repo/blob/fc831b9d60fc5feeae438895f9d5ed8d2a80a27f/ndn_python_repo/storage/storage_base.py#L96">https://github.com/UCLA-IRL/ndn-python-repo/blob/fc831b9d60fc5feeae438895f9d5ed8d2a80a27f/ndn_python_repo/storage/storage_base.py#L96</a> and you'll know why.</div><div dir="auto"><br></div><div dir="auto">Thus, don't bother with PyRepo. Stick with repo-ng or cachedCertificates.</div><div dir="auto"><br></div><div dir="auto">Yours, Junxiao</div><div dir="auto"><br></div><div dir="auto"><br style="font-family:sans-serif"><div style="font-family:sans-serif" class="elided-text" dir="auto"><div dir="ltr">On Wed, Jan 20, 2021, 23:16 Zhiyi Zhang <<a href="mailto:zhiyi@cs.ucla.edu">zhiyi@cs.ucla.edu</a>> wrote:<br></div><blockquote 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">With the current NDNCERT implementation, the certificate will still be fetched and installed on the local keychain.<div>However, you are right in the sense that, the certificate cannot be fetched asynchronously after the NDNCERT client command ends.</div><div><br></div><div>BTW, shouldn't Repe be installed on all testbed nodes through the operator?</div><div><br></div><div>Best,</div><div>Zhiyi </div></div><br><div class="elided-text"><div dir="ltr">On Wed, Jan 20, 2021 at 8:08 PM Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>> wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>Hi Zhiyi</div><div dir="auto"><br></div><div dir="auto">It doesn't make sense to run NDNCERT without a repo.</div><div dir="auto"><br></div><div dir="auto">1. CA profile is not retrievable, so that client cannot initiate.</div><div dir="auto">2. Issued certificate is not retrievable, so that client cannot finish.</div><div dir="auto"><br></div><div dir="auto">Yours, Junxiao</div></div></blockquote></div></blockquote></div></div><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Wed, Jan 20, 2021, 23:13 Lixia Zhang <<a href="mailto:lixia@cs.ucla.edu">lixia@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><p style="text-align:center"><font color="red"><strong>External Email</strong><br></font></p><br><div><blockquote type="cite"><div>On Jan 20, 2021, at 7:38 PM, Zhiyi Zhang <<a href="mailto:zhiyi@cs.ucla.edu" target="_blank" rel="noreferrer">zhiyi@cs.ucla.edu</a>> wrote:</div><br><div><div dir="ltr"><div>Yeah. I found the repo is not running on the Suns: ERROR: Cannot publish certificate to repo-ng (Connection refused)</div><div><br></div><div>@Lixia do you know who should I contact to deploy the repo? and which repo should be used?</div></div></div></blockquote><br><div><div dir="ltr"><div>I dont think people are using repo-ng anymore?</div><div>should be python repo?</div><div>I copied Zhaoning and Zixuan here, both should know the answer</div><div><br></div><div><br></div></div></div><blockquote type="cite"><div><div dir="ltr"><div>I just bring back the NDNCERT without the parameter to publish to the repo. After people figure out the repo deployment, I will update the parameter used in NDNCERT service.</div><div><br></div><div>Best,</div><div>Zhiyi</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 20, 2021 at 11:11 AM Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu" target="_blank" rel="noreferrer">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>As you mentioned on the 2021-01-15 NFD call, you have updated the deployment to use 2019 Naming Convention.</div><div>However, I'm now unable to retrieve the CA profile - the CA is not responding at all.</div><div><br></div><div><span style="font-family:monospace">$ ndnpeek -Pf /ndn/CA/INFO/32=metadata<br>$ echo $?<br>3</span></div><div><br></div><div>Wireshark and NFD counters indicate that the Interest has arrived on <a href="http://suns.cs.ucla.edu/" target="_blank" rel="noreferrer">suns.cs.ucla.edu</a>, but there's no response.<br></div><div><br></div><div>Yours, Junxiao<br></div></div>
</blockquote></div>
</div></blockquote></div><br></div></blockquote></div></div>