[cryptography] How are expired code-signing certs revoked?

Peter Gutmann pgut001 at cs.auckland.ac.nz
Wed Dec 7 16:48:04 EST 2011


ianG <iang at iang.org> 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.




More information about the cryptography mailing list