Open jku opened 2 months ago
Hi, thanks for reaching out! We're reviewing this proposal with our security team and will be able to give you an answer once we've gone through that process.
Still reviewing. In reading the TAP12 proposal, as I understand it, I agree with the change. Most likely we would prefer to see the change incorporated into the spec before making the change here.
One thing not entirely clear to me @jku, are there downstream users of this library that are blocked by the enforcement of the KeyID calculation? I saw that sigstore uses this library in its "experiemental" Rust client. Is that causing blockers or failures now?
Cheers, I can understand that view point. I will likely try to push the linked spec issue forward before the TAP to make the spec intent clear but your point applies there as well: you'd rather see it in the spec first...
So the situation is that
This is blocking the developers of the rust sigstore client from using sigstores staging infrastructure at the moment but we should be able to work around the situation.
I'm wondering if you'd accept a patch that makes the key deserialization checks a little bit less strict...
I've tried to write down all of the the context in this spec issue https://github.com/theupdateframework/specification/issues/305 but the short of it is that
deserialize_keys()
) as the spec instructs seems to have no security benefitThe practical reason I'm filing this now is this:
So I'm trying to clean up my mess, wondering if (in addition to fixing the bug in tuf-on-ci) part of that could be a patch to tough that removes the keyid calculation check from the key deserialization as a way to improve practical compatibility between the implementations.