Earlier quoted context omitted.
Non-repudiation means that the party that sent a message cannot later deny having sent it. In TLS both sides negotiate a shared secret key(s) that they then use for fast symmetric crypto for the actual messages. Symmetric because both sides know the same keys. This means that after the fact either side can claim that the other side fabricated messages that apparently came from them, because they could have done. The…
I now understand your first point. > The point about losing keys is that if I can plausibly claim that I “lost” control of my key then I can claim that an imposter signed a message that apparently came from me. So even with digital signatures you usually need additional controls (hardware, processes, legal/regulatory etc) to really guarantee non-repudiation. Depends on the use-case right? For example,foss projects us…
Why Mastercard Doesn't Use OAuth 2.0
51–56 of 56 posts
Re: Why Mastercard Doesn't Use OAuth 2.0
#52Earlier quoted context omitted.
Can't they just also require that their implementation of OAuth2 also requires a signed payload?
Then it would no longer be oauth2? Standards exist to prevent deviations. How do you manage signing keys and distribute them? What signature scheme,encoding,etc... Should be used?
Re: Why Mastercard Doesn't Use OAuth 2.0
#53It's worth noting that message-level integrity was not a design goal of OAuth 1; it is was a consequence of being based on OpenID 1/2, which were explicitly meant to run on HTTP without TLS so that they could be adopted by blogs. This was pre SNI, and pre cheap certs, so requiring HTTPS increased the hosting cost of a blog by an order of magnitude.
When the constraints changed such that requiring HTTPS was feasible, it greatly simplified OAuth. Some of these simplified proposals for OAuth became the input for OAuth 2 (where complexity was subsequently added back in the form of variants to support new use cases).
Relying on message level integrity in a protocol where such a thing was basically a side-effect of avoiding hosting costs would make me very nervous.
The clearest issue I can point to is that there is no response message integrity in MasterCard's system - an intermediary can block requests to MasterCard and give back fraudulent responses (yes, of course that payment went through!). This throws a ton of application-dependent security considerations into the system.
Re: Why Mastercard Doesn't Use OAuth 2.0
#54Earlier quoted context omitted.
Notice of course that that little stunt resulted in them being removed from everybody's trust stores. And it's not like you can just get away with it these days, since certificates are all publicly logged now.
Not everybody's. There is whole China where the certs remain installed.