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

[Zhiyi Zhang]

Hi Junxiao,

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

I also briefly answer your questions inline.

On Mon, Nov 19, 2018 at 7:13 AM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Zhiyi
>
> I notice that a new protocol is posted at
> https://github.com/named-data/ndncert/wiki/NDNCERT-Protocol-new
> (revision 0988979fc807dc0473ba3d7da4fa62a34a42669c).
> I have the following questions:
>
> Section 2.2: "In *warm start* scenarios, the challenge is usually
> single-direction: the challenge is used to verify a requester's identity or
> legality." and "In *warm start* scenarios, the challenge is supposed to
> be double-direction: the challenge is for the requester to verify the
> issuer and at the same time, the issuer can verify requester's identity.".
> This seems inconsistent.
>

Sorry it's my typo. Fixed in latest commit.


> Section 2.3.1 PROBE Interest: it's redundant to specify "the PlaceHolder
> is the digest value of Interest Parameters Field" because the presence of
> ParametersSha256DigestComponent is already required by NDN Packet Format
> v0.3.
>

Removed in the latest commit.


> Section 2.3.1 PROBE Data: what signature verification, if any, is the
> requester required to perform?
>

I added a new subsection for each signed Interest and Data to discuss how
to perform verification.


> Section 2.3.2 NEW Interest: why is [ECDH_Requester_PubKey] placed in the
> Interest name instead of in the Parameters?
>

You are right. In latest commit, I make the ECDH pub key into the JSON file
and the JSON file is in parameters.


> Section 2.3.2 NEW Interest: how is  [ECDH_Requester_PubKey] encoded?
>

raw bytes without encoding.


> Section 2.3.2 NEW Interest: what signature verification, if any, is the
> issuer required to perform?
> Section 2.3.2 NEW Data: why is "challenges" value encoded as a JSON string
> instead of a JSON array?
>

JSON array in latest commit.


> Section 2.3.2 NEW Data: what signature verification, if any, is the
> requester required to perform?
> Section 2.3.3 SELECT Interest: is an key derivation function
> <https://en.wikipedia.org/wiki/Key_derivation_function> applied on the
> ECDH premaster secret to derive the AES key?
>

No. The default ECDH for NDNCERT 0.2 is over curve p-256 and thus the
shared secret will be 256 bits, which can be directly used for AES-256
Encryption.


> Section 2.3.3 SELECT Interest: where is the Initialization Vector (IV) for
> AES placed?
>

I added a new section talking about the TLV format for encrypted payload.


> Section 2.3.3 SELECT Interest: what signature verification, if any, is the
> issuer required to perform?
> Section 2.3.3 SELECT Data: why are "selected-challenge" and "request-id"
> redundantly included in the JSON body?
>

Removed in latest commit.


> Section 2.3.3 SELECT Data: what signature verification, if any, is the
> requester required to perform?
> Section 2.3.4 VALIDATE Interest: is it really necessary to have distinct
> SELECT and VALIDATE steps? Some challenges can be performed in one step.
> For example, the issuer can distribute a printed PIN code that authorizes
> one certificate, and the PIN code can be sent directly with the SELECT
> Interest. Even if multiple rounds are needed, the semantics of SELECT and
> VALIDATE are largely the same. Thus, these two commands can be merged into
> a single command named "CHALLENGE" or "VALIDATE".
>

You are right. Merged in the latest commit.


> Section 2.3.4 VALIDATE Interest: how many times may the requester retry
> VALIDATE? How does the requester know this limitation?
>

According to the JSON "status" attribute in the replied Data. New
description added in the lates commit.


> Section 2.3.4 VALIDATE Interest: is there a time limit for the protocol?
> Can a requester send SELECT or VALIDATE 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.


> I'm also interested to see what you come up with in certificate revocation.
>

Revocation complicated and depends more on the CA instead of protocol
itself.
I will try to add my explaination and current status of our work there soon.

Best,
Zhiyi


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