Let clients decide wether they want the full chain in the timestamp

[elbosso]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

What is it about?

As was written in the release announcement for 1.3.0 - some tools issued warnings about being unable to validate the trust chain (PKIX-errors) when this server was used to issue timestamps as it only included the immediate signers certificate and left out any certificates of intermediary or root CAs.

Version 1.3.0 changed that - the admin can now decide to include the complete chain in the timestamp. As this eats up bandwidth -it is not ideal.

A better way would be to let the client decide what s/he wants. I will go on and collect some thoughts around this idea ant what it means for backward compatibility and further development in the next few days...

[elbosso]

Letting the client decide means to decide how this could be done - I see two possibilities: either by offering two different endpoints or by introducing a new optional parameter to the one already existing

[elbosso]

But this opens up a whole lot of questions about persistence: If a user wants a timestamp for hash A and s/he decides to not want the chain certificates included - how should requests be treated later for the timestamp? we could use the approach, that only the one requested is persisted - but that leads to a paradoxical situation: the original requestor may decide freely which variant he wants but subsequent queries do not offer that flexibility.
It would be better - or feel more natural - to always have the choice.
But that would mean with each request must be two timestamps created - one with and one without the chain certificates. Then, both must be persisted and the one requestsed is to be returned. This would allow that later searches for the timestamp could wish for either form and would be successful.