Updating the IETF Time Stamp standard
The IETF standard for time stamps is currently being updated - But are the changes really necessary?
The generally accepted standard for times stamps where a Time Stamp Service (TSA) issues time stamp tokens through an on-line service requires a small update to allow algorithm agility.
The core issue is that the old Time Stamping standard RFC 3161 relies on the Cryptographic Message Syntax (CMS) standards to form the time stamp token. The Enhanced Security Services (ESS) of CMS allows the signer to bind the signer’s certificate to the signed data.
Now what does that mean?
It means that if the signer of a time stamp token (the TSA) has more than 1 certificate for the same public/private key pair (which would be very odd in the first place), then we can cryptographically bind which one we should use to verify the time stamp token to the signature of the token.
Now, what we already have in RFC 3161 is a certificate identifier (ESS CertID) where the signer’s certificate is represented by a SHA-1 hash of the certificate.
In the effort to allow other hash algorithms, ESS was updated through RFC 5035 to allow other hash algorithms than SHA-1 in the certificate identifier, resulting in the expanded ESS CertIDv2.
Now for this to have ANY kind of security relevance for the time stamping protocol, a legitimate TSA must have multiple legitimate certificates for the same key pair with conflicting information in them which IN ADDITION TO THIS results in the same SHA-1 hash (produce a hash collision). Now, without being a math professor, I would say that this is pretty unlikely (understatement). In fact I would bet my hat on that there is a lot higher chance that we all get smashed by a huge comet in the near future and all bets are off anyway.
I’m very sceptic if it is worth the risk of creating interop problems to allow a solution to a non-problem.
References:
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 3852,
July 2004.
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999.
[ESSV2] Schaad, J., Enhanced Security Services (ESS) Update:
Adding CertID Algorithm Agility. RFC 5035. August 2007.
The generally accepted standard for times stamps where a Time Stamp Service (TSA) issues time stamp tokens through an on-line service requires a small update to allow algorithm agility.
The core issue is that the old Time Stamping standard RFC 3161 relies on the Cryptographic Message Syntax (CMS) standards to form the time stamp token. The Enhanced Security Services (ESS) of CMS allows the signer to bind the signer’s certificate to the signed data.
Now what does that mean?
It means that if the signer of a time stamp token (the TSA) has more than 1 certificate for the same public/private key pair (which would be very odd in the first place), then we can cryptographically bind which one we should use to verify the time stamp token to the signature of the token.
Now, what we already have in RFC 3161 is a certificate identifier (ESS CertID) where the signer’s certificate is represented by a SHA-1 hash of the certificate.
In the effort to allow other hash algorithms, ESS was updated through RFC 5035 to allow other hash algorithms than SHA-1 in the certificate identifier, resulting in the expanded ESS CertIDv2.
Now for this to have ANY kind of security relevance for the time stamping protocol, a legitimate TSA must have multiple legitimate certificates for the same key pair with conflicting information in them which IN ADDITION TO THIS results in the same SHA-1 hash (produce a hash collision). Now, without being a math professor, I would say that this is pretty unlikely (understatement). In fact I would bet my hat on that there is a lot higher chance that we all get smashed by a huge comet in the near future and all bets are off anyway.
I’m very sceptic if it is worth the risk of creating interop problems to allow a solution to a non-problem.
References:
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 3852,
July 2004.
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999.
[ESSV2] Schaad, J., Enhanced Security Services (ESS) Update:
Adding CertID Algorithm Agility. RFC 5035. August 2007.