Specification of how keys and the random seed are stored #53
Conversation
Describe the storage format for keys and random seed in Mbed Crypto 0.1.0 released with Mbed OS 5.11, over C stdio and over ITS with 32-bit file identifiers. Describe the proposed storage format for keys and random seed in the future release of Mbed Crypto for Mbed OS 5.12, over C stdio and over ITS with 64-bit file identifiers.
|
|
||
| Information about each key is stored in a dedicated file whose name is constructed from the 32-bit key identifier (`psa_key_id_t`) and, if applicable, the owner identifier. The way in which the file name is constructed depends on the storage backend. The content of the file is described [below](#key-file-format-for-0.2.0). | ||
|
|
||
| The valid values for a key identifier are the range from 1 to 0xfffeffff. The range is not documented. |
There was a problem hiding this comment.
"The range is not documented." but doesn't the previous sentence document it?
There was a problem hiding this comment.
This is an internal architecture document. We don't document it, as in, we haven't made any promise to users.
There was a problem hiding this comment.
We can be more clear about "it's not documented" since it is technically documented here in this internal architecture document. We can say "The range is an internal implementation detail not guaranteed to be stable between versions," or something similar.
There was a problem hiding this comment.
Not so much an implementation detail as an undocumented limitation. At this point, the specification says that the key ID is a 32-bit value and doesn't say that implementations are allowed to declare some values as invalid. Should they be? To be clarified in version 1.0 of the API specification.
|
|
||
| ### Key file format for 0.2.0 | ||
|
|
||
| The layout is identical to [0.1.0](#key-file-format-for-0.1.0) so far. However note that the encoding of key types, algorithms and key material has changed, therefore the storage format is not compatible (despite using the same version so far). |
There was a problem hiding this comment.
"using the same version" of what? should this be "using the same layout"? Or should we update the VERSION tag in the format?
There was a problem hiding this comment.
I meant the version tag in the format, I'll clarify.
Since so far this is an experimental format that we break often, we haven't been updating the version tag yet.
There was a problem hiding this comment.
Let's keep the version tag where it's at until 1.0.0 and API stability.
There was a problem hiding this comment.
We may well commit to a key format before we've fully achieve API stability. At that point we'd increment the storage version to 1.
There was a problem hiding this comment.
Yes, we might do. Let's keep it where it's at until 1.0.0 unless we have a good reason not to.
Describe the storage format for keys and random seed in Mbed Crypto 0.1.0 released with Mbed OS 5.11, over C stdio and over ITS with 32-bit file identifiers.
Describe the proposed storage format for keys and random seed in the future release of Mbed Crypto for Mbed OS 5.12, over C stdio and over ITS with 64-bit file identifiers.