Reduce key length for IE8

[callahad]

Recommended is 1024 for certs with a 6 hour validity.

[jrgm]

Hey, so is this 2048 now, or have you reduced the key length to 1024/6h? Just curious because IE9 and Opera (both on VM) can fail too ;-)

[callahad]

I'm still not terribly familiar with jwcrypto... @jrgm, do you know where key length is configured?

[jrgm]

Belated answer. No I don't offhand, but @lloyd, @benadida, @ozten, or @warner should be able to advise.

I'd really like to make use of mockmyid in tests (and delegate.es which is delegation to mockmyid), but it's flaky/painful/fail on IE8 (and IE9, Opera).

[jrgm]

Seems IE10 also cannot work with mockmyid.com.

[callahad]

I think we need to get multiple key support into the .well-known document before I make this change -- there are some applications that are hardcoding mockmyid's private key so they can locally generate identity certificates.. I'd rather not break them.

[jrgm]

One minor note for people who see this with IE10 - IE10 appears to try to fallback to a compatibility mode when the cpu has spun out of control for a while and then fails because "Error: 'JSON' is undefined".

[callahad]

bah, wtf IE? :(

[jaredhirsch]

@callahad I just got the long-running script error on IE8. Is this the same issue?

If it is, I'm happy to help debug.

IE throws this error after some number of consecutive JS commands have run without the UI thread getting a turn, so one fix is to run for (say) 100ms, then use setTimeout(0) to throw the remainder of the computation on the back of the stack, and continue the execution after the UI thread runs.

[callahad]

@6a68 The quick fix is to generate a new, smaller key for mockmyid. At the time, it looked like multiple key support was imminent, and I didn't want to break folks relying on that key not changing. Guess it's time to make that happen regardless.

[lloyd]

Wait, this is related to size of client side generated keypairs. The signing keypairs should be irrelevant from a perf perspective.

s/256/128/ in js.

-- lloyd (thumb-typing)

On Apr 19, 2013, at 7:38 PM, Dan Callahan [email protected] wrote:

@6a68 The quick fix is to generate a new, smaller key for mockmyid. At the time, it looked like multiple key support was imminent, and I didn't want to break folks relying on that key not changing. Guess it's time to make that happen regardless.

—
Reply to this email directly or view it on GitHub.

[callahad]

@lloyd I'm doing all of the cert generation client side -- there's no backend to mockmyid. Current theory is that this is an issue with the domain's key size and type being a bit too much to handle for IE.

[benadida]

Reducing key size to make mockmyid work seems like the wrong trade-off.
However if it's too slow even for normal IdPs, then that makes a lot more
sense.
On Apr 19, 2013 7:30 PM, "Dan Callahan" [email protected] wrote:

@lloyd https://github.com/lloyd I'm doing all of the cert generation
client side -- there's no backend to mockmyid. Current theory is that this
is an issue with the domain's key size and type being a bit too much to
handle for IE.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-16697386
.

[lloyd]

Agree. Was not proposing we change anything in persona. Just forgot there for a moment that user key length is completely under persona control.

-- lloyd (thumb-typing)

On Apr 19, 2013, at 8:38 PM, Ben Adida [email protected] wrote:

Reducing key size to make mockmyid work seems like the wrong trade-off.
However if it's too slow even for normal IdPs, then that makes a lot more
sense.
On Apr 19, 2013 7:30 PM, "Dan Callahan" [email protected] wrote:

@lloyd https://github.com/lloyd I'm doing all of the cert generation
client side -- there's no backend to mockmyid. Current theory is that this
is an issue with the domain's key size and type being a bit too much to
handle for IE.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-16697386
.

—
Reply to this email directly or view it on GitHub.

[callahad]

@benadida I'm not sure I follow? MockMyID is signing with an RS256 key right now. Switching to DS128 fixes it. Normally, these computations would be done server-side, so it's moot for "real" IdPs.

[benadida]

@callahad I'm an idiot and thought this was a bug in the browserid repo. Don't mind me.

[jaredhirsch]

@callahad @benadida I'd argue that a client-side crypto library should always use setTimeout/setImmediate to break up calculations to avoid the long-running script error; this is a fundamental limitation of working in the browser. Maybe I'll file my issue against jwcrypto? /cc @warner

Nicholas Zakas has written a good series of articles on the subject of understanding and avoiding the long-running script error:

• http://www.nczonline.net/blog/2009/01/05/what-determines-that-a-script-is-long-running/
• http://www.nczonline.net/blog/2009/01/13/speed-up-your-javascript-part-1/
• http://www.nczonline.net/blog/2009/08/11/timed-array-processing-in-javascript/
• http://www.nczonline.net/blog/2011/09/19/script-yielding-with-setimmediate/

[benadida]

For sure, but it's tricky cause we use existing crypto libraries that are
not async/pipelined, and making them so didn't look trivial.
On Apr 20, 2013 10:53 AM, "Jared Hirsch" [email protected] wrote:

@callahad https://github.com/callahad @benadidahttps://github.com/benadidaI'd argue that a client-side crypto library should always use
setTimeout/setImmediate to break up calculations to avoid the long-running
script error; this is a fundamental limitation of working in the browser.
Maybe I'll file my issue against jwcrypto? /cc @warnerhttps://github.com/warner

Nicholas Zakas has written a good series of articles on the subject of
understanding and avoiding the long-running script error:

http://www.nczonline.net/blog/2009/01/05/what-determines-that-a-script-is-long-running/

http://www.nczonline.net/blog/2009/01/13/speed-up-your-javascript-part-1/

http://www.nczonline.net/blog/2009/08/11/timed-array-processing-in-javascript/

http://www.nczonline.net/blog/2011/09/19/script-yielding-with-setimmediate/

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-16708276
.

[lloyd]

Callahad reduced mockmyid domain key length to 1024/dsa and it resolved this. Patch forthcoming iirc. No changes to persona needed.

Ben, in your defense, I was an idiot too. Idp can't affect user keypair length. Duh.

-- lloyd (thumb-typing)

On Apr 20, 2013, at 11:58 AM, Ben Adida [email protected] wrote:

For sure, but it's tricky cause we use existing crypto libraries that are
not async/pipelined, and making them so didn't look trivial.
On Apr 20, 2013 10:53 AM, "Jared Hirsch" [email protected] wrote:

@callahad https://github.com/callahad @benadidahttps://github.com/benadidaI'd argue that a client-side crypto library should always use
setTimeout/setImmediate to break up calculations to avoid the long-running
script error; this is a fundamental limitation of working in the browser.
Maybe I'll file my issue against jwcrypto? /cc @warnerhttps://github.com/warner

Nicholas Zakas has written a good series of articles on the subject of
understanding and avoiding the long-running script error:

http://www.nczonline.net/blog/2009/01/05/what-determines-that-a-script-is-long-running/

http://www.nczonline.net/blog/2009/01/13/speed-up-your-javascript-part-1/

http://www.nczonline.net/blog/2009/08/11/timed-array-processing-in-javascript/

http://www.nczonline.net/blog/2011/09/19/script-yielding-with-setimmediate/

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-16708276
.

—
Reply to this email directly or view it on GitHub.