Client@ff6: page loading stalls if more than two nodes are enabled about convergence HOT 14 CLOSED

Distros are Archlinux and Debian

Jonns Mostovoys,
DA234FE7

from convergence.

What is a "node?" In general, please confirm bugs against FF5. Convergence hasn't been ported to FF6 yet, and it isn't supported.

from convergence.

Sorry, nodes are notaries, ofc.

I'll test it in ff5, sure thing. Sorry for not doing that in the first place.

Though I think that it's obvious that ff6 needs support, and thus testing. But the point taken.

Jonns Mostovoys,
DA234FE7

from convergence.

True enough, I'd just like to keep the "ff6 is broken" problems in the ff6 thread, and there were/are some fundamental changes that needed to be made before we could expect anything to work there. Thanks for all the help.

from convergence.

One problem I've run in to related to this: Convergence throws an exception when calling ctypes.NSS.CERT_AsciiToName. After a lot of searching through the nss source code, it turns out libnss enforces the RFC3280 specification that the OU field has a maximum length of 64 characters. This is violated when using more than 2 notaries since Convergence is using this field to hold notary results.

from convergence.

@melknin Damn, that's a good catch, thanks. It seems like we should start shoving the results somewhere else, then. Possibly a v3 extension.

from convergence.

Was considering we could write it in as our own x.509 extension, but there is still a 256 character limit there (is it per an extension?)

from convergence.

I was able to update the bit of code which updates the OU to instead put the result into one of the v3 extensions (I went with Issuer Alternative Name, although pretty much any would work), but I have not checked whether or not a character limit is imposed.
Either way I ran into an issue on the tooltip end; I couldn't find any method in the Mozilla interface for getting the v3 extensions out of the certificate (http://www.oxymoronical.com/experiments/apidocs/interface/nsIX509Cert).

from convergence.

I double-checked and there doesn't appear to be any length restriction on the x509 extensions (instead, the 256 limit is on the number of extensions while the extensions themselves have no explicit maximum length). To test, I was able to encode 270 characters into the IssuerAltName extension.

One possible option is to use the getRawDER method to export the raw certificate and reread it with NSS, but that seems like a pretty ugly hack to me.

from convergence.

So, we can dynamically add extensions, as long as each is less than 256 characters was what I was thinking?

from convergence.

however we get firefox to read it, it's a hack.

from convergence.

Sorry, I totally fumbled my explanation above (clearly hadn't had my coffee yet). What I meant to say is that the v3 extensions do not have a limited length, so we should be fine just picking one and using it.

Fair enough that it being a hack in any case. I've just pushed out an update to my fork (https://github.com/melknin/Convergence); testing requested.

from convergence.

Thanks for the heavy lifting on this, @melknin. I've pushed changes to the master Convergence branch that do the v3 extension tunneling for the verification data, although I switched to the NS "comment" extension. If you folks can confirm that this fixes the bug, we can close it.

from convergence.

This is now fixed in 0.04

from convergence.