NFD » ndn-cxx

Could you justify why PIB needs to support that? PIB is only used in two cases: 1) determine the signing key and signed info; 2) publish certificate.

In the first case, it sounds weird that you have already known the key digest, but you don't know the signing key. If the digest is obtained from some other sources, it would be very dangerous to use a key according to a obscure digest.

In the second case, I don't think one can fetch a key via digest.

As I understand, the keyDigest is used when data consumer has already got the public key, so the data producer does not have to put cert name in keyLocator. If we need to support keyDigest feature, we should add that in Validator and PublicKey, so consumer's validator may index the validated keys by keyDigest, and as long as data producer determine its signing key, it can derive the keyDigest from the PublicKey directly rather than from PIB.

One use case is: the system has a pre-distributed set of keys, and every Data packet only carries a KeyDigest.
In order to validate an incoming Data packet, the validator:

1. retrieve the key from PIB service using its digest
2. check that the key is signed by the trust anchor (trust anchor certificate is already known by validator)
3. validate the Data packet using the key

No, that is not the functionality of PIB, PIB is only used to contain the public information of signing keys on your system. If the public key is used for validation, then it should not be stored in PIB. Instead, the key should be managed by Validator (e.g., In ValidatorConfig, you can specify a trust-anchor directory to store all these keys).

This Task should be Rejected because I misunderstood the scope of PIB service, as pointed in note-4.