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

[Junxiao Shi]

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/20210205/a45e3fdb/attachment.html>