<div dir="auto">Hi Zhiyi<br><div class="gmail_quote" dir="auto"><div dir="ltr"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Your mentioned attack scenario is valid and possible. Thank you for pointing that out!</div><div>Given the ndncert protocol is for two ends only, I think we can add a Diffie-Hellman process in the NEW command and its reply.</div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">I hope you are referring to ECDH, not classical Diffie-Hellman. Many IoT devices have binary code size constraint. Since ECDSA must be supported, it takes less binary code to add ECDH than to add classical DH.</div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>With the negotiated shared secret by DH, the requester and issuer can:</div><div>1. Use hmac to sign the request which is faster and fits IoT scenarios</div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">This is false. With low-cost crypto chip such as ECC508 (less than $1), IoT devices can easily access ECDH and ECDSA implemented by hardware.</div><div dir="auto">Also, NDNCERT is not just for IoT.</div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>2. Use key derived from the shared secret to AES encrypt the sensitive components and Data content (prevent Eve to see the PIN_E and all the other sensitive info)</div></div></blockquote></div><div dir="auto">Yes.</div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>On the other hand, I will update the email format to include the full certificate name and request id (each request instance has a unique ID)</div></div></blockquote></div><div dir="auto">Usability is a concern: user is going to neglect the request ID. There are two solutions:</div><div dir="auto">First, digest of the public key can be represented as graphics (e.g. a cat face with various colors and features). A client with GUI capability can display the graphics, and the user can compare the graphics with one generated by CA and embedded in the email.</div><div dir="auto">Second, the PIN code can be prefixed by the request ID. The email says "PIN code 777777-666666"; the client prompts "Enter PIN code: 777777-"; the user types "666666".</div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>I have already take the ndncert server offline. We will perform a major upgrade on ndncert protocol and ndncert codebase.</div></div></blockquote></div><div dir="auto">When can we see a preview of the new protocol?</div><div dir="auto"><br></div><div dir="auto">Yours, Junxiao</div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div>
</blockquote></div></div>