[Ndn-interest] Complete trust management from scratch in ndn-cxx

Muktadir R Chowdhury (mrchwdhr) mrchwdhr at memphis.edu
Tue Oct 24 07:28:00 PDT 2017

How are you serving the certificate?

Can you share the code where producer is sending the certificate?


From: Michał Król <m.krol at ucl.ac.uk>
Sent: Tuesday, October 24, 2017 8:24:35 PM
To: Muktadir R Chowdhury (mrchwdhr); ndn-interest at lists.cs.ucla.edu
Subject: Re: [Ndn-interest] Complete trust management from scratch in ndn-cxx

When I dump the certificate I get the correct name:

ndnsec-dump-certificate -i -p /root/site1

Certificate name:

 Key Locator: Name=/root/KEY/%AC%FD%1A%A9%CA%9A%A5%C3

However, when I use it to sign, the name I get at the consumer is:


The "NA" component is missing and that's the cause of the problem.

In some tutorials, people submit "-N /root/site1" parameter to the ndnsec-certgen command. However, in the newest version, this option is not present. Could it be the problem?


On 24/10/17 15:10, Muktadir R Chowdhury (mrchwdhr) wrote:

The value for KEY_COMPONENT_OFFSET is -4. That means you get the 4th component from the last. Another way of saying this is that you have three more component after KEY.

Your key/cert creation looks fine.

You can check the name of the certificate using this command:

ndnsec-dump-certificate -i -p /root,

ndnsec-dump-certificate -i -p /root/site1

Just make sure the data that contains the certificate is same as the name of the certificate.


From: Michał Król <m.krol at ucl.ac.uk><mailto:m.krol at ucl.ac.uk>
Sent: Tuesday, October 24, 2017 7:54:44 PM
To: Muktadir R Chowdhury (mrchwdhr); ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>
Subject: Re: [Ndn-interest] Complete trust management from scratch in ndn-cxx

Thanks for your message Muktadir. However, it still looks like the <key-owner-prefix> can have only one component.

When I send an Interest for "/root", use identity "/root" to sign and data name "root" it works fine. But when I send an interest for "/root/site1", use identity "/root/site1" to sign and data name "root/site1" it doesn't, because the check in ndn-cxx is expecting "KEY" and I have "site1" now as the second component. I tried to set the site1 signed certificate as the trust anchor in the config file, but it still doesn't help.

The check I'm talking about is in ./src/security/v2/certificate.cpp line 132. KEY_COMPONENT_OFFSET points to the wrong name component. Maybe there's a problem when I'm generating the identities?

I do it like this:

ndnsec-keygen /root | tee root.ndncert | ndnsec-cert-install -
ndnsec-keygen /root/site1 > site1.req
ndnsec-certgen  -s /root/ site1.req > site1.ndncert
ndnsec-cert-install -f site1.ndncert

Once again, thanks a lot for your help,


On 23/10/17 21:35, Muktadir R Chowdhury (mrchwdhr) wrote:


When your producer sends the certificate make sure that the name of the data is the name of the certificate. Because the receiver will use the data packet to construct the certificate. If the data name does not follow the certificate naming convention, the constructor for Certificate will throw the error you reported.

Please note that certificate name and key name are different.

Key name: <key-owner-prefix>/KEY/<key-id>,

Certificate name: <key-owner-prefix>/KEY/<key-id>/<issuer-id>/<version-id>.

For certificate name the library is expecting three more components after the "KEY" component.

Let me know if you have any more questions.


From: Ndn-interest <ndn-interest-bounces at lists.cs.ucla.edu><mailto:ndn-interest-bounces at lists.cs.ucla.edu> on behalf of Michał Król <m.krol at ucl.ac.uk><mailto:m.krol at ucl.ac.uk>
Sent: Sunday, October 22, 2017 7:28:45 PM
To: Matteo.Bertolino at eurecom.fr<mailto:Matteo.Bertolino at eurecom.fr>; ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>
Subject: Re: [Ndn-interest] Complete trust management from scratch in ndn-cxx

I looked a bit deeper in the code and I found the reason of the problem.

