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

[Junxiao Shi]

Hi Zhiyi

Thanks for your comments! I answered most of your questions in my latest
> commit to NDNCERT wiki. You can check the difference.
>

https://github.com/named-data/ndncert/wiki/NDNCERT-Protocol-new/14ef3ad5d26df066f55f648f28688bf0a405a87d
It looks better now.

Section 2.3.1 PROBE instructions: why is the local area network discovery
Interest named "/ndn/CA/PROBE/INFO", not "/localhop/CA/PROBE/INFO"?
Section 2.3.1 PROBE instructions: "this Interest can *discovery *the
available issuer(s) in the local network" has a typo.

Section 2.3.2 NEW Interest: how is  [ECDH_Requester_PubKey] encoded?
>>
>
> raw bytes without encoding.
>
A public key differs from a certificate. An EC public key is binary data.
It is 65 bytes
<https://github.com/yoursunny/esp8266ndn/blob/c1b282867afb52ac0ec9e64c86b8fda442cd1d9e/src/security/ec-public-key.hpp#L27>
in
uncompressed format, or 33 bytes
<https://github.com/kmackay/micro-ecc/blob/master/uECC.h#L196-L198> in
compressed format.
JSON can only represent string, number, object, array, true, false, and
null. JSON string is a sequence of zero or more Unicode characters. Binary
data is not Unicode.
So (1) are you using uncompressed or compressed format? (2) how do you
encode the binary data into a JSON value?

Section 2.3.3 CHALLENGE Interest: is the requester permitted to select one
challenge-id, and then select a different one?
Section 2.3.3 CHALLENGE Data: in "status" field, WAIT_DOWNLOAD is
unnecessary because the requester could skip DOWNLOAD step and fetch the
issued certificate from a repo instead. This status should be merged with
FINISHED.


>
>
>> Section 2.3.3 CHALLENGE Interest: how many times may the requester retry
>> CHALLENGE? How does the requester know this limitation?
>>
>
> According to the JSON "status" attribute in the replied Data. New
> description added in the latest commit.
>

I don't see the answer. There's no "status" code indicating the number of
retries have been exhausted and the requester must start over.


>
>
>> Section 2.3.3 CHALLENGE Interest: is there a time limit for the protocol?
>> Can a requester send CHALLENGE command several days after NEW command? How
>> does the requester know this limitation?
>>
>
> Don't have this information for now. In the current implementation of
> NDNCERT, the freshness time of challenge is decided by the challenge
> implementation.
> E.g., email challenge implementation requires a config file, where
> operators can set the freshness time there.
>

Can you update the a design document for the email challenge?
The existing document revision
https://github.com/named-data/ndncert/wiki/Email-Challenge/4c83b4b52c22f0bd6558731ad92493040c9768e3
is inconsistent with the new protocol.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20181120/2966fc4a/attachment-0001.html>