Feature #1705
closed
Select DigestSha256 signing method with Identity Name
Added by Alex Afanasyev over 10 years ago.
Updated over 9 years ago.
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.
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).
I would prefer an api-independent name, i.e., a name without "ndn-cxx".
- 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.
- 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
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).
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.
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.
- Blocked by Feature #2218: KeyChain: sign Interest with SHA256 digest added
- Assignee set to Yingdi Yu
- Status changed from New to Code review
- % Done changed from 0 to 100
- Blocked by Feature #2451: New Abstraction for Identity Key Certificate added
- 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.
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.
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by