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

Zhiyi Zhang zhiyi at cs.ucla.edu
Tue Nov 12 15:51:16 PST 2019


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/8afc3424/attachment.html>


More information about the Nfd-dev mailing list