It reproduces in the playground: http://play.golang.org/p/sk1hcmlmBc

/cc @agl

I think the bug here is that the 64-bit version works. We should be consistent between 32- and 64-bit systems. (The rsa package already checks for exponents >= 2^31 and rejects them.)

@agl: I read your post regarding rsa exponent size and agree that there are likely no security benefits in using exponents larger than 2^31-1. However, I think it would be great if go could handle certificates with reasonably large exponents for compatibility reasons. There is crypto hardware (e.g. some athena smartcards) that generate RSA keys with larger randomly chosen exponents. That means that if they are used for issuer certificates in a PKI chain, go programs will not be able to make TLS connections to any certificates signed by these issuers.

Such certificates work with openssl (and therefore python, ruby, ...) and in current browsers (IE, Firefox, Chrome) which means that the PKI likely won't run into any problems with these certificates. And since they work "everywhere else", it might be easy for them to ignore the issue with go compatiblity.

OpenSSL limits the public exponent at 64 Bit, maybe this would be a reasonable compromise between compatibility and performance for go too?

Given that the public exponent is exposed API, and that it's an int, I think we're stuck with it on 32-bit systems.

We could add E64 int64 and document precedence between E and E64 if we wanted.

I don't think there have been enough reports about needing a fix for this to pollute the API with something like E64. Maybe for Go 2 we can think about making it an int64 for better portability.