Project

General

Profile

Task #2173

Explain CertificateCache vs SecPublicInfo in Validator classes

Added by Adeola Bannis about 6 years ago. Updated over 5 years ago.

Status:
Abandoned
Priority:
Normal
Assignee:
Category:
Docs
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

As part of adding signer validation to ndn-cpp, we are trying to follow ndn-cxx's Validator class. However, we have noticed that instead of using SecPublicInfo for certificate lookup and storage, the Validator classes use CertificateCache.

The CertificateCache uses the certificate name minus timestamp as a key when fetching/storing certificates, which allows matching with certificate names in KeyLocator fields in a Data packet. Is this the only reason for using a CertificateCache? Is there currently a mechanism for certificates in the CertificateCache to be added to SecPublicInfo, or do we need to keep these certificates separate?

Is there any documentation that indicates that the certificate store of the Validator classes is distinct from the SecPublicInfo used by the KeyChain, and why? Also, is there any documentation on the lifetime of the downloaded certificates?

#1

Updated by Junxiao Shi about 6 years ago

  • Subject changed from Documentation Request: CertificateCache vs SecPublicInfo in Validator classes to Explain CertificateCache vs SecPublicInfo in Validator classes
  • Category set to Docs
  • Assignee set to Yingdi Yu
  • Target version set to v0.3
  • Start date deleted (11/13/2014)
#2

Updated by Alex Afanasyev about 6 years ago

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.

#3

Updated by Yingdi Yu about 6 years ago

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.

#4

Updated by Adeola Bannis about 6 years ago

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.

#5

Updated by Yingdi Yu about 6 years ago

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.

#6

Updated by Adeola Bannis about 6 years ago

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

#7

Updated by Junxiao Shi about 6 years ago

This shall be documented in ndn-cxx Developer Guide.

#8

Updated by Junxiao Shi over 5 years ago

  • Status changed from New to Abandoned

This issue is no longer applicable because SecPublicInfo is being replaced by Pib.

Also available in: Atom PDF