-
Notifications
You must be signed in to change notification settings - Fork 275
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
Implement TAP 12 #1084
Comments
I have started on step 1 in #1014. |
Two quick questions:
|
Removing
As this is already discussed in a TAP, I don't know if a decision record is needed. However, I'd rather over-document than under-document, so if others disagree we can add one. |
I think it would be good to document the removal of
I think it could be good to add a decision record. The field is unique(?) to the reference implementation and hasn't been documented in the specification, therefore I think it a) doesn't make sense to look for documentation on this field's removal in the specification documentation (taps) and b) regardless, it should be explicitly documented in the implementation's repository. |
This does not require much, if any, work in current python-tuf: we don't assume anything about keyids currently (most importantly, there's no expectation that keys are unique globally: same name can be used in different keys in different delegating metadata). Using keyids like "keyA" or "offline root key #1" should just work. |
I think we can even call ngclient the reference implementation for the TAP. We haven't solved the standard representation for keys, but I think that can be safely left to the discretion of delegators (as they are already trusted to delegate to arbitrary keys). |
Add tap12 to the reference implementation. This TAP allows for greater flexibility in how keyids are generated. This will require the following changes to the client:
The repository code should not need to change as sha256 may still be used to generate keyids.
The text was updated successfully, but these errors were encountered: