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

[Junxiao Shi]

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/20210309/808d586c/attachment.html>