Feature #1426: KeyDigest - ndn-cxx - NDN project issue tracking system

Feature #1426

closed

KeyDigest

Added by Junxiao Shi over 10 years ago. Updated about 10 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Junxiao Shi

Category:

Base

Target version:

v0.3

Start date:

Due date:

% Done:

100%

Estimated time:

2.00 h

Description

ndn::KeyLocator class should encode and decode a KeyLocator element containing a KeyDigest.

Files

A Few Arguments for Digest Support in the KeyLocator 1.docx (132 KB) A Few Arguments for Digest Support in the KeyLocator 1.docx

Jeff Burke, 06/15/2014 11:49 PM

History
Notes
Property changes

Actions

Copy link

Updated by Junxiao Shi over 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.

Actions

Copy link

Updated by Jeff Burke over 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.

Actions

Copy link

Updated by Alex Afanasyev over 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).

Actions

Copy link

Updated by Anonymous over 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).

Actions

Copy link

Updated by Jeff Burke over 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.

Actions

Copy link

Updated by Junxiao Shi over 10 years ago

Subject changed from KeyLocatorDigest to KeyDigest
Description updated (diff)

Actions

Copy link

Updated by Junxiao Shi over 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.

Actions

Copy link

Updated by Junxiao Shi about 10 years ago

I'm still waiting for comments of the API proposal in note-7.

Actions

Copy link

Updated by Alex Afanasyev about 10 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.

Actions

Copy link

#10