I have been checking the code of the timestamp signer module (org.signserver.module.tsa.TimeStampSigner) and have found the following:
/**
* Generates a number of serial number bytes. The number returned should
* be a positive number.
*
* @return a BigInteger with a new random serial number.
*/
public BigInteger getSerno()
Which basically generates a random serial number.
Meanwhile, the RFC#3161 specifies the following:
The serialNumber field is an integer assigned by the TSA to each TimeStampToken. It MUST be unique for each TimeStampToken issued by a given TSA (i.e., the TSA name and serial number identify a unique TimeStampToken).
Does SignServer check if there are no serial collisions or are they simply random? If there are no collisions, where does it keep the history of "consumed" serials?
Best regards,
Luis
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The serial numbers are simply random. In SignServer 3.3 it will be possible to configure longer serial numbers (up to 160 bits) to reduce the risk of a collision.
Best regards,
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for the information Markus, helpful as always. I have been doing some numbers and, indeed, the chance of collision is extremely low (millions of billions low), even now. We are using a custom logger class, so I think we will simply throw a runtime exception at that point. That way signserver doesn't return the timestamp response and no two serials are the same.
It should never happen anyway, and a thread safe serial number generator would create a bottleneck, which could potentially generate more issues by itself.
Best regards,
Luis
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I have been checking the code of the timestamp signer module (org.signserver.module.tsa.TimeStampSigner) and have found the following:
Which basically generates a random serial number.
Meanwhile, the RFC#3161 specifies the following:
Does SignServer check if there are no serial collisions or are they simply random? If there are no collisions, where does it keep the history of "consumed" serials?
Best regards,
Luis
Hello Luis,
The serial numbers are simply random. In SignServer 3.3 it will be possible to configure longer serial numbers (up to 160 bits) to reduce the risk of a collision.
Best regards,
Markus
Thank you for the information Markus, helpful as always. I have been doing some numbers and, indeed, the chance of collision is extremely low (millions of billions low), even now. We are using a custom logger class, so I think we will simply throw a runtime exception at that point. That way signserver doesn't return the timestamp response and no two serials are the same.
It should never happen anyway, and a thread safe serial number generator would create a bottleneck, which could potentially generate more issues by itself.
Best regards,
Luis