-
Notifications
You must be signed in to change notification settings - Fork 44
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
Key Discovery #95
Comments
Per the TUF design, if we can distribute root keys that do namespaced delegations for a registry or registries, we can reduce the number of keys that need to be distributed to end users. This reduced number of keys could be shared with client systems when they are provisioned using existing secret distribution methods, like SPIFFE/SPIRE. |
For SCITT (see draft spec), the proposal is to use DID both as mechanism to establish issuer identifiers and to do key discovery (via DID resolution), while not being constrained to a single identity system but having extensibility through DID methods. For Notary to support this, signing envelopes would have to include the DID as issuer in the protected header plus a key ID. |
Key discovery/distribution can be done outside of Notary. Additionally, I believe we have discussed, that users can inspect a signature using Notation to start their discovery process. |
Re-opening, as key discovery is a critical component to notary usability. We are currently focusing on the |
Steve - I believe we need to fill in more details on 238 because it is currently vague and not connected to this purpose as it is written. Key discovery is vital for verification of course and we need to make this easy for users and producers. Simply getting various metadata back about a signature not necessarily important in general, especially considering we have oras. |
The focus here is we at least need to know where the public key is located. Then, users can download the public key, configure their trust stores and have an e2e story. See notaryproject/roadmap#74, and perhaps we can either copy the content from there, or re-use that issue for tracking. |
@SteveLasker and @dtzar - I think we are saying the same thing, that some sort of "Signature Inspection" can be used as a method to determine the publisher and the public key. There are already other issues/PR like you both pointed out notaryproject/notation#238 and notaryproject/roadmap#74. So could we close this one as a duplicate? |
I forgot about 172 and I believe this captures the notation flavor/idea intent to implement key discovery. However - @letmaik's comment above is worth considering that isn't covered in issue 172. |
As discussed in the community meeting, move this issue to future milestone. |
We've scoped Notary v2 to not support TOFU.
How will clients acquire the public keys for different registries or repos?
The text was updated successfully, but these errors were encountered: