-
Notifications
You must be signed in to change notification settings - Fork 20
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
Discussion of TAP 12: Improving keyid flexibility #135
Comments
This TAP may be superceded by the signing spec project once there is a TAP for that. Though this backwards-compatible solution may still be a good intermediate step that can be done before a TUF 2.0 release. |
Let's consider removing key uniqueness check as a requirement, or at least make it clear that there is no real security benefit over checking for unique keyids only. -- Context: With
@jku argues that
It seems that there has already been some confusion about this in the original TAP 12 discussion, to which @mnm678 concluded:
On a related side-note: The reference implementation currently checks signature thresholds based on keyid uniqueness only (see theupdateframework/python-tuf@48b58d9) |
If we internally represent keys correctly (e..g, modulus and exponent for RSA instead of simply the PEM encoding), we would naturally not have this problem. |
Thanks lukas, that makes sense: the requirement is in there to not prevent an attack but a mistake in the repository side:
I think this should not lead to a client side spec requirement to verify key content uniqueness: clients should be as easy to implement as possible and implementing this is clearly not trivial (evidenced by the fact that to my knowledge no TUF client has yet implemented this). |
This is a thread to discuss TAP 12, introduced in #112.
The corresponding issue for the reference implementation is theupdateframework/python-tuf#1084.
The text was updated successfully, but these errors were encountered: