Feature #3892
closedIntegrate publishing of KeyBundle into Face::setInterestFilter
Added by Alex Afanasyev almost 8 years ago. Updated over 5 years ago.
50%
Updated by Alex Afanasyev almost 8 years ago
- Blocked by Feature #2766: CertificateBundle: design added
Updated by Alex Afanasyev almost 8 years ago
- Category set to Security
- Assignee set to Manika Mittal
Updated by Alex Afanasyev almost 8 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 50
Updated by Junxiao Shi almost 8 years ago
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.
Updated by Alex Afanasyev almost 8 years ago
The first instantiation will be part of the face. The intention is to provide a seamless integration where possible.
Updated by Junxiao Shi almost 8 years ago
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.
Updated by Muktadir Chowdhury over 7 years ago
- Related to Task #3950: Use CertificateBundleFetcher instead of DirectFetcher added
Updated by Junxiao Shi over 7 years ago
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
:
- When a signing key name is known, it is added into the
BundlePublisher
which can start collecting the certificate chain. At the same time, theBundlePublisher
should register a prefix with theFace
. - When an Interest for bundle arrives, the
BundlePublisher
generates the bundle and stores it within anInMemoryStorage
. - Interests are answered via the
InMemoryStorage
.
Updated by Manika Mittal over 7 years ago
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.
Updated by Junxiao Shi over 7 years ago
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.
Updated by Alex Afanasyev over 7 years ago
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 plainBUNDLE
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.
Updated by Junxiao Shi over 7 years ago
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.
Updated by Alex Afanasyev over 7 years ago
Feb 20, 2017 call discussed the issue of naming convention. The conclusion is that we will reserve _BUNDLE
name component for bundle purposes.
Updated by Junxiao Shi over 7 years ago
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
.
Updated by Junxiao Shi over 7 years ago
Change 3668,5 BundleBuilder
collects certificates by expressing Interests. However, this does not work with a common use case: per-instance certificate.
- Application already has a per-application certificate, signed by the operator.
- When application starts, it generates a new key pair, put the public key into a per-instance certificate, signed by the per-application certificate.
- 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.
Updated by Haitao Zhang over 7 years ago
- Related to Feature #3979: Configure Face::expressInterest to allow forward Interest to the incoming face added
Updated by Manika Mittal over 7 years ago
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 theBundleBuilder
.
Yes you are right about BundleState being used internally by the BundleBuilder. Do you have a suggestion about the API?
Updated by Manika Mittal over 7 years ago
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.
Updated by Junxiao Shi over 7 years ago
Reply to note-18:
- Rename
BundleState
toBundleHandle
. - Make it an opaque class. See
Scheduler::EventId
for example.
Updated by Junxiao Shi over 7 years ago
- Has duplicate Bug #2407: Local certificate is not published added
Updated by Davide Pesavento almost 7 years ago
- Tracker changed from Task to Feature
- Target version changed from v0.6 to v0.7
Updated by Junxiao Shi over 5 years ago
- Blocked by deleted (Feature #2766: CertificateBundle: design)
Updated by Junxiao Shi over 5 years ago
- Status changed from In Progress to Abandoned
CertificateBundle design has been changed significantly in #2766-30. I'm abandoning this issue, and will create new issues after the design has been approved.