<div dir="ltr">Hi Junxiao,<div><br></div><div>Thanks for your comments! I answered most of your questions in my latest commit to NDNCERT wiki. You can check the difference.</div><div><br></div><div>I also briefly answer your questions inline.</div><div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 19, 2018 at 7:13 AM Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Zhiyi<div><br></div><div>I notice that a new protocol is posted at <a href="https://github.com/named-data/ndncert/wiki/NDNCERT-Protocol-new" target="_blank">https://github.com/named-data/ndncert/wiki/NDNCERT-Protocol-new</a> (revision 0988979fc807dc0473ba3d7da4fa62a34a42669c).</div><div>I have the following questions:</div><div><br></div><div>Section 2.2: "In <u>warm start</u> scenarios, the challenge is usually single-direction: the challenge is used to verify a requester's identity or legality." and "In <u>warm start</u> 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.<br></div></div></div></div></div></div></div></blockquote><div><br></div><div>Sorry it's my typo. Fixed in latest commit.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>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.<br></div></div></div></div></div></div></div></blockquote><div><br></div><div>Removed in the latest commit.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div>Section 2.3.1 PROBE Data: what signature verification, if any, is the requester required to perform?</div></div></div></div></div></div></div></div></blockquote><div><br></div><div>I added a new subsection for each signed Interest and Data to discuss how to perform verification.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Section 2.3.2 NEW Interest: why is [ECDH_Requester_PubKey] placed in the Interest name instead of in the Parameters?</div></div></div></div></div></div></div></blockquote><div><br></div><div>You are right. In latest commit, I make the ECDH pub key into the JSON file and the JSON file is in parameters.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Section 2.3.2 NEW Interest: how is 

[ECDH_Requester_PubKey] encoded? </div></div></div></div></div></div></div></blockquote><div><br></div><div>raw bytes without encoding.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Section 2.3.2 NEW Interest: what signature verification, if any, is the issuer required to perform?<br>Section 2.3.2 NEW Data: why is "challenges" value encoded as a JSON string instead of a JSON array?</div></div></div></div></div></div></div></blockquote><div><br></div><div>JSON array in latest commit.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Section 2.3.2 NEW Data: what signature verification, if any, is the requester required to perform?</div><div>Section 2.3.3 SELECT Interest: is an <a href="https://en.wikipedia.org/wiki/Key_derivation_function" target="_blank">key derivation function</a> applied on the ECDH premaster secret to derive the AES key?</div></div></div></div></div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Section 2.3.3 SELECT Interest: where is the Initialization Vector (IV) for AES placed?</div></div></div></div></div></div></div></blockquote><div><br></div><div>I added a new section talking about the TLV format for encrypted payload.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Section 2.3.3 SELECT Interest: what signature verification, if any, is the issuer required to perform?<br><div>Section 2.3.3 SELECT Data: why are "selected-challenge" and "request-id" redundantly included in the JSON body?</div></div></div></div></div></div></div></blockquote><div><br></div><div>Removed in latest commit.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div>Section 2.3.3 SELECT Data: what signature verification, if any, is the requester required to perform?</div>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".</div></div></div></div></div></div></div></blockquote><div><br></div><div>You are right. Merged in the latest commit.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Section 2.3.4 VALIDATE Interest: how many times may the requester retry VALIDATE? How does the requester know this limitation?</div></div></div></div></div></div></div></blockquote><div><br></div><div>According to the JSON "status" attribute in the replied Data. New description added in the lates commit.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>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?</div></div></div></div></div></div></div></blockquote><div><br></div><div>Don't have this information for now. In the current implementation of NDNCERT, the freshness time of challenge is decided by the challenge implementation.</div><div>E.g., email challenge implementation requires a config file, where operators can set the freshness time there.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>I'm also interested to see what you come up with in certificate revocation.</div></div></div></div></div></div></div></blockquote><div><br></div><div>Revocation complicated and depends more on the CA instead of protocol itself.</div><div>I will try to add my explaination and current status of our work there soon.</div><div><br></div><div>Best,</div><div>Zhiyi</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>Yours, Junxiao</div></div></div></div></div></div></div>
</blockquote></div></div></div>