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

[Zhiyi Zhang]

Hi Junxiao,

That's a neat solution. I like this approach.
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.

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.

Best,
Zhiyi

On Tue, Mar 9, 2021 at 3:38 PM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Zhiyi
>
> The DOWNLOAD step, used in NDNCERT v0.2, is essentially an encapsulation.
>
> In light of recent presentation about forwarding hint, I propose solving
> this problem with forwarding hint:
>
>    1. 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.
>    2. If the ForwardingHint field is present, the request MUST add this
>    forwarding hint when it expresses an Interest to retrieve the issued
>    certificate.
>    3. After the initial retrieval, publishing the certificate during
>    usage remains the responsibility of the certificate owner i.e. requester.
>
> 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.
> 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.
>
> What do you think?
>
> Yours, Junxiao
>
> On Fri, Feb 19, 2021 at 12:26 AM Zhiyi Zhang <zhiyi at cs.ucla.edu> wrote:
>
>> *External Email*
>> 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/20210309/20e7d0c7/attachment-0001.html>