Version 2.6.0

Last release from the v2 branch, includes various changes and bug fixes.

For future releases please see v3 at: http://github.com/go-jose/go-jose

Version 2.5.1

Bug Fixes

• Fix parsing and validation of x5t and x5t#S256 headers for JWK (h/t @mangas) (#305).

Version 2.5.0

New Features

• Add support for x5u, x5t, and x5t#S256 headers for JWK (#242).
• Add support for RFC 7638 canonical kid for JWK (#269).

Bug Fixes

• Add error checking in jose-util to avoid nil referencing (#250).
• Documentation improvements (#274, #280, #289).

Version 2.4.1

Bug Fixes

• Fixes a bug introduced in v2.4.0 that could cause a panic on invalid inputs (#282).
• Improves performance of parsing payloads with a lot of whitespace (#279).

Version 2.4.0

New Features

• Add support for the b64 header parameter (#230).
• Add functions to handle detached signatures (#234).
• Expose an interface for opaque key encryption/decryption (#261, #257).

Bug Fixes

• Fixes a issue with ECDSA on P-521, whereby the generated shared secret derived for encryption was computed incorrectly (#267, #245).
• Fixes salt length for new RSA-PSS messages to be equal to the hash length, as required by RFC 3447 (#232).
• Don't include the kid header in a JWT if the key id is an empty string (#227).

Version 2.3.1

Fixes a bug in the serialization of ED25519 keys to JWK (JSON), where X/D values ended up being switched for one another in the serialized output (see #224). Reading a serialized private key would also end up switching the X/D values for another, so keys that were serialized/deserialized with old versions of go-jose would work fine (values should end up in the correct place again). However, sharing a private key with another library would have caused problems. If you have private keys that were previously serialized to JWK using this library, the X/D values will be incorrect and will need to be switched in the JSON serialization before the key can be deserialized with an updated version of go-jose.

Version 2.3.0

New Features

• Add support for unwrapping JSON Web Key Set in the jwt sub-package. This means the key passed to Claims or Decrypt can now be a set of keys (of type *jose.JSONWebKeySet), and the key will be selected automatically based on the key id in the header of the token.

Bug Fixes

• Improves handling of exp, iat and nbf claims. This means proper handling for zero dates (#214), don't error if optional exp and nbf claims are missing from the token (#220), and perform an extra check on iat if it is present (#217). Note that expiration in tokens is optional per standard, if you want to require expiration or other claims to be absolutely present in a token be sure to check the claim is present.

Note this release also drops support for Go 1.5 and Go 1.6, we now require Go 1.7 or later.

Version 2.2.2

Exports the random reader used for internal randomness to make deterministic tests possible (#212). This allows consumers of the library to add tests that can compare known inputs/outputs deterministically.

Version 2.2.1

This release adds stricter checks (#210) for handling JWKs with elliptic keys. As per RFC 7518, Section 6.2.1.2 to 6.2.2.1 the length of this octet strings for X/Y/D values in JWKs MUST be the full size of a coordinate for the curve specified in the "crv" parameter. As a result, invalid JWKs that were previously accepted (e.g. a JWK where the padding was missing on X/Y coordinates) will now be rejected when parsing them.

Version 2.2.0

Bug Fixes

• Check that key size when matches cipher for DIRECT encryption mode (issue #204, fix in #205)
• Fix auth tag length for A192CBC-HS384, A256CBC-HS512 to match spec (issue #206, fix in #207)

Note: We bumped the minor version in this release because the changes in #207 fixes a compatibility issue with the implementations of the A192CBC-HS384 and A256CBC-HS512 ciphers. The library didn't correctly follow the JOSE specification (RFC 7518) when encrypting and as a result ciphertexts produced with square/go-jose were incompatible with other JOSE implementations. Ciphertexts produced from other libraries with those ciphers would still decrypt correctly. If you were encrypting with A192CBC-HS384 and A256CBC-HS512 using old versions of this library there might be compatibility concerns when upgrading.