Feature #1705
closed
Select DigestSha256 signing method with Identity Name
Description
Reserve ndn:/localhost/identity/digest-sha256 as a special Identity Name.
When this Identity Name is passed to KeyChain::sign or becomes the default with ndnsec-set-default, the packet is hashed with DigestSha256 signing method.
Necessity
Right now, the default signature (selected signature during sign operation) not only specifies which public key will be used during the signing, but also which exactly algorithm (rsa or ecdsa).
However. It is literally impossible right now to "select" digestSha256 "signing" without specifically designing the application in a special way. If we designate some special "public key identity" that can be created/set using ndnsec-set-default, then it would be trivial for a user to select very cheap signing, if it is really desired.
Updated by Alex Afanasyev over 10 years ago
Junxiao suggested to use (hard-coded?) identity name like /localhost/ndn-cxx/identity/DigestSha256.
May be instead of /localhost we can define some other special prefix that is guaranteed to be non-routable (but this would require special definition in some spec).
Updated by Yingdi Yu over 10 years ago
I would prefer an api-independent name, i.e., a name without "ndn-cxx".
Updated by Junxiao Shi about 10 years ago
- Start date deleted (
06/26/2014)
Another possibility is:
Extend ndnsec-key-gen to accept a keyType parameter, in which DigestSha256 can be specified as a keyType.
The user can generate an identity of DigestSha256 type, to make KeyChain sign packets with only a SHA256 hash.
This allows the user to choose the identity Name.
Updated by Junxiao Shi about 10 years ago
- Subject changed from Fake "public key identity" to designate digestSha256-only hashing of the Data packet to Select DigestSha256 signing method with Identity Name
- Description updated (diff)
20141022 conference call decides to use a fixed Name as DigestSha256 identity:
ndn:/localhost/identity/DigestSha256
Updated by Alex Afanasyev about 10 years ago
I just realized that it may not be a good idea require this specific case spelling. We could allow equivalents: /localhost/identity/digestsha256 and or /localhost/identity/digest-sha256 (i like this the best).
Updated by Junxiao Shi about 10 years ago
This mixed case spelling comes from DigestSha256 element definition in NDN-TLV spec.
It's a Name, and it's binary. There's no reason to use lower case, or allow more than one Names.
Updated by Alex Afanasyev about 10 years ago
The spec does not need to have anything to do with the naming convention used in this case. All our other identities are in lower case and requiring this special identity to have camel case name for one of the components does not seem right.
Updated by Junxiao Shi almost 10 years ago
- Blocked by Feature #2218: KeyChain: sign Interest with SHA256 digest added
Updated by Yingdi Yu almost 10 years ago
- Status changed from New to Code review
- % Done changed from 0 to 100
Updated by Yingdi Yu over 9 years ago
- Blocked by Feature #2451: New Abstraction for Identity Key Certificate added
Updated by Junxiao Shi over 9 years ago
- Tracker changed from Task to Feature
- Description updated (diff)
- Status changed from Code review to In Progress
- Target version changed from v0.3 to v0.4
- % Done changed from 100 to 0
20150508 conference call decides to use all lower-case special identity:
ndn:/localhost/identity/digest-sha256
Yingdi will abandon http://gerrit.named-data.net/1536 and work on a new commit under the new PIB abstraction adopted in #2451.
Updated by Junxiao Shi over 9 years ago
After #2871, is it still a good idea to use a special identity?
We could define a string representation for SigningInfo, such as:
id:/my-identity
cert:/my-identity/KEY/ksk-1
sha256:
The three forms select identity, certificate, and DigestSha256.
Updated by Yingdi Yu over 9 years ago
- Blocks Task #2926: Refactor KeyChain added
Updated by Junxiao Shi over 9 years ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100