To avoid a potential DoS vulnerability in v3.0.0 update to v3.0.1.

Signed-off-by: Stefan Berger <[email protected]>

Bumps [golang.org/x/crypto](https://github.com/golang/crypto) from 0.14.0 to 0.17.0.
- [Commits](golang/crypto@v0.14.0...v0.17.0)

---
updated-dependencies:
- dependency-name: golang.org/x/crypto
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <[email protected]>

Now, passing a JWK (via EncryptWithJwe / JSONWebKey.MarshalJSON) will
allow for ECDSA keys and for customizing the algorithm used with a
particular key.

Previously, the code made it impossible to supply a JWK-encoded ECDSA
public key in the encryption config, as all keys passed as JSONWebKey-s
were treated as RSA_OAEP keys, since utils.ParsePublicKey delegates to
parseJWKPublicKey which returns the JWK itself; and hence the switch in
the JWE keywrap failed to detect those as an ecdsa public key.
A simpler patch here would have been to change parseJWKPublicKey to return
the key contained inside the JWK directly, however, as pointed out by
stefanberger, this would have broken backwards compatibility of the public
API. Plus, using the algorithm encoded in the JWK allows us to more easily
extend the JWE encoder to new algorithms.

Risks: JWK-s containing RSA keys but with .Algorithm not set to "" (the
default value) or string(jose.RSA_OLAP) will end up erroring or producing
different encryptions than before. However, such keys would have failed to
decrypt the contents regardless, so it should be fine to consider this a
correction rather than breakage of old behavior. (Hyrum's law
notwithstanding)

Signed-off-by: Bojidar Marinov <[email protected]>

To avoid a potential DoS vulnerability in v3.0.0 update to v3.0.3.

Resolves: Issue #104
Signed-off-by: Stefan Berger <[email protected]>