Skip to content
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

Open
SteveLasker opened this issue Aug 17, 2021 · 9 comments
Open

Key Discovery #95

SteveLasker opened this issue Aug 17, 2021 · 9 comments
Milestone

Comments

@SteveLasker
Copy link
Contributor

We've scoped Notary v2 to not support TOFU.
How will clients acquire the public keys for different registries or repos?

@SteveLasker SteveLasker added this to the Artifacts: RC1 milestone Aug 17, 2021
@mnm678
Copy link
Contributor

mnm678 commented Aug 17, 2021

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.

@letmaik
Copy link
Contributor

letmaik commented Mar 23, 2022

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.

@iamsamirzon
Copy link

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.

@SteveLasker SteveLasker reopened this Jul 19, 2022
Repository owner moved this from Done to In Progress in Notary Project Planning Board Jul 19, 2022
@SteveLasker
Copy link
Contributor Author

Re-opening, as key discovery is a critical component to notary usability. We are currently focusing on the notation inspect notation notaryproject/notation#238 command to provide the discovery method, for how to find the public key.

@dtzar
Copy link
Contributor

dtzar commented Jul 19, 2022

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.

@SteveLasker
Copy link
Contributor Author

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.

@iamsamirzon
Copy link

@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?

@dtzar
Copy link
Contributor

dtzar commented Jul 20, 2022

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.

@yizha1
Copy link
Contributor

yizha1 commented Oct 29, 2024

As discussed in the community meeting, move this issue to future milestone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Todo
Development

No branches or pull requests

7 participants