[Nfd-dev] Try NDNCERT (based on Interest-Data exchange) and get an NDN certificate today

[Zhiyi Zhang]

Hmm. I agree it's more compactly but we have to modify the Data
packet format which is non-trivial?

Best,
Zhiyi

On Fri, Oct 5, 2018 at 2:10 PM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Zhiyi
>
> Does this mean the signer must put the extension into EVERY signed
> Interest or Data packet it generates?
> If so, why not extend the KeyLocator, as it will be encoded more compactly?
>
> Yours, Junxiao
>
> On Fri, Oct 5, 2018 at 4:21 PM, Zhiyi Zhang <zhiyi at cs.ucla.edu> wrote:
>
>> We don't need to put the hint into the keylocator and change the Data
>> packet format.
>> Instead, we can add an extension TLV into the SignatureInfo part, e.g.,
>> http://named-data.net/doc/ndn-cxx/current/specs/certificate-format.html#additionaldescription,
>> and put the forwarding hint information there.
>>
>> We can mention this in the ndncert documentation.
>>
>> Best,
>> Zhiyi
>>
>> On Fri, Oct 5, 2018 at 11:44 AM Junxiao Shi <shijunxiao at email.arizona.edu>
>> wrote:
>>
>>> Hi Zhiyi
>>>
>>> Certificate publishing question: it seems that the certificates issued
>>>>>> from your CA is not published into the testbed, as I’m unable to retrieve
>>>>>> them by expressing an Interest of the certificate name with CanBePrefix. In
>>>>>> ndncert-legacy, the CA publishes every certificate it ever issued, and the
>>>>>> Relying Party can just refer to them with a KeyLocator. In new ndncert
>>>>>> system, who is expected to publish the certificates, CA or Replying Party
>>>>>> (client)?
>>>>>>
>>>>>
>>>> NDNCERT already support the repo-ng, which means the NDNCERT server can
>>>> publish all the issued certificates into the repo.
>>>> To solve the name issue (e.g., let /ndn/edu/ucla/CA serve
>>>> /ndn/edu/ucla/zhiyi/KEY/...), we can have a forwarding hint to forward the
>>>> request to the /ndn/edu/ucla and get the certificate from the repo. (repo's
>>>> registered prefix is not exposed to the testbed)
>>>>
>>>
>>> When a verifier V needs to retrieve a certificate, the only information
>>> V has is the KeyLocator. For example:
>>> <KeyLocator>
>>>   <Name>
>>>
>>> /ndn/edu/arizona/cs/shijunxiao/KEY/%FE%A6%A6%12r%9F%DE%A5/NA/%FD%00%00%01b%28%C6%91%1F
>>>   </Name>
>>> </KeyLocator>
>>> V is unable to infer the ForwardingHint needed for retrieving the
>>> certificate, because it does not know how many components are in the CA
>>> prefix.
>>>
>>> One obvious solution is to include forwarding hint in the KeyLocator:
>>> <KeyLocator>
>>>   <Name>
>>>
>>> /ndn/edu/arizona/cs/shijunxiao/KEY/%FE%A6%A6%12r%9F%DE%A5/NA/%FD%00%00%01b%28%C6%91%1F
>>>   </Name>
>>>   <ForwardingHint>
>>>     <Delegation>
>>>       <Preference>0</Preference>
>>>       <Name>/ndn/edu/arizona</Name>
>>>     </Delegation>
>>>   </ForwardingHint>
>>> </KeyLocator>
>>> but this requires changing the packet format, and possibly the
>>> certificate format as well because the signer needs to know what forwarding
>>> hint to put into the KeyLocator.
>>>
>>> Yours, Junxiao
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20181005/6a61e710/attachment-0001.html>