adlnet / xAPI-Spec

The xAPI Specification describes communication about learner activity and experiences between technologies.
https://adlnet.gov/projects/xapi/
898 stars 404 forks source link

Multiple Signature Verification #1023

Open andyjohnson opened 7 years ago

andyjohnson commented 7 years ago

From the ADL Tech Team - What is the proper algorithm for verifying the signatures of a statement when there are multiple signatures? We find that it's impossible for the payload of the JWT to be correct for both signatures - because the payload of the second signature would include the metadata block of the first signature. This is causing a payload/statement mismatch when validating one of the 2 sigs. We propose that the validation of the signatures be updated to require a reverse traversal of the list of attachments. You must pop off the metadata block from the statement for the current signature before comparing the payloads. The next signature in reverse order should be verified in the same way, popping off the next attachment metadata block.

andyjohnson commented 7 years ago

Per the 1/18/17 call - spec should either not allow multiple signatures or outline a process on how to do it (which would need a slight modification to current behavior). Right now this isn't a MUST (thus not affecting conformance), so we can take time to come up with a sound recommendation.

brianjmiller commented 7 years ago

I'm a little bit curious what the use case for multiple signatures is in the first case. That would mean that two private keys have been exposed in the same place which would negatively effect the trust of either key so as to make them basically unusable.

garemoko commented 7 years ago

@brianjmiller good point. 'Basically unusable' is probably a little strong if the system that has access to the keys is highly trusted, but still, it's far from an ideal scenario.

The use case discussed on the call was where there are two authorities that want to assert the thing: the learner and the organization providing the training. There are definitely ways of solving that without having multiple signatures in one statement though (e.g. multiple statements with different authorities or using statement references).

brianjmiller commented 7 years ago

"Strong" is relative to the extent that you feel a key can ever be trusted. I certainly wouldn't want my key co-mingled with another just for this purpose. I agree completely that multiple statements (each signed by their respective keys) is a much better implementation.

rchadwic commented 7 years ago

@brianjmiller So sorry this sat so long with out further discussion. I'm confused by your comment about exposing private keys - in the system I'm working on, we have one signature signed server side (verifying some aspects of the data) and the client signs the statements before they are sent. In both cases, the private key is never exposed beyond the system doing the signing. The server key is private to the server and the client's key is private to the client. How are these keys leaked?