<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 3, 2020 at 9:34 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 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>1. sec 2.1.2 why we need version + segment components? I understand the use of version component but why bother segment component? What's the benefit of using these two rather than timestamp?</div></div></blockquote><div><br></div><div>Having a segment component is future proof: the information in a CA profile may exceed the optimal size of one segment.</div><div><a href="https://redmine.named-data.net/projects/ndn-tlv/wiki/RDR" target="_blank">RDR</a> metadata has a segment component for the same reason.</div></div></div></blockquote><div><br></div><div>but why not simply set a final block id in /<ca-prefix>/CA/INFO/version so that the requester can fetch more back?</div><div>we can omit the segment component for the first segment?</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 class="gmail_quote"><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>2. sec 2.1.2 yes I am considering RSA OAEP, the main reason for using RSA instead of the session key (e.g., ECDH) is the round trip -- ECDH requires an additional round trip to set up the session (which may be too costly for an informational query).</div></div></blockquote><div><br></div><div>RSA-OAEP is <a href="https://crypto.stackexchange.com/a/51615" target="_blank">discouraged for new designs</a>.</div><div><br></div><div>NDNCERT, being a security protocol, should prioritize security properties over bandwidth cost.</div><div>ECDH plus AES-GSM would provide better security properties that includes forward secrecy.</div></div></div></blockquote><div><br></div><div>I agree with you.</div><div>We should have session keys to support forward secrecy.</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 class="gmail_quote"><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>3. sec 2.1.4 do we need to consider the evolvability here? given it's an application layer protocol and all fields clearly defined.</div></div></blockquote><div><br></div><div>TLV evolvability guidelines should be followed by default, unless there's a reason to opt out of TLV evolvability guidelines.</div></div></div></blockquote><div><br></div><div>Hmm. I didn't see the reasons why NDNCERT needs to follow the evolvability.</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 class="gmail_quote"><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>4. sec 2.2.2 you suggested the type name be email and full name, do you expect them to be pre-defined as TLV types? If so, it's really a usability issue because different CAs may require totally different information for the probe.</div></div></blockquote><div><br></div><div>There are two options.</div><div><br></div><div>First option is to include TLV-TYPE number for each item as part of the CA profile.</div><div>The CA profile could say:</div><div><font face="monospace"><ProbeDefinitions></font></div><div><div><font face="monospace"> <DescriptionEntry></font></div><div><font face="monospace"> <DescriptionKey>email</DescriptionKey></font></div><div><font face="monospace"> <DescriptionValue>1243</DescriptionValue></font></div><div><font face="monospace"> </DescriptionEntry></font></div><div></div></div><div><font face="monospace"> <DescriptionEntry></font></div><div><font face="monospace"> <DescriptionKey>full name</DescriptionKey></font></div><div><font face="monospace"> <DescriptionValue>3186</DescriptionValue></font></div><div><font face="monospace"> </DescriptionEntry></font></div><div></div><div><font face="monospace"><ProbeDefinitions></font></div><div><div></div></div><div>This tells the requester what TLV-TYPE numbers to use.<br></div><div>The requester can then send:</div><div><font face="monospace"><ProbeParameters></font></div><div><font face="monospace"> <1243><a href="mailto:david.henson@contoso.com" target="_blank">david.henson@contoso.com</a></1243></font></div><div><font face="monospace"> <3186>David Henson</3186></font></div><div><font face="monospace"></ProbeParameters></font></div><div><br></div><div>Second option is to use DescriptionEntry structure in the PROBE Interest packet.</div><div><div><font face="monospace"><ProbeParameters></font></div><div><div><font face="monospace"> <DescriptionEntry></font></div><div><font face="monospace"> <DescriptionKey>email</DescriptionKey></font></div><div><font face="monospace"> <DescriptionValue><a href="mailto:david.henson@contoso.com" target="_blank">david.henson@contoso.com</a></DescriptionValue></font></div><div><font face="monospace"> </DescriptionEntry></font></div><div></div></div><div><font face="monospace"> <DescriptionEntry></font></div><div><font face="monospace"> <DescriptionKey>full name</DescriptionKey></font></div><div><font face="monospace"> <DescriptionValue>David Henson</DescriptionValue></font></div><div><font face="monospace"> </DescriptionEntry></font></div><div><font face="monospace"></ProbeParameters></font></div><div></div></div><div><br></div><div>Comparing these two options:</div><div><ul><li>First option makes PROBE Interest packet smaller.</li><li>Second option has less complexity in terms of binary code size.</li></ul></div></div></div></blockquote><div><br></div><div>Another possible solution is:</div><div>T:probe-parameter, L, V: first probe parameter</div><div>T:probe-parameter, L, V: second probe parameter</div><div>...</div><div>The value of probe parameters is listed in the same order as defined in CA profile.</div><div><br></div><div>Should the value type be defined also? if the value can be a string, an integer, or bytes.</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 class="gmail_quote"><div><br></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>5. sec 2.2.2. regarding multiple available names in PROBE reply, I don't think so? given it's not an important feature. And we may not want to bother CA to design a function to output multiple namespaces?=</div></div></blockquote><div><br></div><div>ndncert-legacy allows the same email to request one of many name prefixes.</div><div>For example, <a href="mailto:david.henson@contoso.com" target="_blank">david.henson@contoso.com</a> can request:</div><div><div><font face="monospace">/8=ndn/8=guest/8=david.henson%<a href="http://25contoso.com" target="_blank">25contoso.com</a></font></div><div></div></div><div><div><div><div><font face="monospace">/8=ndn/8=edu/8=arizona/8=%40GUEST/8=david.henson%<a href="http://25contoso.com" target="_blank">25contoso.com</a></font></div><div></div></div><div></div></div></div><div><div><div><font face="monospace">/8=ndn/8=edu/8=ucla/8=%40GUEST/8=david.henson%<a href="http://25contoso.com" target="_blank">25contoso.com</a></font></div><div></div></div><div></div></div><div>and many other names.</div></div></div></blockquote><div><br></div><div>Okay, fair enough. I will mention this in the spec.</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 class="gmail_quote"><div><br></div><div>Likewise, new NDNCERT should allow multiple names as well referrals to sub-CAs to appear in the PROBE reply, to preserve this feature of the existing system.</div><div><br></div><div>Yours, Junxiao</div></div></div>
</blockquote></div></div>