Re: Has any public CA ever had their certificate revoked?
Paul Hoffman paul.hoff...@vpnc.org writes: Peter, you really need more detents on the knob for your hyperbole setting. nothing happened is flat-out wrong: the CA fixed the problem and researched all related problems that it could find. Perhaps you meant the CA was not punished: that would be correct in this case. What I meant was that there were no repercussions due to the CA acting negligently. This is nothing happened as far as motivating CAs to exercise diligence is concerned, you can be as negligent as you like but as long as you look suitably embarassed afterwards there are no repercussions (that is, there's no evidence that there was any exodus of customers from the CA, or any other CA that's done similar things in the past). Imagine if a surgeon used rusty scalpels and randomly killed patients, or a bank handed out money to anyone walking in the door and claiming to have an account there, or a restaurant served spoiled food, or ... . The repercussions in all of these cases would be quite severe. However when several CAs exhibited the same level of carelessness, they looked a bit embarassed and then went back to business as usual. The CA-as-a-certificate- vending-machine problem (or rogue CA if you want to call it that) had been known for years (Verisign's Microsoft certificates of 2001 were the first case that got widespread publicity) but since there are no repercussions for CAs doing this there's no incentive for anything to change. This leads to the question: if a CA in a trust anchor pile does something wrong (terribly wrong, in this case) and fixes it, should they be punished? If a CA in a trust anchor pile does something terribly wrong and there are no repercussions, why would any CA care about doing things right? All that does is drive up costs. The perverse incentive that this creates is for CAs to ship as many certificates as possible while applying as little effort as possible. And thus we have the current state of commercial PKI. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CSPRNG algorithms
Travis travis+ml-cryptogra...@subspacefield.org writes: I have never seen a good catalog of computationally-strong pseudo-random number generators. It seems that everyone tries to roll their own in whatever application they are using, and I bet there's a lot of waste and inefficiency and re-inventing the wheel involved. If this true, or is there a survey somewhere? I did a (hopefully) reasonably comprehensive analysis of what was around in the late 90s in my thesis, available via http://researchspace.auckland.ac.nz/handle/2292/2310 (there's an updated version available as Cryptographic security architecture: design and verification, published by Springer), specifically chapter 6, Random number generation. This covers PRNGs from AC2, X9.17, PGP 5.x, /dev/random, Skip, ssh (that is, the ssh.com implementation), SSLeay/OpenSSL, CryptoAPI, Capstone/Fortezza, the Intel PIII generator, and some other bits. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Solving password problems one at a time, Re: The password-reset paradox
Ben Laurie b...@links.org writes: Incidentally, the reason we don't use EKE (and many other useful schemes) is not because they don't solve our problems, its because the rights holders won't let us use them. That's not the reason, TLS-SRP isn't that annoyingly encumbered, and even the totally unencumbered TLS-PSK doesn't get used by anyone. I was told a reason for the lack of use of strong password protocols from one browser vendor that was so stunningly stupid that I had trouble beliving that it was for real, ask me in private mail if you want the details. In any case though it's not patent issues that are leading to non-use. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Has any public CA ever had their certificate revoked?
At 1:02 AM +1200 5/7/09, Peter Gutmann wrote: Paul Hoffman paul.hoff...@vpnc.org writes: Peter, you really need more detents on the knob for your hyperbole setting. nothing happened is flat-out wrong: the CA fixed the problem and researched all related problems that it could find. Perhaps you meant the CA was not punished: that would be correct in this case. What I meant was that there were no repercussions due to the CA acting negligently. We agree fully, then. This is nothing happened as far as motivating CAs to exercise diligence is concerned, you can be as negligent as you like but as long as you look suitably embarassed afterwards there are no repercussions (that is, there's no evidence that there was any exodus of customers from the CA, or any other CA that's done similar things in the past). This assertion is probably, but unprovably, wrong. I suspect the CA now has better mechanisms in place to check for the problem in the future, and I suspect that a few other CAs seeing the kerfuffle probably added their own automated checks. Note that these are checks that should have been in place before the error was found. Imagine if a surgeon used rusty scalpels and randomly killed patients, or a bank handed out money to anyone walking in the door and claiming to have an account there, or a restaurant served spoiled food, or ... . The repercussions in all of these cases would be quite severe. However when several CAs exhibited the same level of carelessness, they looked a bit embarassed and then went back to business as usual. ...because not only did no one die, but also the CAs were able to fix the problem. The CA-as-a-certificate- vending-machine problem (or rogue CA if you want to call it that) had been known for years (Verisign's Microsoft certificates of 2001 were the first case that got widespread publicity) but since there are no repercussions for CAs doing this there's no incentive for anything to change. s/no/small/ This leads to the question: if a CA in a trust anchor pile does something wrong (terribly wrong, in this case) and fixes it, should they be punished? If a CA in a trust anchor pile does something terribly wrong and there are no repercussions, why would any CA care about doing things right? Slight worry about making a more serious mistake than happened here. All that does is drive up costs. The perverse incentive that this creates is for CAs to ship as many certificates as possible while applying as little effort as possible. And thus we have the current state of commercial PKI. Fully agree. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: SHA-1 collisions now at 2^{52}?
Perry E. Metzger pe...@piermont.com writes: Home routers and other equipment last for years. If we slowly roll out various protocol and system updates now, then in a number of years, when we find ourselves with real trouble, a lot of them will already be updated because new ones won't have issues. I'm not really sure if it works that way. From my experience with SSH in routers [0] I'd say it's more like: Binary images in routers last years. If we deploy first-cut, buggy implementations of new protocols now, we'll have to support the bugs in a backwards-compatible manner for the rest of eternity. That is, in the absence of widely-deployed, mature implementations to test against, router vendors will (if they were to ship with this right now) deploy pre-alpha quality code that would then be frozen for the rest of eternity. I have to maintain support for ten-year-old SSH bugs in my code because of ports to... well, unnamed vendors' systems done a decade or so back that never get touched again once the initial version got to the point where it would respond to a packet. So if vendors are going to bake things into firmware (which includes firmware images that never get updated, more or less the same thing) then I'd prefer they hold on a bit until it's certain they've got somewhat more mature code. Peter. [0] Implementations of this are easier to date than SSL, and also a lot buggier so there's more to watch out for. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
