Less strict validation

The purpose of this release is to use less strict validation for JWK. This will allow users to work with non-RFC compliant JWK Sets for small padding mistakes.

Two padding related reasons for this are:

1. Mandatory leading padding for ECDSA JWK parameters.
2. A common mistake adding leading padding to RSA JWK parameter "n".

For padding specifically, this project is only comparing integers after they are parsed from Base64 raw URL encoding by default. To turn on strict validation, there will be a new field on jwkset.ValidateOptions named StrictPadding.

An example for 1 would be a bug in this project were mandatory leading padding was absent: #18

An example for 2 would be a Firebase service that was reported to be incompatible with this project: #23

Relevant issues:

• #23
• #20
• #18

Relevant pull requests:

• #24

v0.5.13

The purpose of this release is to correctly pad EC JWK parameters with leading zeros where required by RFC 7518.

For "x" and "y":

The length of this octet 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.

For "d":

The length of this octet string MUST be ceiling(log-base-2(n)/8) octets (where n is the order of the curve).

This is to bring the project into RFC compliance with RFC 7518 Section 6.2.1.2, 6.2.1.3, and 6.2.2.1.

Relevant issues:

• #18

What's Changed

• Required leading zeros in ECDSA keys by @MicahParks in #19

Full Changelog: v0.5.12...v0.5.13

jwksetinfer tool multi-PEM bug

A bug in the cmd/jwksetinfer tool caused multiple PEM file inputs to only output the final PEM key as a JWK Set. This is because the metadata wasn't being passed in and the all key IDs were the same empty string.

Thank you @aarnaud for discovering the bug and fixing it!

Relevant pull requests:

• #15

Refresh on unknown key ID

The purpose of this release is to change the default HTTP client to add a feature that refreshes remote JWK Set resources when trying to read a key ID kid that has not been found in the local cache.

This requires rate limiting and the pkg.go.dev/golang.org/x/time/rate has been added as a dependency for that.

Related pull requests:

• #13

Consistent optional behavior for X.509 certificate thumbprints

This release fixes a bug where X.509 certificate thumbprints were not optional when a JWKMarshal without these fields was used in NewJWKFromMarshal.

Thank you, @joshkaplinsky, for reporting this bug!

Relevant pull requests:

• #12

Relevant issues:

• #11

Add HTTP Client

This release contains a Golang HTTP client for JWK Sets.

Add website and X.509 support

This project now supports all standardized JSON Web Key parameters, including X.509 assets that I could find. Please open an issue if you find some that are not supported.

Additionally, I made a website for this project. The website is mostly for generating and inspecting JSON Web Keys. Check it out at https://jwkset.com

Bug fix for RSA multi-prime keys

This release fixes a bug in marshaling and unmarshaling RSA multi-prime keys. It also adds a check to validate an RSA key before returning it from an unmarshal.

Relevant issues:

• #1

Private key JSON representation and individual JWK marshal/unmarshal type

The purpose of this release is to add multiple new features.

• Private key material now has a JSON representation.
• Individual cryptographic keys can be marshaled or marshaled to/from JSON via the JWKMarshal type and helper functions.