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

[Junxiao Shi]

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