<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 28, 2020 at 11:51 AM Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.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"><div dir="ltr"><div>Hi Zhiyi</div><div><br></div><div>These comments are on revision 5520432.</div><div><br></div><div><b>Terminology</b></div><div>"the TLV encoding of integer, string, and bytes all follow NDN TLV encoding", but none of these encodings is specified on the linked page.<br></div><div><br></div><div>Also, links to <a href="http://named-data.net" target="_blank">http://named-data.net</a> should use <a href="https://named-data.net" target="_blank">https://named-data.net</a> instead.</div></div></blockquote><div><br></div><div>Addressed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div><b>INFO step <br></b></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><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></blockquote></div></div></blockquote><div><br></div></div></div></blockquote><div>This is not that important? and for completeness, I would still keep it? </div></div></div></blockquote><div><br></div><div>Under RDR, the requester first expresses an Interest to retrieve the metadata with Interest:</div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>/<CA-Prefix>/CA/INFO/32=metadata</div><div>CanBePrefix=1</div><div>MustBeFresh=1</div></div></blockquote><div><div>The returned Data would contain the version of current CA profile. The requester then expresses another Interest to retrieve a specific version of CA profile:</div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>/<CA-Prefix>/CA/INFO/v=<i>VERSION</i>/seg=0<br></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>CanBePrefix=0</div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>MustBeFresh=0</div></div></blockquote><div><div>The Interest listed in NDNCERT spec does not conform to either of these Interests and would not be used by a consumer that follows RDR procedure.<br></div></div></div></blockquote><div><br></div><div>Addressed. I removed the Interest format.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div></div><div><br></div><div> <br></div><div></div></div><div><b>PROBE step</b></div><div>probe-parameter and probe-parameter-value TLV-TYPEs should be critical, as a CA that does not understand these TLV-TYPEs cannot process a PROBE Interest correctly.</div><div>Generally, you can assign critical TLV-TYPE numbers to everything in the initial protocol revision (i.e. this version), and decide whether to use critical or non-critical for new additions in the future.</div></div></blockquote><div><br></div><div>The PROBE can be empty? if the CA ask the requester to get an available name through PROBE but does not require any parameters?</div><div>hmm, maybe we shouldn't consider this scenario.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div><b>NEW step</b></div><div>ecdh-pub has 67 octets. How is this calculated?</div><div>I used the following code to generate ECDH public key on P-256 curve and export as raw uncompressed format, and it is 65 octets:</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font face="monospace">crypto.subtle.generateKey({name:"ECDH",namedCurve:"P-256"},false,["deriveKey"])</font></div><div><font face="monospace">  .then(({publicKey})=>crypto.subtle.exportKey("raw",publicKey))</font></div><div><font face="monospace">  .then(console.log)</font></div></blockquote><div><br></div><div>The link to "ndn certificate" should (1) use "NDN" instead of "ndn" (2) link to specific document version instead of "current".</div></div></blockquote><div><br></div><div>Addressed.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>In ABNF of Data format, "ApplicationParameters" should be "Content".</div></div></blockquote><div><br></div><div>Addressed. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>In Data format, request-id is defined as 8OCTET.</div><div>Assuming it is the same thing as <Request_ID>, this conflicts with Terminology section that defines it as one name component.</div><div>A name component needs to specify its TLV-TYPE.</div></div></blockquote><div><br></div><div>Addressed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>The status field is defined but unused. I think this field is unnecessary in this step.</div></div></blockquote><div><br></div><div>Addressed. I removed it. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>HKDF needs <a href="https://developer.mozilla.org/en-US/docs/Web/API/HkdfParams" target="_blank">three parameters</a>: hash, salt, info.</div><div>The hash function is not specified in the protocol.</div></div></blockquote><div><br></div><div>Addressed. SHA256. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div><b>CHALLENGE step</b></div><div>The initial-vector for AES-GCM-128 is 12 octets, not 16 octets. Also, in ABNF, it should be written as <font face="monospace">12OCTET</font>, not <font face="monospace">12OCTETS</font>.</div></div></blockquote><div><br></div><div>Addressed.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>In ABNF, you are missing a definition of what's the object prior to encryption:</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font face="monospace">PLAINTEXT =</font></div><div><font face="monospace">  selected-challenge</font></div><div><font face="monospace">  1*(challenge-parameter challenge-parameter-value)</font></div></blockquote><div>The above is for the Interest payload. Data payload needs a similar definition.</div></div></blockquote><div><br></div><div>Addressed.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>issued-cert-name is a full name, so it should be:</div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font face="monospace">issued-cert-name = ISSUED-CERT-NAME-TYPE TLV-LENGTH Name</font></div></blockquote></div><div>instead of *OCTET.</div></div></blockquote><div><br></div><div>Addressed.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div><b>Certificate Application Procedure</b></div><div>Does the CA start the challenge timeout clock since sending NEW Data or since receiving the first CHALLENGE Interest?</div><div>If the former: how can the requester know how long does it have to select and complete the challenge?</div><div>If the latter: it could be insecure because a requester could send a NEW Interest and wait for a long time before starting CHALLENGE, forcing the CA to hold onto the AES session key for a long time.</div></div></blockquote><div><br></div><div>Addressed.<br></div><div><br></div><div>Best,</div><div>Zhiyi</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Yours, Junxiao</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div></div>