<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>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>Section 2.3.1 PROBE Data: what signature verification, if any, is the requester required to perform?</div>Section 2.3.2 NEW Interest: why is [ECDH_Requester_PubKey] placed in the Interest name instead of in the Parameters?</div><div>Section 2.3.2 NEW Interest: how is 

[ECDH_Requester_PubKey] encoded? </div><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>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>Section 2.3.3 SELECT Interest: where is the Initialization Vector (IV) for AES placed?</div>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>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>Section 2.3.4 VALIDATE Interest: how many times may the requester retry VALIDATE? How does the requester know this limitation?</div><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><br></div><div>I'm also interested to see what you come up with in certificate revocation.</div><div><br></div><div>Yours, Junxiao</div></div></div></div></div></div></div>