User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 Build Identifier: Sometimes Firefox browser returns the value "SPKAC=2048 (High Grade)", "SPKAC=1024 (Medium Grade)" or other variations of it depending on the language used (for example "SPKAC=2048(Högnivå)"), instead of the request value when using the keygen tag. We use the keygen tag to create SPKAC private key and request and it happens from time to time. I can't reproduce it, but all of the users use Firefox 1.5 or higher usually on Windows. Usually it affects that browser and retrying it doesn't solve the problem, therefor I believe that it is reproducible by users which are affected by it. Reproducible: Didn't try Steps to Reproduce: 1. Using html with <keygen name="somename"> 2. User submits the form 3. Return value is SPKAC=2048 (High Grade) instead of something like SPKAC=MIICQDCCASgwgg....very-long-value...GAlpqOgA== Actual Results: Return value is SPKAC=2048 (High Grade)of keygen tag Expected Results: Expecting something like SPKAC=MIICQDCCASgwgg....very-long-value...GAlpqOgA== Happens randomly and only from time to time.

Eddy, could you contact some of your users who've had this experience and ask them if they'd be willing to participate in some testing? It would be useful to find out if this happens only occasionally to them, or every time or ...

Sure, contacted a few of the most recent such failed requests. Apparently it happens in about 3% of all requests. It seems to be more common in version of languages other than English, specially proportional. But nevertheless it happens also with English versions, just much less. I hope we'll get soon some more information about this issue together.

I just received the email from Eddy that apparently one of my requests was effected by this bug. I'll gladly do what I can to help reproduce it, just let me know what I should do.

To anyone who has experienced this bug: please start by adding a comment here, telling us what version of the browser you were using when you experienced it. You can get that information from the URL "about:" which is the same as going to the "About" selection in your browser's help menu. Perhaps we will devise a test page on a test web site to help us determine how frequently it can be reproduced with your browser.

Kai, Can you determine by code inspection what sorts of conditions could cause the key size menu string to be returned in place of the computed result? We know that RSA key pair generation sometimes fails due to failure to find a prime number within a limited number of trials. Could failure to generate the RSA key pair lead to this problem? Are any other causes apparent? It would be quite disconcerting to learn that RSA key pair generation is failing for about 3% of the attempts! If it is caused by key pair gen failure, then one would predict that it would happen in a higher percentage of cases for larger keys than for smaller ones. Eddy, since the strings that appear in the keygen results appear to report the selected key size, can you report any statistics of what percentage of the failures occurred with 2kb keys, vs 1kb keys or 512b keys?

(In reply to comment #5) > Eddy, since the strings that appear in the keygen results appear to report > the selected key size, can you report any statistics of what percentage of > the failures occurred with 2kb keys, vs 1kb keys or 512b keys? > The answer might not really useful, since the default selections is 2048 bit key size. Almost obviously the ratio is about 100 to 4 in favor for 2048. Since the user must deliberately change that selection, it might prove that the key size isn't really the issue here. Just by feeling, it looks like that this issue hasn't much to do with the key pair generation itself, but rather with the way the select box itself assigns the value. I haven't looked at any code...so I might be wrong. However I think this, because the value which is send after submit is exactly what's displayed in the label. I've got a full collection of those: 2048(HighGrade),2048(altonivel),2048(hogegraads),2048(hoheStufe), 2048(Высокаястепень),2048(Hautgrade)... One small correction I have to make is, that the part "SPKAC=" as reported at the beginning of this bug isn't actually sent by the keygen tag, but added on the server side. Sorry about that, but thought it important to mention.

OK, I was able to track one user agent where this happened: "Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8". I've asked the user in question to participate here so we may make some more tests.

I've seen this before, too. I've attached a snippet from my Apache log so that one can further find out which versions are affected. I believe this problems has been existant for quite a while - OpenXPKI checks for a string that is too small because of this bug since more than a year ago ...

Another system reported now to me was Firefox, version 2.0.0.8 on Linux (Slackware, 10.2). It appears that this bug happens on all platforms.

I'm the linux/2.0.0.8. I just repeated the process I followed yesterday (up to a point at least). It was: Select the Creation Wizard, select class 1, continue, select s/mime, continue, fill in the screen with values, continue, fill in the state/province (the only field left open), continue. I then get a popup. The titlebar shows "Password Required", the Caption is 'Please enter the master password for the Software Security Device". This popup has both Cancel and OK buttons. I press the Cancel button. Today, I got a message at this point complaining that the e-mail address exists and was not revoked. Before, I got an e-mail with a verification code. Hope this helps. If you want me to try something else, let me know.

OK, the last message was very helpful! I could reproduce the bug, which essentially happens when the browser never used a certificate before and the master password for the software device wasn't set. When the user cancels the action we receive the said response from the keygen tag.

And now somewhat clearer: This also happens every time a new session is started (i.e. restarting Firefox). When trying to generate a new key with the keygen tag the browser asks for the master password (once per new session). When clicking on cancel, the key never gets generated and the submission continues nevertheless with said value of the keygen tag 2048(HighGrade). Solution: If key generation fails for whatever reason the form should never submit but a message displayed to the user about the failure. Please confirm this as a bug!

I confirm. Good Job investigating this, guys!

We are not allocating resources to fixing keygen issues.