<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:15 AM Davide Pesavento <<a href="mailto:davidepesa@gmail.com">davidepesa@gmail.com</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">Zhiyi,<br>
<br>
On Tue, Mar 3, 2020 at 1:53 AM Zhiyi Zhang <<a href="mailto:zhiyi@cs.ucla.edu" target="_blank">zhiyi@cs.ucla.edu</a>> wrote:<br>
><br>
> Hi Junxiao,<br>
><br>
> Thanks for the feedback, here are some questions regarding your comments. Could you please help to clarify?<br>
><br>
> 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?<br>
> 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).<br>
<br>
I don't remember we discussed this RSA encryption during the calls.<br>
Can you clarify the use case?<br></blockquote><div><br></div><div>Right. I came up with this idea when I am writing down the spec (I also put a @TODO in the spec for discussion).</div><div>The rationale is: PROBE will generate names from inputs from the requester. The inputs may contain private information like UID, email address, full name, etc.</div><div>I am thinking we should encrypt the inputs.</div><div>There are two alternatives: </div><div>1. set up a TLS-like channel based on DH </div><div>2. insert an RSA encryption key into the CA profile so the requester can use that key to encrypt the input</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">
<br>
Two more comments, I only took a brief look:<br>
1/ What is the "salt" value used for? It shows up in the NEW Data<br>
content and nowhere else.<br></blockquote><div><br></div><div>Oh, you are right. I will add the key derivation function to the doc. I forgot that part.</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">
2/ "The ECC curve by default is prime256v1": you're not providing any<br>
mechanisms to specify the elliptic curve, so saying "by default"<br>
doesn't make much sense. Effectively only one curve is supported.<br></blockquote><div><br></div><div>Agree.</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">
<br>
Thanks,<br>
Davide<br>
</blockquote></div></div>