NFD » ndn-cxx

SecPublicInfo (PIB) is public information about keys that are used for signing.

Verifiers normally verify things that are signed by someone else. Primary reason for cache is to cache previously fetched certificates, as it is kind of expensive. Also, Yingdi may correct me here, Cache also caches verfications. For example, if the certificate has already been verified against the trust model, there is no reason to re-verify it for some time.

As Alex said, SecPublicInfo contains the information of all the keys whose private key is under your control, thus it is used for signing only. For verification, keys are used to verify signatures are public keys, and for most of them, the private key is not under your control. So it does not make sense to include the SecPublicInfo as a part of Validator.

For now CertificateCache only caches validated certificates (a white list), we did not cache the invalid certificates.

If we go with the cache for ndn-cpp, it looks like certificates in the CertificateCache are lost when the application terminates. Is that the correct implementation?

Given that SecTpm knows the private keys that are under your control, and keys are generated there, and signing is done there, why does it not make sense to keep all known public keys in the SecPublicInfo?

This suggests that if multiple instances of an application, or multiple applications using the same namespace are running, each one may have its own private cache of the same certificates in its validator. It also suggests that an application specific key already in SecPublicInfo must be extracted either into a file or as base64 encoded data for the Validator to know about it. This seems inefficient.

It makes sense to me that a known public key is known to all applications, i.e. it is public information that can be kept in SecPublicInfo.

Adeola Bannis wrote:

If we go with the cache for ndn-cpp, it looks like certificates in the CertificateCache are lost when the application terminates. Is that the correct implementation?

This is exactly what we expect.

Given that SecTpm knows the private keys that are under your control, and keys are generated there, and signing is done there, why does it not make sense to keep all known public keys in the SecPublicInfo?

As I said, SecPublicInfo contains all the information of keys whose private keys are under your control, the information is used to determine which signing key should be used. SecPublicInfo is not only a container of certificates. If you do not have the private key, what is the point of putting the public key in the SecPublicInfo?

This suggests that if multiple instances of an application, or multiple applications using the same namespace are running, each one may have its own private cache of the same certificates in its validator. It also suggests that an application specific key already in SecPublicInfo must be extracted either into a file or as base64 encoded data for the Validator to know about it. This seems inefficient.

Why different apps should share the same cache? Different apps may have different validation policy. A certificate may be valid to one app but may be invalid to another. It is not about efficiency, it is about correctness.

It makes sense to me that a known public key is known to all applications, i.e. it is public information that can be kept in SecPublicInfo.

If you mean "valid public key" by "known public key", then I just explain why it should not be shared among all apps.

Okay, I have a better understanding of the decision to use a CertificateCache now, thank you.

This shall be documented in ndn-cxx Developer Guide.