ndnSIM

Junxiao Shi wrote:

CCNx libccn expects SignatureBits BLOB to have at least 16 octets.
ndnSIM writes uint32_t (4 octets) in SignatureBits.

While this does not violate CCNx Signature specs, it is not compatible with libccn.

Yeah. I know this "feature", but not sure what would be the best way to go... Adding real signature to the ndnSIM datastructure or adding fake padding to the signature in CCNb format to play nicely with ccnx implementation? In either case, ndnSIM doesn't calculates (yet?) any real signatures... What do you think would be a better approach to go?

If CCNx compatibility is the goal,

put "NOP" in <DigestAlgorithm>

omitting is not correct, because does not contain a valid SHA-256 signature

pad <SignatureBits> to 16 octets

Junxiao Shi wrote:

If CCNx compatibility is the goal,

put "NOP" in <DigestAlgorithm>

omitting is not correct, because does not contain a valid SHA-256 signature

Does ccnd/C-API recognizes NOP? Or it is something that we should eventually add to provide inter-operability support?

pad <SignatureBits> to 16 octets

Sure. I'll do that

libccn does not recognize NOP, but A ContentObject with "NOP" in can be parsed by libccn and processed by recent version of ccnd.
Apps and routers may choose to verify the signature. If the is not known, they may decide to drop the ContentObject.