Re: [cryptography] validating SSL cert chains timestamps
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. By the way, is there anything wrong about reissing a cert with the same serial and key but a new timestamp (date range)? -- 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. pgp35ovrOfE0y.pgp Description: PGP signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] validating SSL cert chains timestamps
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
Re: [cryptography] validating SSL cert chains timestamps
travis+ml-rbcryptogra...@subspacefield.org writes: 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, Which only occurs in textbooks. It's probably not necessary to mention that in real life the lifetime of a cert exists to enforce a CA's billing cycle, but beyond that, that it's common practice to re-certify the same key year in, year out, without changing it. So even if you have a cert issued last year, it may contain a key generated a decade ago. It does, however, seem to ensure a subscription-based revenue model for CAs. That's it exactly. 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. See above. Lifetimes were originally introduced to limit exposure but rapidly became a convenient aspect of the CA's billing cycle. In effect validFrom/validTo should be renamed renewalFeeDueBefore. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] validating SSL cert chains timestamps
On Fri, Oct 7, 2011 at 5:56 PM, Peter Gutmann pgut...@cs.auckland.ac.nzwrote: travis+ml-rbcryptogra...@subspacefield.org writes: 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, Which only occurs in textbooks. It's probably not necessary to mention that in real life the lifetime of a cert exists to enforce a CA's billing cycle, but beyond that, that it's common practice to re-certify the same key year in, year out, without changing it. So even if you have a cert issued last year, it may contain a key generated a decade ago. It does, however, seem to ensure a subscription-based revenue model for CAs. That's it exactly. As evidenced by the fact that the typical SSL server cert has a 1 year lifetime and the typical CA cert has a 10 yr (or longer) lifetime. The CAs are all about minimizing the hassle and cost to themselves and maximizing the cost (and thus profits) to everyone else. Unfortunately, there isn't much push back on this. IMO, there should be a browser tweak one could set to prevent the Danger, Will Robinson! The sky is falling and evil aliens are approaching pop-ups that the browsers seem to unanimously give. Sometimes it seems like there are in cahoots with the CAs. -kevin -- Blog: http://off-the-wall-security.blogspot.com/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We *cause* accidents.-- Nathaniel Borenstein ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] validating SSL cert chains timestamps
On Fri, Oct 7, 2011 at 7:59 PM, Kevin W. Wall kevin.w.w...@gmail.com wrote: On Fri, Oct 7, 2011 at 5:56 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: travis+ml-rbcryptogra...@subspacefield.org writes: 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, Which only occurs in textbooks. It's probably not necessary to mention that in real life the lifetime of a cert exists to enforce a CA's billing cycle, but beyond that, that it's common practice to re-certify the same key year in, year out, without changing it. So even if you have a cert issued last year, it may contain a key generated a decade ago. It does, however, seem to ensure a subscription-based revenue model for CAs. That's it exactly. As evidenced by the fact that the typical SSL server cert has a 1 year lifetime and the typical CA cert has a 10 yr (or longer) lifetime. It looks like 20 to 30 years: https://spreadsheets.google.com/pub?key=ttwCVzDVuWzZYaDosdU6e3wsingle=truegid=0 (Mozilla's CA list). Ignore the broken links to security policies and 3 year old audits. Just trust that everything is OK (CAs are busy doing other things, and some don't have time to do things like update documentation or audits). Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
