-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Opinion] Hardcoded TLV format is not a good long term choice #4
Comments
Here is my implementation of a slightly simpler version w/ fixed 4-byte maximum lengths. Just a starting point if you consider bringing the TLV structure into its own component... pd_klv.h
pd_klv_serialization.h
All In Single File
|
Hi @chipweinberger Thanks for your opinion. and thanks for the detailed reasoning. I have seen your implementation and it looks interesting. But I think it is more generic and it also supports updating an existing KLV. As for the flash format, Our main objective was to make it simple, and more efficient. While designing a generic flash format, I think there are many aspects that need to be looked at. However, our current goal here was to tailor the flash format specific to our needs. I agree that adding a header that contains the version would be a good idea. I will discuss it and see if we can incorporate it. While I give you my explanation as to why we designed it in such a way, we would really take your comments into consideration. Thanks, |
Thanks for the thoughtful answer. Yes, I think if the format was documented and moved to it's own If this repo changes, the |
I see, that would be helpful as well. But not sure how many users would use this customised flash format with their own projects. |
Thanks for answering my previous questions =)
I just wanted to share this idea and why I ended up choosing against the custom TLV format. Instead, I store certs in a generic KLV format, that I already implemented for other purposes in my code base.
As alluded to in #2, I'm not a fan of using a custom hard coded TLV format. Personally, It's a deal-breaker.
Why?
Instead, we really should:
keyLen
,key
,dataLen
,data
format, so we don't need hardcoded type valuesThe generic KLV format I use looks like this:
Edit: also worth considering using DER format.
The TLV format currently used here is a deal-breaker for me.
The text was updated successfully, but these errors were encountered: