search

square / go-jose

An implementation of JOSE standards (JWE, JWS, JWT) in Go
1.98k stars 270 forks source link

There is no support for non native Golang keys, non standard algorithms and alternate entropy sources. #193

Closed dmercer-google closed 5 years ago

dmercer-google commented 5 years ago

tl;dr but I am trying to make a case for why this is important.

There are many instances where the keys, algorithms and the entropy source required to sign a JWT are not supported by Golang and go-jose. Issue #25 is an example of one such case.

Some examples of unsupported key types include:

There are instances where, so as to comply with internal security policy, signing must be performed with keys that are supported by Golang and/or go-jose but which employ the use of entropy sources other than crypto/rand.Reader. An example of this is where entropy must be generated through specific interaction with a hardware based entropy source (e.g. an HSM)

go-jose only supports a subset of the signing algorithms called out in the IANA registry of JSON Web Signature and Encryption Algorithms. Unsupported algorithms of note are EdDSA and none.

There are instances where algorithms not mentioned in the IANA registry of JSON Web Signature and Encryption Algorithms are required.

Some examples of such algorithms are:

RFC 7515 para 4.1.1 explicitly allows for the use of unregistered algorithms providing they do not lead to name collisions with IANA registered algorithms.

Lastly: There exist cases where an organization may want to “roll it's own” crypto. While generally ill advised, go-jose should not prohibit this. “Rolling one’s own” is often done to support research or to leverage emerging algorithms (e.g. XMSS, LMS, etc.).

go-jose should provide a means to support signing that meets all of the aforementioned cases.

Note: A pull request that addresses this issue will be created shortly.

dmercer-google commented 5 years ago

Solution proposed in PR 194

alokmenghrajani commented 5 years ago

I agree with the general idea of being more flexible when it comes to algorithms/HSMs.

Keys associated with Hardware Security Modules (HSM) exposing APIs other than PKCS11 (e.g. nCipher ncore keys).

nCiphers do expose a pkcs11 API. Moving a key from one application to another is possible (e.g. from java key to pkcs11 or vice versa), albeit painful.

dmercer-google commented 5 years ago

@alokmenghrajani

The nCipher PKCS11 implementation is an incomplete implementation of v2.2 and is this lacking in several areas, despite the underlying hardware having support for the v2.4 mechanisms and algorithms. I've a lot of experience with nCipher and have basically given up on their P11 drivers and I now live in ncore hell.

csstaub commented 5 years ago

Per discussion in #194, this is already supported on v2 through the OpaqueSigner interface. Hence closing this issue.