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

[Junxiao Shi]

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/47f60b08/attachment.html>