Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm writing some code to digitally sign certain files (JSON, if you must know), and I'm trying to understand the use cases, not being a crypto guy myself.

I understand there are use cases where several parties all need to sign the same content, e.g. the two parties who enter a contract sign it to indicate their approval.

But are there use cases where B signs not just the content (of the contract, or whatever), but the concatenation of content plus the previously-created signature by A of the content?

Update: given this discussion, I created a proposal that I believe covers the case in case you are interested:

share|improve this question
You should take a look at JSON Web Signature (JWS). I didn't read it myself, so I can't vouch for its quality. – CodesInChaos Mar 13 '14 at 21:12
Duh! I was looking for something like that and failed to find it. Thanks for pointing it out. – Johannes Ernst Mar 13 '14 at 21:14
From what I can tell, this is about representing the signature/metadata in JSON, assuming blobs as payload, so it doesn't really address my use case. – Johannes Ernst Mar 13 '14 at 21:20
up vote 5 down vote accepted

In a nutshell there are two main uses cases for signing an existing signature:

  • validation: the signature of another person (ex: a superior) is required to give effect to a primary signature. The second signature covers the content, the first signature and potentially additional data added by the second signer.
  • witness / notary: a second person signs only the first signature, to vouch that the person applying the first signature is indeed the right one. Contrary to the previous case, the content is not covered by the second signature, because the second signer does not commit to it.
share|improve this answer

Yes. An independent witness to the signing may vouch for the initial signing, and do so by signing the whole document. E.g. this could indicate that the signing was done by an officer of the company and not a rogue employee.

share|improve this answer
Thank you for actually answering my question :-) – Johannes Ernst Mar 13 '14 at 22:24

Another usecase for "signing a signature" could be a timestamp service:

The original document was signed by Alice. To be later able to prove that Alice did sign before some date, Alice (or Bob) submits it to a timestamp service (Tim). Tim adds a time stamp and signs the combination of "timestamp, Alice's signature".

Later Bob can prove that Alice signed the document before some time.

share|improve this answer

Maybe. Why not? Why would you rule this out? A signature is just bits. When you sign a message, you sign a stream of bits. If you are implementing a signature API, your API should allow a signer to sign any byte-sequence they like, and should allow them to get the signature as a byte-sequence. I can't imagine any reason why you would prohibit that. And if you allow that, the use case is already covered. So, I'm not clear why you are asking. What problem are you trying to solve? How will the answer to this question change how you design/implement your code?

share|improve this answer
Because of the particular structure of my payload: it has certain processing advantages to put the signature and associated meta-data into the signed JSON itself as JSON fields. (e.g. it remains a JSON document and can be fetched over the network in a single operation) – Johannes Ernst Mar 13 '14 at 21:12
@JohannesErnst I'd rather encapsulate it, like {data={...}, sigs=[{sig1}, {sig2}]}. If one signature needs to be signed, the outer signature can encapsulate the previous one, else add them to the array. – CodesInChaos Mar 13 '14 at 21:14
@CodesInChaos: there's some advantage to that, I agree, but the downside is that the structure of the JSON document changes (it is now a child of "data") which means existing parsers would have to be changed. – Johannes Ernst Mar 13 '14 at 21:18

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.