Project

General

Profile

Actions

Task #3313

closed

Add IssuerId component in certificate naming convention in NDN certificate format 2.0

Added by Yingdi Yu about 9 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
11/04/2015
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)

Description

In the NFD call 20151104, we discussed the solution to allow different issuers to assert the same (key name, key) binding and manage their own certificates independently from others. The solution is to introduce one more name component IssuerId in the naming convention of certificate name.

For now, we defines only one way to calculate IssuerId as the first 4-byte of the SHA1 hash of the wire-encoded issuer name:

SHA1(issuer_name)[0:4];

This task involves two parts: revise the format spec and implement the support in feature-keychain branch.


Subtasks 2 (0 open2 closed)

Task #3315: Update the spec of certificate format 2.0 with IssuerId definitionClosedYingdi Yu11/04/2015

Actions
Task #3316: Support IssuerId in certificate format 2.0 implementationClosedYingdi Yu11/04/2015

Actions
Actions #1

Updated by Yingdi Yu about 9 years ago

  • Blocked by Feature #3314: Support SHA1 hash in DigestFilter added
Actions #2

Updated by Junxiao Shi about 9 years ago

calculate IssuerId as the first 4-byte of the SHA1 hash of the wire-encoded issuer name

Why SHA1?

  • SHA1 is deprecated.
  • SHA256(issuer_name)[0:4] can serve the same purpose.
  • SHA256 is already available in most NDN libraries; using it requires no new code.
Actions #3

Updated by Yingdi Yu almost 9 years ago

Junxiao Shi wrote:

calculate IssuerId as the first 4-byte of the SHA1 hash of the wire-encoded issuer name

Why SHA1?

  • SHA1 is deprecated.
  • SHA256(issuer_name)[0:4] can serve the same purpose.
  • SHA256 is already available in most NDN libraries; using it requires no new code.

SHA1 is deprecated for signature calculation usage, but it is still widely used to get a roughly unique id (such as Git). The reason of not using SHA256 is because the calculation overhead. SHA1 is just one round calculation, but SHA256 requires multiple rounds of iterations...

Actions #4

Updated by Junxiao Shi almost 9 years ago

SHA1 is deprecated for signature calculation usage, but it is still widely used to get a roughly unique id (such as Git).

Yes I know that.

The reason of not using SHA256 is because the calculation overhead. SHA1 is just one round calculation, but SHA256 requires multiple rounds of iterations...

Why is calculation overhead significant? Certificate issuers are running on powerful devices.

Is there a use case where certificates need to be issued on an IoT device?

Actions #5

Updated by Yingdi Yu almost 9 years ago

When verifier is a power constrained device, and the device want to retrieve a certificate issued by a particular issuer.

Actions #6

Updated by Junxiao Shi almost 9 years ago

I agree with note-5 about the reason of choosing SHA-1.

For now, we defines only one way to calculate IssuerId as the first 4-byte of the SHA1 hash of the wire-encoded issuer name:

Per note-5, the verifier is expected to compute the IssuerId from an issuer name.

There are two concerns:

  • The algorithm for IssuerId is described as extensible (based on the usage of "for now" phrase). How could a verifier know which algorithm is chosen?
  • Why not use the full SHA-1 digest?
    How to handle collisions caused by truncated SHA-1 digest? If a certificate has 3000 issuers (e.g. web-of-trust, endorsed by every Facebook friend of a person), the probability of having a collision is over 0.1%, which is significant.
Actions #7

Updated by Alex Afanasyev almost 9 years ago

For note-5:

  • If the device is constrained and have issues calculating sha256, it will not be able to do any RSA/DCA cryptography and there is no point of getting anything

  • I'm in general not clearly seeing / agreeing with the concept of hashing "issuer name" and relying on it for purposes other than just disambiguation.

Actions #8

Updated by Yingdi Yu almost 9 years ago

Alex Afanasyev wrote:

  • If the device is constrained and have issues calculating sha256, it will not be able to do any RSA/DCA cryptography and there is no point of getting anything

It is not that the device cannot compute SHA256, I just want to safe some computation if it is possible. But anyway, given this is only research demo, let's reject the SHA1 proposal, and use SHA256 instead.

  • I'm in general not clearly seeing / agreeing with the concept of hashing "issuer name" and relying on it for purposes other than just disambiguation.

Are you against using hash or against generally disambiguate the certs?

Actions #9

Updated by Yingdi Yu almost 9 years ago

Junxiao Shi wrote:

Per note-5, the verifier is expected to compute the IssuerId from an issuer name.

There are two concerns:

  • The algorithm for IssuerId is described as extensible (based on the usage of "for now" phrase). How could a verifier know which algorithm is chosen?

There should be only one mechanism. The reason for "for now" is because we cannot say this one is the best one eventually.

  • Why not use the full SHA-1 digest?

Because Alex does not like long hashes...

How to handle collisions caused by truncated SHA-1 digest?
If a certificate has 3000 issuers (e.g. web-of-trust, endorsed by every Facebook friend of a person), the probability of having a collision is over 0.1%, which is significant.

Well, I did not expect that many issuers, but if that is really the concern, can we use 8-octets instead, should be long enough

Actions #10

Updated by Alex Afanasyev almost 9 years ago

  • I'm in general not clearly seeing / agreeing with the concept of hashing "issuer name" and relying on it for purposes other than just disambiguation.

Are you against using hash or against generally disambiguate the certs?

I'm against making assumptions about the disambiguation. Hash/sha1/2 are just viable options for that, without any attached semantic meanings.

Actions #11

Updated by Yingdi Yu almost 9 years ago

  • Blocked by deleted (Feature #3314: Support SHA1 hash in DigestFilter)
Actions #12

Updated by Alex Afanasyev almost 9 years ago

  • Target version set to v0.5
Actions #13

Updated by Yingdi Yu over 8 years ago

  • Status changed from New to Closed

All the subtasks are closed, close this issue.

Actions

Also available in: Atom PDF