Open SteveLasker opened 3 years ago
Trusting the cname
field seems risky since anyone pushing a certificate can set this value to anything they want. Instead I think some kind of chain of trust makes more sense, where we look at the root/intermediate authorities that verified the signer.
I'm actually suggesting we're trusting the cert, which happens to have a cname that can be used to find where content from this cert can be found. Regardless of where it was currently stored.
Since this is simply an OPA/Gatekeeper validation, can I suggest we move the feedback to the Notary v2 signature design so we can capture the discussion on the signature, not the validation?
I've removed the cname validation for now. We can revisit as we make more progress on the core capabilities.
@SteveLasker - does this issue still make sense to keep considering we have the e2e scenario with ratify?
As part of prototype-2, we'd like to validate the e2e scenario for validating a deployment based on the existence of a valid key, associated with the requested image to be deployed.
Based on the current nv2 signature format, we'll focus on:
We're not focusing on how the key is acquired in prototype-2, as it's considered part of our key-management goals that are being developed and will hopefully be part of prototype-3
Note: for purposes of clarity and focus, I've removed references to validating the cname of cert matches the current registry.