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

[Zhiyi Zhang]

Sorry. This has been on my to-do list for two weeks but new urgent
todos keep showing up.
I will escalate it and do it today.

Best,
Zhiyi

On Wed, Feb 17, 2021 at 1:28 AM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Zhiyi
>
> It's been 12 days since I reported the implementation error. Have you
> updated the implementation and deployment?
>
> Yours, Junxiao
>
>
> On Fri, Feb 5, 2021, 14:52 Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
>> Hi Zhiyi
>>
>> Anyway, I've tested the service.
>>>> CA profile retrieval is working now.
>>>>
>>>> However, the NewResponse packet is encoded incorrectly - it contains an
>>>> unrecognized TLV element of critical type 0x9B.
>>>> Packet capture is attached.
>>>>
>>>> I can see that the offending line is here:
>>>>
>>>> https://github.com/Zhiyi-Zhang/ndncert/blob/cac27f1128883096c803d70b3c6d2cab50e1cd10/src/detail/new-renew-revoke-encoder.cpp#L91
>>>> The protocol doesn't have a Status field in this packet:
>>>>
>>>> https://github.com/named-data/ndncert/wiki/NDNCERT-Protocol-0.3/0d11d48d9ebee022eee71dee14f1342e0905a620#232-packet-format
>>>>
>>>
>>> I remembered we have this status field in the original doc. I guess it
>>> was removed in later edits.
>>> Anyway, do you think we should have this field in the NEW Data packet to
>>> indicate the current status?
>>>
>>
>> What are the possible values for the Status field in NewResponse? If
>> there's only one possible value, it's unnecessary to include this field.
>> Note that error conditions would cause the CA to generate an ErrorMsg
>> packet instead of NewResponse.
>>
>>
>>>
>>>>
>>>> Your decoding function is not implementing TLV evolvability correctly.
>>>>
>>>> https://github.com/Zhiyi-Zhang/ndncert/blob/cac27f1128883096c803d70b3c6d2cab50e1cd10/src/detail/new-renew-revoke-encoder.cpp#L102
>>>> If it encounters an unrecognized or out-of-order field of a critical
>>>> TLV-TYPE. However, the current decoding function would erroneously accept
>>>> any unrecognized or out-of-order fields of critical TLV-TYPEs.
>>>> All new NDN software is expected to properly implement TLV
>>>> evolvability. Please see ndn::Interest type in ndn-cxx for an example.
>>>>
>>>
>>> Okay. BTW, should there be some helper functions from NDN libraries to
>>> help with this?
>>> I feel it's not very developer-friendly considering the alternatives
>>> like JSON.
>>> Compared with forwarder development, maybe we should relax this
>>> requirement for application development?
>>>
>>
>> Yes, this functionality should ideally come from the library.
>> Two of my three libraries have *evolution-aware decoder* functionality.
>> See code samples here:
>>
>> https://github.com/yoursunny/NDNts/tree/a42b94a793e479aaeac163bec8d30e328875ea58/packages/tlv#evdecoder
>>
>> https://github.com/yoursunny/NDNph/blob/10e1b0ea77af890a0d7b8453060529924b7dadc8/src/ndnph/packet/interest.hpp#L412-L436
>> You can either ask the library maintainer of other libraries to add this
>> feature, or switch to one of my libraries.
>>
>> Nevertheless, it is your responsibility as application maintainer to
>> ensure the evolvability guidelines are in the application, especially for
>> NDNCERT that is a critical part of the NDN testbed infrastructure.
>>
>> Yours, Junxiao
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20210217/2e5afedc/attachment.html>