NFD » ndn-cxx

Why is the key bundle published by Face, a low level component? They should be published by a higher level component, or the PIB service.

The first instantiation will be part of the face. The intention is to provide a seamless integration where possible.

There would be uninteded consequences: there would be additional prefix registrations, and some Interests are not dispatched to producer application as expected.

KeyBundle packets should instead be published by a separate component backed by InMemoryStorage. InMemoryStorage should offer a function that ties itself to a Face. Then, an application that wants to publish KeyBundles can create that component and connect it to the face, while all other applications are unaffected and do not incur the overhead.

It's unclear how BundleHelper in https://gerrit.named-data.net/3668 patchset4 can be used.

The idea is to initiate the process of fetching the certificates as soon as the signing key name is known. This does not have to wait for the actual bundle interest.
The get bundle function is called when the actual interest for bundle is received. So whenever the interest is received, just respond with a bundle with whatever certificates are currently known.

The above is correct. However:

• How could the application receive an Interest for bundle? Bundle name is derived from signing key name, but the deriving rules is only in CertficateBundleFecher::deriveBundleName which is private.
• Why should the application even care about BundleState?
• Why should the application register prefixes for publishing the bundles? They should be registered by a "bundle publisher" component.
• Why should the application store the additional segments, once an Interest for bundle arrives but there are more than one segment? They should be stored in the "bundle publisher".

Then, BundleHelper or BundleBuilder is insufficient to fulfill the purpose. Instead, we need a BundlePublisher:

1. When a signing key name is known, it is added into the BundlePublisher which can start collecting the certificate chain. At the same time, the BundlePublisher should register a prefix with the Face.
2. When an Interest for bundle arrives, the BundlePublisher generates the bundle and stores it within an InMemoryStorage.
3. Interests are answered via the InMemoryStorage.

You are right about BundleBuilder being insufficient in providing the complete functionality of publishing the bundle.

Originally the idea was to have a new setInterestFilter that takes an additional argument "signingKeyName". In essence, whatever you said the BundlePublisher should do was going to go in the setInterestFilter(interestFilter, onInterest, signingKeyName) which would use the BundleBuilder to initiate the process of fetching certificates and set interest filter for the bundle (it passes the bundle state to onBundleInterest callback). Note that the bundle name is derived from the data name and not the signing key name which means the face would use the interest prefix name in the interest filter and the "BUNDLE" component to distinguish between interests for the actual data and those for the bundle.

And when an actual bundle interest is received, the onBundleInterest callback would use the Bundle state to return the bundle with certs that are currently available.

Currently it seems that may be setInterestFilter might not be the best place to put all this logic. So till that is finalized I only have BundleBuilder and BundleState.

the face would use the interest prefix name in the interest filter and the "BUNDLE" component to distinguish between interests for the actual data and those for the bundle.

BUNDLE is a valid name component which can mean something other than a certificate bundle. Face should not hijack such Interests by replying with certificate bundles instead of delivering to producer application (InterestCallback).
The protocol should be changed to use a MarkedComponent whose marker type is reserved to certificate bundles, instead of a plain BUNDLE component. (note: this is not needed if bundle name is derived from signing key name)

the bundle name is derived from the data name and not the signing key name

Why not deriving the bundle name from the signing key name? The verifier already knows the signing key name from KeyLocator field. This also allows more opportunity to retrieve a bundle from in-network cache.

Junxiao Shi wrote:

the face would use the interest prefix name in the interest filter and the "BUNDLE" component to distinguish between interests for the actual data and those for the bundle.

BUNDLE is a valid name component which can mean something other than a certificate bundle. Face should not hijack such Interests by replying with certificate bundles instead of delivering to producer application (InterestCallback).
The protocol should be changed to use a MarkedComponent whose marker type is reserved to certificate bundles, instead of a plain BUNDLE component. (note: this is not needed if bundle name is derived from signing key name)

This is a naming convention. It is irrelevant is application using this for something else or not. And we are not hijacking, we publish data if requests is conforming to bundle naming convention.

the bundle name is derived from the data name and not the signing key name

Why not deriving the bundle name from the signing key name? The verifier already knows the signing key name from KeyLocator field. This also allows more opportunity to retrieve a bundle from in-network cache.

We had long discussions about derivation logic and the current one is to the best of our understanding represent the use case for the bundle. The idea is to keep bundle together with the data. The signing key is not always named under the same prefix and even less likely to be served by the same application as the data.

In any case, other derivation rules are not excluded and, in the long term, they suppose to be flexible, potentially schematized. In the short term, we have fixed set of derivation rules based on data name.

This is a naming convention. It is irrelevant is application using this for something else or not. And we are not hijacking, we publish data if requests is conforming to bundle naming convention.

This is hijacking: the library is responding to Interests that contains the token BUNDLE, which prevents application from responding to such Interests.
Think about a file server such as NDNFS: it's absolutely normal for a filesystem to have a directory named "BUNDLE" and a file named "00" within that directory, and such Interest must not be responded with a certificate bundle.

The bundle naming convention is wrong: it should not use any component that the application can legitimately use, but should use a MarkedComponent that is reserved for certificate bundles and not open to normal application usage.

The idea is to keep bundle together with the data. The signing key is not always named under the same prefix and even less likely to be served by the same application as the data.

Agreed.

Feb 20, 2017 call discussed the issue of naming convention. The conclusion is that we will reserve _BUNDLE name component for bundle purposes.

Change 3668,5 suggests BundleBuilder is used as follows:

shared_ptr<BundleState> bundleState = builder.begin("/my-identity/KEY/key-id/signed-by-ca");
face.processEvents();

std::vector<shared_ptr<const Data>> bundlePkts = builder.getBundle(interest, bundleState);

This API is confusing. In particular, it's unclear what the type name BundleState means, because this seems like a "handle" which is only used internally by the BundleBuilder.

Change 3668,5 BundleBuilder collects certificates by expressing Interests. However, this does not work with a common use case: per-instance certificate.

1. Application already has a per-application certificate, signed by the operator.
2. When application starts, it generates a new key pair, put the public key into a per-instance certificate, signed by the per-application certificate.
3. Both per-application certificate and per-instance certificate are published by the application itself.

Typically, each application uses only one ndn::Face, and Face::expressInterest would not attempt to forward an Interest toward an InterestFilter registered on the same ndn::Face.
When BundleBuilder is used to create a bundle for the per-instance certificate, the Interests for certificate collection would not reach the InterestFilter on the ndn::Face where the certificates are published, but will be forwarded to NFD. NFD would not forward the Interests back to the ndn::Face because that would cause a loop. Therefore, certificate bundle cannot be built successfully.

To solve this problem, BundleBuilder should collect certificates not only by expressing Interests, but also from local KeyChain's PIB.

Junxiao Shi wrote:

This API is confusing. In particular, it's unclear what the type name BundleState means, because this seems like a "handle" which is only used internally by the BundleBuilder.

Yes you are right about BundleState being used internally by the BundleBuilder. Do you have a suggestion about the API?

Junxiao Shi wrote:

To solve this problem, BundleBuilder should collect certificates not only by expressing Interests, but also from local KeyChain's PIB.

I fixed this in the new patch.

Reply to note-18:

• Rename BundleState to BundleHandle.
• Make it an opaque class. See Scheduler::EventId for example.