The certificate chain in envelopes should be integrity protected

[plietar]

The current notary spec, in both its JWS and COSE formats, specify that the certificate chain associated with the key that was used to generate the signature should be stored as an unprotected attribute.

Doing so allows the certificate chain to be replaced after the fact. While replacing the public key will obviously invalidate the signature, there is a lot of other metadata in a certificate, and an attacker may swap the leaf certificate for one with other metadata values.

As a concrete example, consider a service that, provided the signed envelope complies with a set of policies, issues a COSE Countersignature for it. These policies may, for example, restrict what Subject values are allowed in the signing certificate. Since the countersignature only binds over the protected attributes, an attacker may generate two certificates with the same key pair but two different Subjects, embed one of the certificates in the unprotected attribute, obtain a countersignature from the service, and finally replace the certificate with the other one, bypassing the service's policy.

See this issue for some more discussions on the topic: cose-wg/X509#30

In fact, both the JWS RFC and the COSE-X509 Draft RFC have language suggesting the certificates be integrity protected:

RFC7515 Section 6:

Specifically, the Header Parameters "jku", "jwk", "kid", "x5u", "x5c", "x5t", and "x5t#S256" can be used to identify the key used. These Header Parameters MUST be integrity protected if the information that they convey is to be utilized in a trust decision; however, if the only information used in the trust decision is a key, these parameters need not be integrity protected, since changing them in a way that causes a different key to be used will cause the validation to fail.

draft-ietf-cose-x509-09

Unless it is known that the CA required proof-of-possession of the subject's private key to issue an end-entity certificate, the end-entity certificate MUST be integrity protected by COSE. Without proof-of-possession, an attacker can trick the CA to issue an identity-misbinding certificate with someone else's "borrowed" public-key but with a different subject. A MITM attacker can then perform an identity-misbinding attack by replacing the real end-entity certificate in COSE with such an identity-misbinding certificate.

and

Protecting the integrity of the x5bag, x5chain and x5t contents by placing them in the protected header bucket can help mitigate some risks of a misbehaving certificate authority (cf. Section 5.1 of RFC2634).