On Mon, Oct 19, 2020 at 11:40:33AM -0700, Laurence Lundblade wrote: > I’m trying to understand why the x5u header must be a COSE protected header > parameter and in general what the expected use of this header is. > > My understanding is that it the relying party that is validating the cert > chain is the one doing the HTTP fetching. > > In the case of application/pkix-cert, then only one DER cert is returned and > that is the end-entity cert. > > My expectation for the way this would work is: > - The relying party would use HTTP to with the x5u URL to fetch the > end-entity cert > - The relying party would have a trust anchor previously configured > - The certs in the chain between the end-entity are either already possess > by the relying party or are in the x5bag header > - Then it is just a straight forward chain formation and validation. > > In this use, there is no requirement for security of the URL or for use of > TLS to fetch it. All the necessary security is provided by standard chain > validation. > > So why is there a requirement that the header be protected and that TLS/DTLS > be used? > > Further, wouldn't the header protection be a form of self signing since the > private key used to sign the header corresponds to the public key that is > being fetched?
It is in some sense a form of self-signing, yes. But TLS (or equivalent) is still needed for fetching the certificate in order to verify that the *certificate* received is the one intended, not a different certificate that wraps the same public key. There are plenty of attacks if you swap out the certificate for one with different key usage, SAN, etc. You might argue that it's hard to get a different cert (with attacker-controlled contents) for the same public key if the attacker doesn't have access to the corresponding private key, but that's not a very reliable security control. -Ben _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
