<div dir="ltr">
<div>Hi Zhiyi</div><div><br></div><div>Comments on revision 226dbac.</div><div><br></div><div><b>Major Changes<br></b></div>The term "users" should be replaced by "requesters" or "clients" to be consistent with terminology list.<div><br></div><div><b>Terminologies<br></b></div><div>Section title "terminologies" should be just "terminology". The singular form <a href="https://www.merriam-webster.com/dictionary/terminology" target="_blank">terminology</a> refers to a group of technical or special terms used in a subject, such as NDNCERT protocol. The plural form <a href="https://www.wordhippo.com/what-is/the-plural-of/terminology.html" target="_blank">terminologies</a> refers to several groups of terms used in multiple subjects.</div><div>Links for timestamp, version, and segment component types should point to <a href="https://named-data.net/publications/techreports/ndn-tr-22-2-ndn-memo-naming-conventions/" target="_blank">NDN-TR-0022 rev2</a>.<br></div><div>The NDN Testbed, as in, forwarding services, already supports signed Interest defined in NDN Packet Format v0.3 spec. The clause "before this format is officially supported by NDN Testbed" is inapplicable and should be removed.<br></div><div>Terms "parent namespace" and "sub namespace" need to be defined in this section. Their semantics are fuzzy in overview section.</div><div>Links to NDN Packet Format spec should use specific version <a href="https://named-data.net/doc/NDN-packet-spec/0.3/" target="_blank">https://named-data.net/doc/NDN-packet-spec/0.3/</a> , not "current".</div><div><br></div><div><b>Packet Specification</b></div><div>Every "phase" should be replaced by "step" or "Interest and Data" or "request and response".<br></div><div>Every TLV format specification needs to have <a href="https://tools.ietf.org/html/rfc5234" target="_blank">ABNF</a>.<br></div><div>"TLV Type number" should be written as "TLV-TYPE number (decimal)" and "TLV-TYPE number (hexadecimal)". Having both decimal and hexadecimal can greatly help programming and traffic trace analysis.<br></div><div><br></div><div><b>INFO</b><br></div><div>Since INFO Data packet is retrieved via RDR, the Interest format is defined by RDR and does not need to appear in NDNCERT protocol.<br></div><div>max-validity-period is defined to be "int value". Terminology list points this to NDN Packet Format, but it does not define how to encode "int value". If you mean "non negative integer", this has to be clarified either here or in terminology list.</div><div><br></div><div><b>PROBE<br></b></div><div>What happens if the CA cannot issue any certificate for the provided probe-parameter-value(s)? I suggest replying with a Data packet that has zero Name element. Alternatively, you'll have to define an error format.<br></div><div><b><br></b></div><div><b>PROBE redirect<br></b></div><div>Is it possible to receive redirects to multiple CAs? In NDNCERT-legacy, a requester can obtain guest certificates from a number of CAs.</div><div>Is it possible for the Data to contain both name prefixes and redirects?<br></div><div><div><div>Note: in order to let this revision proceed to implementation and deployment quickly, I strongly recommend deleting "PROBE redirect" and "PROBE privacy" section. They can be re-added in a future revision of the NDNCERT protocol.<br></div><div><br></div><div><b>NEW<br></b></div><div>challenge: how to specify multiple possible challenges?<br></div><div>salt: clarify that the AES key is AES-GCM-128 key, because this is the entropy from ECDH on P-256 curve.<br></div><div><br></div><div><b>RENEW</b></div><div>If RENEW is same as NEW, why not use the same verb?<br></div><div><br></div><div><b>CHALLENGE</b></div><div>To simplify protocol and implementations, consider merging "probe-parameter" and "challenge-parameter" into a single "parameter-key" TLV-TYPE, and merging "probe-parameter-value" and "challenge-parameter-value" into a single "parameter-value" 
TLV-TYPE

.</div><div>
<div>initial-vector: specify this to be fixed 12-byte IV that is more efficient in processing, see <a href="https://crypto.stackexchange.com/a/41610" target="_blank">this answer</a>.<br></div><div>AES-GCM supports AEAD. I suggest passing <Request_ID> as additional data while encrypting and decrypting the payload, which cryptographically binds the payload to this request.<br></div>

</div><div><br></div><div>Yours, Junxiao<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 19, 2020 at 6:53 PM Zhiyi Zhang <<a href="mailto:zhiyi@cs.ucla.edu" target="_blank">zhiyi@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi folks,<br><div dir="ltr"><div><br></div><div>I've updated the NDNCERT spec based on today's NFD call (Mar 19). </div><div>Regarding the error message part, I am sure there are error types that I missed. Please help to add more.</div><div><br></div><div><a href="https://github.com/named-data/ndncert/wiki/NDNCERT-Protocol-0.3" target="_blank">https://github.com/named-data/ndncert/wiki/NDNCERT-Protocol-0.3</a><br></div><div><br></div><div>Also, please feel free to share your comments/suggestions here.</div><div><br></div><div>Best,</div><div>Zhiyi</div></div><br>
</blockquote></div></div></div>

</div>