xAPI-Spec icon indicating copy to clipboard operation
xAPI-Spec copied to clipboard

Multiple Signature Verification

Open andyjohnson opened this issue 8 years ago • 5 comments

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 avatar Jan 18 '17 19:01 andyjohnson

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.

andyjohnson avatar Jan 18 '17 19:01 andyjohnson

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.

brianjmiller avatar Jan 18 '17 21:01 brianjmiller

@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).

garemoko avatar Jan 19 '17 09:01 garemoko

"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.

brianjmiller avatar Jan 21 '17 13:01 brianjmiller

@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?

rchadwic avatar Apr 06 '17 17:04 rchadwic