ndn-cxx is expecting "KEY" as the second component in the certificate name. However, my certificate name is: "/root/publisher/KEY/%AF%C7%D8y3%5De%06/%FD%00%00%01_D8%F1%A4", so "KEY" is the third component.

When I changed the code to put "/root/" in the Interest instead of "/root/site1" it solved the problem and the signature is verified correctly. In future experiments I would like to implement a hierarchy of trust. Do you know what is the problem here?



On 17/10/17 10:49, Michał Król wrote:

Hi Matteo,

thanks for your message. It's just a formatting problem. For some reason my mail client decide to replace tabs with "/" and "?". There are not present in the files though.

I've seen your tutorial before. Actually, it was the only complete solution it could find online, so I was basing heavily on it. Thank you. My setup seems only slightly different, but I still can't make it work.



Begin forwarded message:

From: Matteo Bertolino <Matteo.Bertolino at eurecom.fr<mailto:Matteo.Bertolino at eurecom.fr>>
Subject: Re: [Ndn-interest] Complete trust management from scratch in ndn-cxx
Date: 16 October 2017 19:49:16 BST
To: <ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>>

why do you have the "//" in each line of the validator?
I am by phone so I cannot provide you easily a good answer, but you can find a completed and commented use case  here: https://github.com/MatteoBertolino92/NDN-matteo/blob/master/ndncxx_miniNDN_someUseCases_nacks__certificates__interest_verification.pdf

Section 3. Write me if u need some clarifications.

Quoting Micha? Król <m.krol at ucl.ac.uk<mailto:m.krol at ucl.ac.uk>>:

Dear all,

I'm struggling with setting up a simple trust/security system in NDN. I
find it difficult to find an updated set information that will work for
all system components. Please correct me if I misunderstood something.

I have a very simple scenario: one producer and one consumer on one
machine. I want to have a central entity (root) and a publisher
(publisher) that will be allowed to publish trusted content.

I first create the root certificate using ndnsec and selfsign it: /

/    ndnsec-key-gen -n /root//

/    ndnsec-sign-req /root > root.cert/

Next I create a certificate for the publisher and sign it using the root

/   ndnsec-key-gen -n /root/publisher > unsigned_publisher.cert//
//   ndnsec-cert-gen -S 201510080000 -E 202010080000  -s /root -i
/root/publisher -r unsigned_publisher.cert  > publisher.cert/

I then used the publisher identity to sign the data:

/    m_ident = m_keyChain.createIdentity(Name("/root/publisher"));//
//    m_info = ndn::security::SigningInfo(m_ident);/

/    m_keyChain.sign(*data, m_info);/

On the consumer side I use a validator to validate data:

/    m_validator->load("sample.cfg");/

/    m_validator->validate (data,//
//            ndn::bind(&Consumer::onValidated, this, _1),//
//            ndn::bind(&Consumer::onValidationFailed, this, _1, _2));/

I want to trust everything signed with the publishers key. The
sample.cfg is:

/    rule//
//    {//
//      id "Sample Rule"//
//      for data//
//      filter//
//      {//
//        type name//
//        name /root/publisher//
//        relation is-prefix-of//
//      }//
//      checker//
//      {//
//        type hierarchical//
//        sig-type rsa-sha256//
//      }//
//    }//
//    trust-anchor//
//    {//
//      type file//
//      file-name "root.cert"//
//    }/

Now, when I launch the consumer, it issues an interest, gets the data,
issues another interest to get the key
(/root/publisher/KEY/4%05i%7E%3C%F6%87%2F/%FD%00%00%01_%25%8Bz%80), but
ends up with an error:

/    Malformed certificate (Name does not follow the naming convention
for certificate). /

My question is now, is it how I'm supposed to do this? If yes, what's
the problem here? If not, is there any example tutorial, walking through
the all steps of managing trust in NDN (ndnsec, app, validator)?

Thanks in advance,


This message was sent using EURECOM Webmail: http://webmail.eurecom.fr

Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20171024/4a3c4c3d/attachment-0001.html>

More information about the Ndn-interest mailing list