[Nfd-dev] [EXT]Re: Try NDNCERT (based on Interest-Data exchange) and get an NDN certificate today

[Zhiyi Zhang]

No. It has nothing to do with IP.
Since in NDNCERT, the certificate is named with the hierarchy, the
certificate is also under the prefix of CA.
This allows certificate fetch when it's a new certificate issued (thus the
requester's prefix has not been registered).
I know this cannot guarantee the Interest can reach the CA considering the
long prefix match and other scenarios like renew.
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.
This avoids the complexity of handling NLSR.

Best,
Zhiyi

On Thu, Feb 18, 2021 at 5:56 PM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Zhiyi
>
>
>
>>> Missing prefix registration of issued certificate
>>> Currently, it's impossible to retrieve an issued certificate unless the
>>> requester is directly connected to the CA host.
>>> 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.
>>> This prefix registration should be deleted when the certificate falls
>>> out of CA's issued certificate cache, which also withdraws the routing
>>> announcement.
>>>
>>
>> I think this is not an issue given the requester will directly contact
>> the CA?
>> After fetching the certificate, the requester should take responsibility
>> to make his certificate available to the network.
>>
>
> 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.
>
> 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.
>
> Case A: an end host could be IPv6-only but *suns* is IPv4-only, so that
> it's impossible to establish a direct connection. The end host would have
> to connect to udp6://ndnhub.ipv6.lip6.fr that is the only IPv6-enabled
> router, and rely on testbed routing to reach your CA.
>
> Case B: a recent measurement indicates that *suns* 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.
> https://atlas.ripe.net/measurements/29136922/#probes
>
> 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.
>
> Yours, Junxiao
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20210218/c96f20be/attachment-0001.html>