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

[Junxiao Shi]

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.
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.
Section 2.3.1 PROBE Data: what signature verification, if any, is the
requester required to perform?
Section 2.3.2 NEW Interest: why is [ECDH_Requester_PubKey] placed in the
Interest name instead of in the Parameters?
Section 2.3.2 NEW Interest: how is  [ECDH_Requester_PubKey] encoded?
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?
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?
Section 2.3.3 SELECT Interest: where is the Initialization Vector (IV) for
AES placed?
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?
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".
Section 2.3.4 VALIDATE Interest: how many times may the requester retry
VALIDATE? How does the requester know this limitation?
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?

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

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