NIST Elliptic Curve JWK field element octet string padding

[7ing]

Describe the bug
According to RFC 7518, Section 6.2.1.2 and Section 6.2.1.3, The length of the X and Y string MUST be the full size of a coordinate for the curve specified in the crv parameter. For example, if the value of crv is P-521, the octet string must be 66 octets long.

However, the jjwt library 0.12 version violates this requirement. Instead, it removes the leading zero byte and result in 65 octets long.

To Reproduce
Here is a (failed) test case:

// NOT A CONTRIBUTION
package io.jsonwebtoken.impl.security

import io.jsonwebtoken.Jwts
import io.jsonwebtoken.impl.DefaultJwsHeader
import io.jsonwebtoken.io.Decoders
import io.jsonwebtoken.security.Jwks
import org.json.JSONObject
import org.junit.Test

import static org.junit.Assert.assertEquals

class RFC7518Section6Dot2Test {

 @Test
 void test() {
 def key = Jwts.SIG.ES512.keyPair().build().getPublic();
 def jwk = Jwks.builder().key(key).build();
 def header = new DefaultJwsHeader(new JSONObject(jwk).toMap())
 def x = Decoders.BASE64URL.decode((String) header.get("x"))
 def y = Decoders.BASE64URL.decode((String) header.get("y"))
 assertEquals(x.size(), 66)      ////////// fail if X has a leading zero byte
 assertEquals(y.size(), 66)      ////////// fail if Y has a leading zero byte
 }

}

Expected behavior
jjwt implementation shall NOT change the bytes for X, Y coordinates.

[lhazlewood]

I could have sworn we had a test case for this, thank you for the issue! We'll incorporate your test (and probably a few more) and add any changes to the immediate next (0.12.4) release.