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

Junxiao Shi shijunxiao at email.arizona.edu
Tue Apr 14 05:05:50 PDT 2020


Hi Zhiyi

Comments on revision 99ed1b3.


*Terminology*"the TLV encoding of integer, string, and bytes all follow NDN
TLV encoding", but none of these encodings is specified on the linked page.
This is the fourth time I point out the same problem, and it's still not
fixed.

In "we call /example/alice a child namespace", "child" should be "sub",
because there's only definition of "sub namespace" and "child namespace"
was never defined.

"SignatureTimeStamp" should be "SignatureTime".

* All strings are specified as UTF 8 encoded
>
This should appear in the Terminology section. Other sections do not need
to repeat "UTF-8".

*CA profile*
"The profile is kept in a Data packet" is inaccurate, because the CA
profile could be segmented.
It should say: The CA profile is published in Data packets as a segmented
object following NDN naming conventions.

"A CA INFO Data packet" should be "CA profile Data packets".

*PROBE step*
In the example, URI representation of ParametersSha256DigestComponent is
incorrect.
In the example, Data name does not satisfy Interest name.

*NEW step*
"cert-request.NotBefore >= Max(NOW, ca-certificate.NotBefore)" is
problematic.
Assuming requester and issuer has synchronized clocks:

   1. Requester generates a cert-request at 08:00:01 UTC. Normally, the
   requester would put 08:00:01 as NotBefore.
   2. Issuer receives the NEW request at 08:00:02 UTC. According to the
   above rule, this NEW request is invalid.

To workaround this issue, the requester would have to increment NotBefore
to account for network latency, which complicates requester implementation.
I'd suggest relaxing this rule to "cert-request.NotBefore >= Max(NOW - 60s,
ca-certificate.NotBefore)", so that the requester does not have to
increment NotBefore.
Moreover, it's necessary to specify that timestamp rules are checked while
the issuer processes a NEW request, and it is not checked while issuing a
certificate.

"The L should be 12 bytes (128 bit)" is inconsistent. 12 bytes = 96 bits.
128 bits = 16 bytes.

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


More information about the Nfd-dev mailing list