spec: Root CA in the signature manifest vs out of band root?

[asraa]

Description

I'm curious if I'm being pedantic, or what the rationale is here.

The spec says:

chain string This OPTIONAL property contains a PEM-encoded, DER-formatted, ASN.1 x509 certificate chain. The certificate property MUST be present if this property is present. This chain MAY be used by implementations to verify the certificate property.

The example chain also includes a root certificate for Fulcio. I don't think that this chain "MAY" be used to verify the certificate property, because you MUST be provided your root CA certificate out of band.

This also appears in the proposal for #2131

This seems like a footgun.

I definitely want to open the conversation around this because other client workflows like sign-blob outputs should be aware.

@patflynn @haydentherapper @mnm678 @znewman01

Version

[asraa]

Note that cosign specifically excludes the root: https://cs.github.com/sigstore/cosign/blob/36e18875ce466bb85ac57f2d39b009624248e1da/pkg/cosign/verify.go?q=Chain%28%29+repo%3Asigstore%2Fcosign#L537

This is a really subtle detail and other client implementations really need to be aware not to include the root.

[dlorenc]

I think we should fix the example, the root should never be included.

[patflynn]

@loosebazooka @jvanzyl FYI.

[asraa]

I think we should fix the example, the root should never be included.

We include the root in the manifest right now, but don't include it for verification.

I can push a cosign fix.

[znewman01]

+1 to the general sentiment and the specific actions proposed EDIT: should have read more carefully, will respond downthread

[haydentherapper]

I actually think it's fine to have the root in the annotation and would be wrong to not include it. It's a reflection of what the CA returned at that point in time. While we aren't currently doing this, we could also check that the root in the annotation matches a root in TUF, and fail otherwise. You could imagine where two different roots cross-signed an intermediate. Maybe someone wants to write their own verification logic to enforce an exact root is used.

[asraa]

You could imagine where two different roots cross-signed an intermediate. Maybe someone wants to write their own verification logic to enforce an exact root is used.

In this case the verification logic dictates which out of band root to use.

While we aren't currently doing this, we could also check that the root in the annotation matches a root in TUF, and fail otherwise.

Yes, but exposing the root in the signature manifest exposes footguns, and I think it's more severe to expose this option.

I could see an argument that PKCS7 optionally includes the certificate chain similar to this, although tools will NOT verify correctly unless the root is provided out of band. Either way, at minimum, I think wording needs to be avoided to use the embedded certificate chain for verification.

[haydentherapper]

TLS does the same, returning a complete chain. I don't see this being a significant footgun, and FWIW I think there's many other ways clients can make mistakes - For example, maybe they just don't verify the chain at all, maybe they mess up the time verification, maybe they misunderstand X.509 and pull the root certificate from the CA Issuers extensions. We need to clearly articulate what is required for verification. Agreed we need better wording in the spec (the OCI annotation spec should be a part of the architecture docs for the client).

[asraa]

SGTM. I'll update the spec doc, clearer docs will help articulate the need for when you need to rely on out of band trust.

[znewman01]

+1 to following TLS here, but also being very explicit in the client specification.

[asraa]

Cool, I found some details here: https://www.rfc-editor.org/rfc/rfc8446#section-4.4.2

Because
certificate validation requires that trust anchors be distributed
independently, a certificate that specifies a trust anchor MAY be
omitted from the chain, provided that supported peers are known to
possess any omitted certificates.

Certificates that are self-signed or
certificates that are expected to be trust anchors are not validated
as part of the chain and therefore MAY be signed with any algorithm.