Open codysoyland opened 3 days ago
I'm +1 to all of these changes, thanks for putting this together!
In some instances, we may want to allow a client to provide a *x509.CertPool
This also will come up with https://github.com/sigstore/protobuf-specs/issues/249, which I'd really like to do before we have a 1.0 release of the protobuf spec.
I have some clarifying questions, one general and the other more specific.
First the general question, with a disclaimer that I haven't thought much about certificate pools until this week. Let's say in our trusted root there's 3 different certificateAuthorities
. Today in sigstore-go we iterate through that list and create a separate certificate pool for each certificate authority we're verifying against. I think what we're proposing here is to allow one certificate pool that contains all the content from the different certificateAuthorities
at once. Is that the case? And if so, is there a meaningful difference / does that allow malicious use that wouldn't be allowed if they were separate? If not, should we change sigstore-go's implementation to create one big certificate pool for all the certificate authorities?
Assuming we get that ironed out : ) today in sigstore-go the TrustedMaterials interface mirrors the private members of TrustedRoot and the various function signatures in trusted_root.go. Would we update those all to match? Or are these changes just scoped to TrustedMaterials?
And if so, is there a meaningful difference / does that allow malicious use that wouldn't be allowed if they were separate?
It shouldn't allow any malicious behavior. x509 libraries implement path finding, using the subject key IDs and authority key IDs in each certificate to determine the path from a leaf certificate down to a CA certificate from the root pool. There is no meaningful difference between the two when it comes to certificate validation.
If not, should we change sigstore-go's implementation to create one big certificate pool for all the certificate authorities?
Yea, I think that would be reasonable. With the current logic, we would lose the validity window check however if we merge all CA certs together, so we'd need a mapping from CA cert to trust root entry to check the validity window after the x509 library verifies the certificate and finds the certificate chain (which is returned here, we currently ignore this).
Description
The
TrustedMaterial
interface currently includes these methods:The
CertificateAuthority
interface is defined as:There are a couple of issues with this interface:
verify/certificate.go
andverify/tsa.go
are tightly coupled to theCertificateAuthority
struct. In some instances, we may want to allow a client to provide a*x509.CertPool
(for example, to cleanly migrate cosign to the newTrustedMaterial
interface), to provide a custom certificate verifier function, or to provide multiple root certificates.I propose the following changes:
TimestampingAuthority
interface.CertificateAuthority
interface.FulcioCertificateAuthority
andSigstoreTimestampingAuthority
that implement the new interfaces.pkg/verify
package and into thepkg/root
package.These would be defined as follows:
The TrustedMaterial interface would then be updated to look like this:
One of the benefits of this approach is a smoother transition for cosign. This would allow cosign's
CheckOpts
to implement theTrustedMaterial
interface, as it currently is impossible due to the use ofx509.CertPool
in cosign, which is not compatible with the currentTrustedMaterial
interface.