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

[Junxiao Shi]

Hi Zhiyi

NDNCERT PROBE command uses name /CA/_PROBE, not /CA/_RPROBE.
The packet sample in pcap file is sending correct prefix according to
protocol, but your snippet is sending wrong prefix.

Yours, Junxiao

On Tue, Nov 12, 2019, 18:51 Zhiyi Zhang <zhiyi at cs.ucla.edu> wrote:

> Hi Junxiao,
>
> I tried the code but it seems that the Interest arrives at the CA, but did
> not trigger the filter match (I cannot see the log from this line
> https://github.com/named-data/ndn-cxx/blob/master/ndn-cxx/impl/face-impl.hpp#L209
> ).
> I set a breakpoint in my ndncert code in the onProbe function, but it's
> never triggered.
>
> Here is my client code (I modified your code):
>
> #include <ndn-cxx/interest.hpp>
> #include <ndn-cxx/face.hpp>
> #include <ndn-cxx/encoding/block.hpp>
> #include <ndn-cxx/util/string-helper.hpp>
>
> #include <iostream>
> #include <string>
>
> std::string pkt =
> "0571074208036e646e0803656475080475636c610806797566656e6708065f50524f42450220649503f51f30e5f9a3a76d6f1847bcce7208b64367a2459ac848ebfc91f47ed812000a046d1ddfd80c020f97241f7b22656d61696c223a22537573656e746572406461797265702e636f6d227d"
> ;
>
> ndn::Face face;
>
> int main() {
>   ndn::Block block(ndn::fromHex(pkt));
>   ndn::Interest interest(block);
>   auto param = interest.getApplicationParameters();
>   interest.setName(ndn::Name("/zhiyi/CA/_RPROBE"));
>   interest.setApplicationParameters(param);
>   face.expressInterest(interest, nullptr, nullptr, nullptr);
>   face.processEvents();
> }
>
>
> On the client side, here is what I got from the NDN log:
>
> 1573601811.702968 DEBUG: [ndn.Face] >I /zhiyi/CA/_RPROBE
> ndn.MaxSuffixComponents=1&ndn.MustBeFresh=true&ndn.InterestLifetime=3991&ndn.Nonce=3638500717
>
> Best,
> Zhiyi
>
> On Tue, Nov 12, 2019 at 10:02 AM Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
>> Hi Zhiyi
>>
>> Have you figured out why the CA isn't responding?
>> I attached packet samples so you can replay them onto your node.
>>
>> Yours, Junxiao
>>
>> On Tue, Nov 5, 2019 at 5:25 PM Junxiao Shi <shijunxiao at email.arizona.edu>
>> wrote:
>>
>>> Hi Zhiyi
>>>
>>> Sorry. but to be honest, I don't know why the client will have invalid
>>>> last component. (my clinet code simply runs setApplicationParameter(), no
>>>> more function calls).
>>>>
>>>
>>> I guess it's because I'm running the client from your personal repo
>>> <https://github.com/Zhiyi-Zhang/ndncert>, designed to work with
>>> ndn-cxx-0.6.6, which does not append ParametersDigestSha256Component.
>>> However, my other program appends ParametersDigestSha256Component
>>> properly, and I have verified against latest ndn-cxx that the digest is
>>> correct.
>>>
>>>
>>>
>>>> Regarding the CA does not reply, I guess it may be the JSON format
>>>> problem (if you generate the JSON on your own)?  I recalled in last
>>>> hackathon, Alex met the similar issue. They said some weird newlines are
>>>> added to the JSON file generated by the BOOST library.
>>>>
>>>
>>> According to RFC8259 section 2
>>> <https://tools.ietf.org/html/rfc8259#section-2>,
>>>
>>> Insignificant whitespace is allowed before or after any of the
>>> six structural characters.
>>>
>>> Therefore, it's not wrong to add "weird newlines", as they will be
>>> ignored by a decoder.
>>>
>>> ApplicationParameters element (including T,L,V) is:
>>>
>>> 0000   24 1f 7b 22 65 6d 61 69 6c 22 3a 22 53 75 73 65   $.{"email":"Suse
>>> 0010   6e 74 65 72 40 64 61 79 72 65 70 2e 63 6f 6d 22   nter at dayrep.com
>>> "
>>> 0020   7d                                                }
>>>
>>> The JSON payload is handwritten. It is not generated by BOOST library.
>>>
>>> Interpreting the TLV-VALUE using RFC8259
>>> <https://tools.ietf.org/html/rfc8259>, we can see that it represents a
>>> JSON object that contains a key "email".
>>>
>>> As specified in NDNCERT protocol:
>>>
>>> JSON format: The format depends on the probe of the configuration file.
>>> As an example, if we have "probe":"email:full-name", then the JSON file
>>> carried in the PROBE Interest will contains two attributes: email and
>>> full-name.
>>>
>>>
>>> As seen in /ndn/edu/ucla/yufeng/CA/_PROBE/INFO packet (frame 5 in packet
>>> sample
>>> <https://www.lists.cs.ucla.edu/pipermail/nfd-dev/2019-November/003861.html>),
>>> the CA expects PROBE parameters to have "email" key.
>>> Therefore, I believe my Interest satisfies the schema shown on the
>>> protocol page.
>>>
>>> Yours, Junxiao
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20191112/e1e58576/attachment-0001.html>