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

[Junxiao Shi]

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/3e674c31/attachment.html>