ianG <[email protected]> writes: >However, if one is relying on an external TTP to time-stamp the digital >signature, one can also rely on the TTP to evidence the hash of the document. >In which case, the digital signature is not performing any signing task >(although it may form a local authentication role, or may not, as the case >may be). In this case the act of presenting the hash for external time-stamp >is the act of signing, not the act of affixing a digital signature.
You have to remember that using TSAs for code is used purely as a means of getting around the fact that for CA billing purposes the code-signing cert expires after one year. You need to extend this in some PKI-compliant manner in some way, and timestamping is the only obviously available way to do it. If you want to extend it in a non-PKI-compliant manner you just ignore cert expiration for code signatures, as the Java folks did when they removed any certificate-expiry checks in JCE 1.2.2 after the expiry of the JCE 1.2.1 certificate on 27 July 2005 caused considerable pain for vendors of products that used it. Alongside TB2F CA certs, code-signing TSA certs are another example of irrevocable certs, which would make them tempting targets for theft. Unlike CA roots, they have to be kept online at all times since they're used for automated code-signing. There are probably many more examples of certs in similar too-critical-to-revoke certs that can't be protected as well as CA roots. How many can you spot? Peter. _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
