Feature #1426
closed
KeyDigest
100%
Description
ndn::KeyLocator class should encode and decode a KeyLocator element containing a KeyDigest.
Files
Updated by Junxiao Shi almost 10 years ago
- Category set to Security
- Target version set to v0.3
20140613 conference call points out that the term `KeyLocatorDigest' is misleading: it is a digest of the public key, not a digest of the Name of the key.
The purpose of `KeyLocatorDigest' is an optimization when the consumer is expected to have received the public key already.
The consumer is able to make sure that it's verifying with the correct public key.
We should have this feature in 0.3.
Updated by Jeff Burke almost 10 years ago
I believe that the use case motivating digest support was to make it efficient for a consumer that has seen a key before to verify new packets from the same publisher. In this scenario, one could imagine a digest of the key itself OR a previous KeyLocator (containing a name) as being useful... Perhaps the various options need to be considered in more detail.
Updated by Alex Afanasyev almost 10 years ago
Do we actually have any use cases for this?
My opinion was and is that this is completely unnecessary to have anything except name in key locator. Without certificate name in key locator, it will be unclear for anybody else in the network to fetch the key. Digest is 32-bytes and proper names can be way smaller than this (e.g., like short-links).
I don't see a valid reason for hashing keyLocator field. Anything that was there should identify the key, not the name that points to the key. The latter can point to different things (e.g., in current trust model, KeyLocator is not an exact name).
Updated by Anonymous almost 10 years ago
Alex Afanasyev wrote:
Do we actually have any use cases for this?My opinion was and is that this is completely unnecessary to have anything except name in key locator. Without certificate name in key locator, it will be unclear for anybody else in the network to fetch the key. Digest is 32-bytes and proper names can be way smaller than this (e.g., like short-links).
+1
Updated by Jeff Burke almost 10 years ago
- File A Few Arguments for Digest Support in the KeyLocator 1.docx A Few Arguments for Digest Support in the KeyLocator 1.docx added
See attached.
Updated by Junxiao Shi almost 10 years ago
- Subject changed from KeyLocatorDigest to KeyDigest
- Description updated (diff)
Updated by Junxiao Shi almost 10 years ago
- Category changed from Security to Base
- Assignee set to Junxiao Shi
I plan to work on this Task soon.
The proposed API is:
partial class KeyLocator
{
public:
enum {
KeyLocator_KeyDigest = 1
};
/** \brief get KeyDigest element
* \throw Error if type is not KeyLocator_KeyDigest
*/
const Block&
getKeyDigest() const;
/** \brief set KeyDigest
* \param keyDigest a KeyDigest block
* \throw Error if keyDigest is not of KeyDigest type
* \note type becomes KeyLocator_KeyDigest after this operation is successful
* \return self
*/
KeyLocator&
setKeyDigest(const Block& keyDigest);
/** \brief set KeyDigest
* \note type becomes KeyLocator_KeyDigest after this operation is successful
* \return self
*/
KeyLocator&
setKeyDigest(const uint8_t* keyDigest, size_t keyDigestLength);
};
Please let me know if there's objection to this API.
Updated by Junxiao Shi over 9 years ago
I'm still waiting for comments of the API proposal in note-7.
Updated by Alex Afanasyev over 9 years ago
I'm ok with the exception of the last set method (not sure if we need that one, but we could...). I would also another one, since ndn::crypto::sha256 (http://named-data.net/doc/ndn-cxx/current/doxygen/d0/d86/namespacendn_1_1crypto.html#a66fcb4e810480d5c82d458d85a3aab72) method returns
ConstBufferPtr and it should be directly acceptable as a parameter to set digest.
Updated by Junxiao Shi over 9 years ago
- Status changed from New to In Progress
I'll use the API described in note-7 and updated by note-9.
Updated by Junxiao Shi over 9 years ago
- Status changed from In Progress to Code review
- % Done changed from 0 to 100
Updated by Junxiao Shi over 9 years ago
- Status changed from Code review to Closed