Feature #3764
closed
TPM functions should use RFC4648 standard filename safe Base64 encodings
0%
Description
TPM public and private key files appear to be encoded with a non-standard variant of Base64. Consider following the RF4648 standard for filename safe encoding, available in CryptoPP as Base64URLEncoder. https://www.cryptopp.com/wiki/Base64URLEncoder
Updated by Alex Afanasyev over 7 years ago
Do you mean the content or file names?
Just curious. Are you using the filenames in some ways directly? There is import/export functionality in ndnsec tools, which give a more portable solution to move certs (though may need improvements).
Updated by Jeff Burke over 7 years ago
Filename. When moving identities (specifically, private key files) between machines, I was trying to manually create entries in mapping.txt and the TPM directory itself and realized that I couldn't use standard Base64 tools to create the filenames. It's not at all a big deal - just a minor incompatibility that I didn't figure out until reading the code. But, seems like it should be based on a standard.
Updated by Junxiao Shi over 7 years ago
When moving identities (specifically, private key files) between machines, I was trying to manually create entries in mapping.txt and the TPM directory itself
The structure of $HOME/.ndn folder, except $HOME/.ndn/client.conf, is implementation detail and not public API.
To move identities between machines, use ndnsec export and ndnsec import commands.
See https://yoursunny.com/t/2016/nfd-prefix/ "Where's the Key Chain?" section for examples on command syntax.
Nevertheless, standard filename base64 encoding should be used in the implementation.
Updated by Junxiao Shi almost 6 years ago
- Status changed from New to Rejected
Security v2 no longer has this problem.
$ find .ndn
.ndn
.ndn/pib.db
.ndn/ndnsec-key-file
.ndn/ndnsec-key-file/33b7153f66c33470bf440bb3846351c9a51c96dd386143be2e0a0c5461b1d1cd.privkey