> On Oct 22, 2020, at 8:21 AM, Benjamin Kaduk <[email protected]> wrote: > > 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.
Hi Ben, It seems like your are interpreting the x5u header to be for the fetching of a single validated end-entity certificate. Some remote service did the cert chain validation. You and other folks probably were involved in some ace work that I was not involved with to know that. I don’t think it says that clearly in cose-x509, though I can now see how you can triangulate your way to that understanding. If x5u is to work like this, it seems a lot of addition to security considerations is needed. RFC 2585 does not work this way. It assumes the chain validation is done locally (see RFC 2585 Security Considerations) and that there is no need for any transport layer security. This seems like a perfectly useful and good thing to do and to support in cose-x509. This is what I outlined in bullet points above. When I think about implementing cose-x509, I can see several options. 1. Just implement x5chain. Fail if x5chain is not present. Only need code for chain validation. No need for chain formation. 2. Just implement x5bag and x5t. Fail if x5t and x5bag are not present. Now you need code for chain validation and chain formation. 3. Just implement x5u. Fail if x5u is not present. All you need is some ASN.1 parsing and DTLS code. No chain validation or formation needed. 4. Implement all, with a priority order like first try x5chain, then try x5bag/x5t, finally x5u. 5. Various combinations of the above If RFC 2585 (non-validated) fetching is allowed, then further options… LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
