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

[Zhiyi Zhang]

Hi Junxiao,

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.
I think the new maintainer will send us an email soon.

Best,
Zhiyi

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

> Hi Zhiyi
>
> I have updated v0.3 specification.
>
> Regarding configuration: you do not need a configuration option for
> forwarding hint yet.
> 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.
> 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.
>
> Regarding deployment: although the testbed has only partial support for
> forwarding hint, the existing features are sufficient for this scheme to
> work.
> Thus, it is deployable today and does not need testbed upgrades.
>
> Yours, Junxiao
>
> On Tue, Mar 9, 2021 at 6:55 PM Zhiyi Zhang <zhiyi at cs.ucla.edu> wrote:
>
>> *External Email*
>> 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/20210319/69a8b13a/attachment.html>