Task #3313
closedAdd IssuerId component in certificate naming convention in NDN certificate format 2.0
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.
Updated by Yingdi Yu about 9 years ago
- Blocked by Feature #3314: Support SHA1 hash in DigestFilter added
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.
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 nameWhy 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...
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?
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.
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.
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.
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?
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
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.
Updated by Yingdi Yu almost 9 years ago
- Blocked by deleted (Feature #3314: Support SHA1 hash in DigestFilter)
Updated by Yingdi Yu over 8 years ago
- Status changed from New to Closed
All the subtasks are closed, close this issue.