On Mon, Dec 20, 2010 at 10:46:30AM -0800, travis+ml-rbcryptogra...@subspacefield.org wrote: > libnss, at least on Linux, checks that the signing cert (chain) is valid > at the time of signature - as opposed to present time. (It may check > present time as well - not sure on that). > > This makes for problems if you renew the cert, since the new cert will > have a creation date of the current time, after the object was signed. > > Can anyone think of why this would be a good thing?
In case my argument wasn't clear... If we assume that the lifetime of the cert is there to limit its window of vulnerability to factoring, brute force, and other attacks against computational security properties, then checking the timestamp of the signature is silly - I can wait 20 years and then forge a signed object and backdate it into the window of validity. The cert lifetimes are so long that any adversary who procured the private key would use it long before the window expired, one would think. And if this were the reason for validity date ranges then reissuing with the same key makes very little sense. Revocation seems like a more timely alternative - if you detect or become aware of the leak, of course, and within the bounds of functionality of code paths that aren't actually used in normal operation. I suppose limiting the amount of ciphertext under one key is a possible reason for validity date ranges, but it's a pretty poor one. With an interactive protocol like TLS you negotiate your session keys so this doesn't make much sense. And if that were the main reason then reissuing with the same key makes zero sense. It does, however, seem to ensure a subscription-based revenue model for CAs. It would be interesting to see the actual rationale behind these things, if it were in clear language. I feel a bit like a historical archaeologist groping for find structure and meaning in something rather complex. The real problem here comes about not with TLS but when you use this library with signed PKCS objects that are to be stored and reused years later. One may argue that we can't trust the current timestamp from an adversary's computer, but this library gets the current time from the same system on which it runs, so if we can't trust the timestamp, there seems little reason to trust the validity checks in the library itself. Short of filing a bug and waiting for a fix, validating and updating the library and reshipping, or a local patch, I'm wondering if anyone has ideas on how to fix? (I'm wishing that I had filed a bug when this first came up; it wasn't my problem then, but it's mine now, sigh...) -- http://www.subspacefield.org/~travis/ | "His secure handshake is so strong, you won't be able to exchange keying material with anyone else for a week" If you are a spammer, please email j...@subspacefield.org to get blacklisted.
pgpJ9iJzgEHQQ.pgp
Description: PGP signature
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
