crypto/x509: parsing of certificates with exponent length > 32bit fails on GOARCH=386

[nurio]

1.) What version of Go are you using (go version)?
go1.6beta2
2.) What operating system and processor architecture are you using?
Architecture: 386 OS: windows
3.) What did you do?
Tried to parse a valid X.509 certificate using the public key exponent "4044784889" (0xf11684f9) with crypto/x509.ParseCertificate()
4.) What did you expect to see?
Certificate parses without error
5.) What did you see instead?
Parsing the certificate fails under Windows GOARCH=386 with "asn1: structure error: integer too large". It works correctly if compiled with GOARCH=amd64 and running on a 64bit OS.

Most certificates use 65537 as exponent which works fine, however according to NIST
"applications should be able to process RSA public keys that have any public exponent
that is an odd positive integer greater than or equal to 65537 and less than 2^256."

NIST Cryptographic Algorithms and Key Sizes for Personal Identity Verification

Simple go program containing a test certificate to reproduce the error:
test_cert_fail.go

[bradfitz]

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

/cc @agl

[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.)

[nurio]

@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?

[agl]

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.

[bradfitz]

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

[rsc]

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.