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

Zhiyi Zhang zhiyi at cs.ucla.edu
Mon Apr 6 17:21:20 PDT 2020


Hi Junxiao,

I just updated it.

>An alternative is truncating ValidityPeriod to what the CA allows.

I would like to keep it simple: a requester should follow the rules and
provide a valid validity period.

Best,
Zhiyi

On Fri, Apr 3, 2020 at 3:17 AM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Zhiyi
>
> Comments on revision 2cf5f47.
> Other than this protocol, it's time to start another document(s) to
> specify each of the common challenges.
>
> *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.
>
> Missing space before "signed Interest".
>
> *INFO step*
> Rename this section to "CA profile". It's a static Data packet, not a
> protocol round.
>
> I removed `certificate` from the CA profile because we can reuse
>> CertificateV2.
>>
> This is a bad idea. The top level TLV-TYPE for CertificateV2 is 0x06 Data,
> which could be ambiguous. It is also inconsistent with NEW step where a
> self-signed CertificateV2 is nested inside cert-request TLV.
>
> In the ABNF, simplify [*parameter-key] to *parameter-key .
> * denotes "repeat zero to infinity times".
>
> *PROBE step*
> The example should show a concrete example of CA prefix, not
> "<CA-Prefix>". Likewise, show a concrete example instead of
> "<ParameterDigest>".
>
> Link in "Name" should refer to a specific version of NDN Packet Format,
> not "current".
>
> Since PROBE response must contain at least one name, *Name should be
> 1*Name . Also see below.
>
> I also added `allow-longer-name` to the CA profile to indicate whether CA
>> allows longer identity name applications (apply /example/alice).
>>
> This does not belong in the CA profile, but should appear in the PROBE
> response along with each prefix.
>
>    - Not every CA needs a PROBE step. Without a PROBE step, there's no
>    such thing as "identity name".
>    - When a CA returns multiple allowable names in a PROBE response, it
>    could allow longer names for some prefixes but not others.
>
> The format could be:
> Content = CONTENT-TYPE TLV-LENGTH 1*probe-response
> probe-response = PROBE-RESPONSE-TYPE TLV-LENGTH Name [allow-longer-name]
> allow-longer-name = ALLOW-LONGER-NAME-TYPE TLV-LENGTH ;==0
>
> parameter-key TLV-TYPE is assigned to be 0x85 in INFO step, but it has a
> different number in this step. I'd suggest putting all TLV-TYPE assignments
> in the same table at the end, to avoid such errors.
>
> *NEW step*
> Can the requester request a certificate beyond the expiration time of the
> CA certificate?
> Generally it does not make sense, and should be disallowed.
> In other words: MAX(NOW, ca-certificate.NotBefore) <=
> cert-request.NotBefore <= cert-request.NotAfter <= MIN(NOW +
> max-validity-period, ca-certificate.NotAfter).
>
> Currently the CA rejects requests with out-of-bound ValidityPeriod. An
> alternative is truncating ValidityPeriod to what the CA allows.
>
> Can the CA return zero challenges in a NEW response? If it cannot, write
> as 1*challenge in ABNF.
>
> *CHALLENGE step*
> "initial vector" should be "initialization vector".
>
> Pronouns such as "his/her" and "he/she" could be simplified as "they",
> because the requester is not necessarily a person, but a computer program.
>
> Yours, Junxiao
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20200406/b2f9c28d/attachment.html>


More information about the Nfd-dev mailing list