That’s an interesting point, but it depends on your definition of
expiration. For time stamped signatures, the expiration is treated as the
expiration of the timestamp validation chain, not the entity validation
chain. This means timestamped signatures have to potentially support a much
larger CRL size for verification. With a simple digital signature, you can’t
determine if it was signed before or after the entity certificate
expiration, so you have to treat the entity certificate expiration as the
end of verifiability, and you can also discard CRL entries for expired
certificates.
The expiration date does protect the certificate owner. If it’s stolen,
there is a definite time window of when signatures can be done. If the
certificate is revoked on a time-stamped signature, the CA should be
checking the CRL at the moment of timestamping, and rejecting attempts to
timestamp revoked or expired certificates. The entity certificate expiration
still helps managed the CRL size, as at the time of timestamping, the CRL
check only has to contain revoked certificates up to their expiration. After
their expiration, all certificates are rejected for timestamping.
Apple code signing I believe use much shorter expiration times on their
developer certificates, which does a better job of containing the damage
from a stolen certificates. Code signing certificates also come essentially
for free, if you pay the $99/year development program fee.
As far a price goes, keep in mind the price VeriSign charges has to cover
costs for maintaining the timestamp server and the CRL database. This is an
ongoing operational cost, not a one time cost of a few milliseconds of cpu
time. Doesn’t Visa charge a merchant like $0.30 (and a few percent of the
transaction value) for every credit card transaction processed? Let’s see,
if each transaction to the timestamp server cost $0.30, and I have say 3
signatures in my product (kernel code, .cat, install package), and my build
system runs every day, that’s like $300 in timestamp server transactions
charges per year. Based on typical transaction fees, code signing
certificates may not be priced all that outrageously. We might be worse off
if VeriSign gives away the code signing certificate for free, but charges us
$0.30 each time we use the timestamping server. I suppose if we were charged
per timestamp transaction, we would be very motivated to only use
self-signed test certificates during builds. Effectively, buying a code
signing certificate is also buying a bucket of timestamp server transactions
bundled into the price. This is a difference than an SSL certificate, which
does not have an ongoing stream of timestamp requests.
Jan
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-425336-
xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Saturday, September 18, 2010 9:59 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] FYI - VeriSign has code signing certificates on sale
> The CRL only needs to contain unexpired certificates.
If true, that sounds like a huge security hole in the existing model. It
means if
a malware producer signs & timestamps their ware, then simply waits to
release until the day after the cert they used expires, then there is no
way to
deal with it. Astonishing oversight.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer