[Nfd-dev] [EXT]Re: Update on NDNCERT protocol

[Junxiao Shi]

Hi Zhiyi

Some comments are not adequately addressed in revision a106193.


>> *Terminologies*
>> Links for timestamp, version, and segment component types should point to NDN-TR-0022
>> rev2
>> <https://named-data.net/publications/techreports/ndn-tr-22-2-ndn-memo-naming-conventions/>
>> .
>>
> The link should say "NDN naming conventions", not "NDN name".

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.
>>
> This sentence is still not removed.

*Packet Specification*
>> Every TLV format specification needs to have ABNF
>> <https://tools.ietf.org/html/rfc5234>.
>>
> Why does this become an "ongoing issue"?
I can't further review the packet format until ABNF is added.

"TLV Type number" should be written as "TLV-TYPE number (decimal)" and
>> "TLV-TYPE number (hexadecimal)".
>>
> It still says "TLV Type". It should be "TLV-TYPE" to be consistent with
NDN Packet Format spec.
Also, all numbers should be assigned, not "tbd", in order for the spec to
be implementable.


>> *INFO*
>> Since INFO Data packet is retrieved via RDR, the Interest format is
>> defined by RDR and does not need to appear in NDNCERT protocol.
>>
> This is not done.

*PROBE redirect*
>>
> 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.
>>
> I agree with you. I will put these two extensions a lower priority.
>
Not "lower priority", but delete it altogether so that the spec can be
finalized.
Re-add them in a future version (e.g. v0.3.1).


>> *NEW*
>> challenge: how to specify multiple possible challenges?
>>
>
> Repeat the challenge TLV.
>
Please clarify this through ABNF.

*RENEW*
>> If RENEW is same as NEW, why not use the same verb?
>>
> Because they are for different purposes and indicate different operations
> to the CA.
>
I'm not convinced. Please further explain.
I strongly recommend deleting RENEW and REVOKE sections for this revision,
so that the spec can be finalized.
You can re-add these sections in v0.3.2.

*CHALLENGE*
>> 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 .
>>
> I see this becomes an "ongoing issue", so I'm adding this for discussion
on next NFD call.


> 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.
>>
> I realize that HKDF also has an "info" input parameter. <Request_ID>
should be used there too.

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