Below... > On Oct 22, 2020, at 12:12 PM, Benjamin Kaduk <ka...@mit.edu> wrote: > > Hi Laurence, > > On Thu, Oct 22, 2020 at 11:56:24AM -0700, Laurence Lundblade wrote: >> >>> On Oct 22, 2020, at 8:21 AM, Benjamin Kaduk <ka...@mit.edu> 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 > > I do not believe I am doing so. The TLS (or other) authentication of the > URI target does not inherently stand in for local validation of the > certificate and chain. (There may be particular special cases arranged by > policy where it does, but not in the general case.) > > I am saying that you can have multiple certificates, call them A and B, > that certify the same public key K. Knowing K, you can validate the > message signature, protected attributes, etc., including the URI used to > fetch the certificate. However, if the URI used to fetch the certificate > uses a scheme that does not provide integrity protection or server > authentication, then the party dereferencing the URI could obtain > certificate A when the message originator intended for certificate B to be > used for validation. It is not too hard to imagine situations where both A > and B can be used to build valid chains that end at root CAs trusted by the > message recipient, and thus the insecure certificate fetch is (1) > undetected and (2) causes the message to be interpreted differently than > intended by the originator. As I mentioned originally, A and B could have > different X.509 extensions, (extended) key usage, subject information, > etc., so there is a lot of room for the "interpreted differently" to be > attacked.
But isn’t this a problem with any and all cert chain construction and validation? If this is an issue, then x5bag and x5chain should be protected headers. Seems like the real problem is CA operation. CA’s shouldn’t be creating alternate certs for real keys that result in issues like this. So it still seems to me that the primary reason for an x5u that is a protected header parameter and obtained with DTLS is so you don’t have to validate the end-entity on the constrained device. Presumably you already have a DTLS stack, so you are almost getting the validated cert for no extra code. > >> 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. > > With RFC 2585 you know enough information about the *certificate* that you > want that you have what is (supposed to be, at least) a unique identifier > for the *certificate*. In the "x5u" case you only have information about a > *key*, not a certificate. I’m not understanding how x5u is about a key, not about a certificate. > >> >> 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 > > I believe that there is some intent to use x5t for cases where the > certificates in question are already in local storage on both parties, so > the thumbprint is just a shortand reference for "use this one [that you > already have]"; no need for the x5bag. Yes, agreed. Might not even need any chain formation code if the hierarchy is simple and certs are pre-distributed. > [Probably more comments possible here, but I didn't think very hard.] > > -Ben LL
_______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
