[Nfd-dev] Update on NDNCERT protocol

[Junxiao Shi]

Hi Zhiyi

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?
>

Having a segment component is future proof: the information in a CA profile
may exceed the optimal size of one segment.
RDR <https://redmine.named-data.net/projects/ndn-tlv/wiki/RDR> metadata has
a segment component for the same reason.

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).
>

RSA-OAEP is discouraged for new designs
<https://crypto.stackexchange.com/a/51615>.

NDNCERT, being a security protocol, should prioritize security properties
over bandwidth cost.
ECDH plus AES-GSM would provide better security properties that includes
forward secrecy.


> 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.
>

TLV evolvability guidelines should be followed by default, unless there's a
reason to opt out of TLV evolvability guidelines.


> 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.
>

There are two options.

First option is to include TLV-TYPE number for each item as part of the CA
profile.
The CA profile could say:
<ProbeDefinitions>
  <DescriptionEntry>
    <DescriptionKey>email</DescriptionKey>
    <DescriptionValue>1243</DescriptionValue>
  </DescriptionEntry>
  <DescriptionEntry>
    <DescriptionKey>full name</DescriptionKey>
    <DescriptionValue>3186</DescriptionValue>
  </DescriptionEntry>
<ProbeDefinitions>
This tells the requester what TLV-TYPE numbers to use.
The requester can then send:
<ProbeParameters>
  <1243>david.henson at contoso.com</1243>
  <3186>David Henson</3186>
</ProbeParameters>

Second option is to use DescriptionEntry structure in the PROBE Interest
packet.
<ProbeParameters>
  <DescriptionEntry>
    <DescriptionKey>email</DescriptionKey>
    <DescriptionValue>david.henson at contoso.com</DescriptionValue>
  </DescriptionEntry>
  <DescriptionEntry>
    <DescriptionKey>full name</DescriptionKey>
    <DescriptionValue>David Henson</DescriptionValue>
  </DescriptionEntry>
</ProbeParameters>

Comparing these two options:

   - First option makes PROBE Interest packet smaller.
   - Second option has less complexity in terms of binary code size.




> 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?=
>

ndncert-legacy allows the same email to request one of many name prefixes.
For example, david.henson at contoso.com can request:
/8=ndn/8=guest/8=david.henson%25contoso.com
/8=ndn/8=edu/8=arizona/8=%40GUEST/8=david.henson%25contoso.com
/8=ndn/8=edu/8=ucla/8=%40GUEST/8=david.henson%25contoso.com
and many other names.

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.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20200303/54e7a75c/attachment-0001.html>