Clarify current state of key formats in the spec #272
Conversation
There was a problem hiding this comment.
Thanks for the patch, @joshuagl! I think this is the right solution for ecdsa keys. Also thanks for structuring the commits in a meaningful way!
Joshua, did you coordinate with @trishankatdatadog that he syncs your branch with upstream?
joshuagl
force-pushed
the
joshuagl/keytype
branch
from
e83ed23 to
9fe0b01
Compare
|
I just rebased on main and pushed an additional commit which: adds a header for the object format and makes that section, the key format section and the date-time section all subsections (one level of heading lower) of the "File formats: general principles" section. @lukpueh PTAL at 9fe0b01 and re-approve if you agree.
We did not coordinate. |
|
Sorry, what branch upstream? |
You seemed to have pushed a merge commit (e83ed23) onto Joshua's branch. |
We claim that the spec is just documenting the signature _schemes_ from the reference implementation, but that we define three _keytypes_ within the spec. This change first updates the _keytypes_ to match the reference implementation (we have defaulted to a generic "ecdsa" keytype since secure-systems-lab/securesystemslib#267). Further, we update the specification to clarify that within we are documenting the keytypes and schemes from the reference implementation, and that we recommend implementing these keytypes and schemes as specified. Signed-off-by: Joshua Lock <[email protected]>
Signed-off-by: Joshua Lock <[email protected]>
Make it easier to find key formats and, more importantly because it's often missed, date-time recommendations. Signed-off-by: Joshua Lock <[email protected]>
Signed-off-by: Joshua Lock <[email protected]>
These all form part of the general principles of the pedagogical file format, so move them to be one level heading lower. Signed-off-by: Joshua Lock <[email protected]>
joshuagl
force-pushed
the
joshuagl/keytype
branch
from
9fe0b01 to
de6b164
Compare
|
Rebased on master and force pushed. That didn't dismiss @lukpueh's approval 😌 has GitHub evolved? @trishankatdatadog @mnm678 any chance of a review/2nd approval? |
Key formats are a recurring source of confusion (see secure-systems-lab/securesystemslib#513, #201, and secure-systems-lab/securesystemslib#308). Do we specify key formats, or simply record those used by the reference implementation?
The current status is unclear, so this PR attempts to:
The above changes are included in a single commit ac9fc63.
There are additional changes in this PR to address a bikeshed error in newer versions of the generator (2de4149) and to add additional navigation headers to make it easier to find and link to details of the recommended file formats (5fef375). I included these changes in one PR because the workflow is awkward for small changes.
I encourage reviewers to use the commits tab and review each patch independently.
(Note: deeper discussions around key formats and specification vs. recommendation and interoperability of implementations is necessary, and has been added to the agenda