notaryproject
Key Discovery
We've scoped Notary v2 to not support TOFU. How will clients acquire the public keys for different registries or repos?
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 notation inspect notation notaryproject/notation#238 command to provide the discovery method, for how to find the public key.
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 https://github.com/notaryproject/roadmap/issues/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 https://github.com/notaryproject/notation/issues/238 and https://github.com/notaryproject/roadmap/issues/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.