I am not able to encrypt/decrypt within Java and Go using Curve P521, ECDH-ES, and A256GCM using the same values for curve X, Y, and D. When I try to take the encrypted value from Java and Decrypt in Go it fails (about half the time) and vice versa it fails with:

Go: square/go-jose: error in cryptographic primitive

Sometimes it works though.

I am manually creating the KeyPair in both programs with the same X, Y, and D. Here is a link to my stackoverflow question.

https://stackoverflow.com/questions/55711277/why-do-i-get-an-error-decrypting-jwe-between-java-and-go

The JWE spec supports more than just the two fields allowed currently in go-jose (alg and enc). You can also specify a kid which is really important when using symmetric encryption like AES with JWE.

I'm attempting something like so:

    alg := jose.KeyAlgorithm("dir")
    enc := jose.ContentEncryption("A256GCM")
    encrypter, err := jose.NewEncrypter(alg, enc, resp.Plaintext)
    if err != nil {
        log.Fatalf(err.Error())
    }
    obj, err := encrypter.Encrypt([]byte(contents))
    obj.Header.KeyID = "XXXXXX"

but when I attempt to base64 decode the header (first part), I still only see alg and enc.

I'm proposing either changing the Encrypter interface to support new funcs for adding kid specifically or a more generic one to allow setting headers that are unrelated to the encryption and key methods being used.

I can maybe make a PR on this but I need to know which way you'd rather go first.

Thanks!

I want to access JWS payload before it gets verified.

Use Case: I am building an Open ID Connect clients which accepts ID Tokens (i.e. JWTs signed by JWS) issued by multiple issuers. In this client, parse a JWS payload at first, then recognize the issuer by iss claim of the payload and retrieve JWKs via Open ID Connect Discovery flow, finally verify the JWS using retrieved JWKs.

I looked for a go-jose's API that exports an unverified JWS payload but could not find. Do you have any plans to support this use case?

Is it possible to use x5c parameters with go-jose? I want to marshall a RSA private key along a x509 certificate (for HTTP over TLS).

Example: https://tools.ietf.org/html/rfc7517#appendix-B

Claims represented as concrete type.

Follows JWT spec on interpretation of claim fields values, namely:

• NumericDate can be represented as either int or float
• Audience can be either string or array of strings

Timestamps are normalized by checking Time.IsZero, otherwise negative timestamp values would show up in encoded JSON.

Validator is checking Expiry/NotBefore using leeway as indicated in a spec. Current time is provided as argument to Validator.Validate call. Unit tests for validator are still pending.

@mbyczkowski

-Add support for x5u, x5t, and x5t#S256 headers for JWK (#242).

#issue 1 has some breaking changes particularly in the jwk.go, where

method name : func (k *JSONWebKey) UnmarshalJSON(data []byte) (err error)

k.CertificateThumbprintSHA1 = raw.X5tSHA1.bytes() k.CertificateThumbprintSHA256 = raw.X5tSHA256.bytes()

here the raw value is attempted to convert in bytes but it does not work as expected in fact, it returns base64 decoded value for kid attribute in the token.

as a result following conditions always fails,

if x5tSHA1Len > 0 && x5tSHA1Len != sha1.Size { return errors.New("square/go-jose: invalid JWK, x5t header is of incorrect size") } if x5tSHA256Len > 0 && x5tSHA256Len != sha256.Size { return errors.New("square/go-jose: invalid JWK, x5t header is of incorrect size") }

here sha1.Size is the checksum size which is expected to be 20 bytes. but the value which we are assigning k.CertificateThumbprintSHA1 is not a checksum instead it's a raw hash for sha1 or sha256. So when x5tSHA1Len := len(k.CertificateThumbprintSHA1))is executed length turns out to be 40

solutions: use x5tSHA1Len := len(sha1.Sum(k.CertificateThumbprintSHA1))

#issue 2

// If certificate chain and thumbprints are set, verify correctness. if len(k.Certificates) > 0 { leaf := k.Certificates[0] sha1sum := sha1.Sum(leaf.Raw) sha256sum := sha256.Sum256(leaf.Raw) if len(k.CertificateThumbprintSHA1) > 0 && !bytes.Equal(sha1sum[:], k.CertificateThumbprintSHA1) { return errors.New("square/go-jose: invalid JWK, x5c thumbprint does not match x5t value") }

	if len(k.CertificateThumbprintSHA256) > 0 && !bytes.Equal(sha256sum[:], k.CertificateThumbprintSHA256) {
		return errors.New("square/go-jose: invalid JWK, x5c thumbprint does not match x5t#S256 value")
	}
}

I don't understand what are we trying to validate here but this condition seems to be failing always.

feel free to reach out in case of questions or queries

Add functionality to support for password-based cryptography with the optional key algorithms:

• PBES2-HS256+A128KW
• PBES2-HS384+A192KW
• PBES2-HS512+A256KW

PBES2 algorithms require two new parameters in the header p2c (pbkdf2 number of iterations) and p2s (salt). I added those parameters in the recipient and they are optional. Safe defaults are used if they are left empty, 100,000 for the count and a 128 bits salt. NIST recommendation is at least 10,000, but some applications like 1Password are already using 100k.

I'm open to suggestions, do a PR for the master branch, change the defaults, or use EncrypterOptions to add the extra parameters instead of the recipient.

The JWA spec says:

The "n" (modulus) parameter contains the modulus value for the RSA public key. It is represented as a Base64urlUInt-encoded value.

However, Base64URL-encoded "n" parameter cannot be unmarshalled into JSONWebKey in go-jose.

Here is what I'm trying to do:

var d jose.JSONWebKeySet
if err := json.Unmarshal(body, &d); err != nil {
	return err
}

When the "n" parameter in the json body is Base64URL encoded instead of Base64 encoded, I get the error illegal base64 data at input byte 343. I think this is because encoding/json package expects a Base64-encoded string when decoding to []byte.

Not sure if I'm missing something?

This can be solved by changing the type of N in rawJSONWebKey to string. If I'm right, let me know, I'll gladly submit a PR.

r: @alokmenghrajani @mcpherrinm @sqshh @jsha @rolandshoemaker

Fixes issue #73 by switching to a forked, case-sensitive version of encoding/json (from Go 1.6).

Changes in square/go-jose:

• Switch to forked json package
• Add tests for case-sensitive parsing behavior
• Drop Go 1.2 support (broken with forked json)

Changes in the forked encoding/json package:

• Remove fold.go, fold_test.go (contained case-sensitive folding functions)
• Set equalFold to be bytes.Equal in encode.go (no more case-sensitive matching)
• Removed example_test.go (broke build on older Go versions)

Also updated some of the test cases in the forked json package, as they were depending on the case-insensitive parsing behavior. In particular, decode_test.go (c.f Ambig struct) was updated.

The certificate for CN=TrustedSigner has been regenerated with SAN extension. Due to missing keys, certs for CN=TrustedCA & CN=IntermediateCA have been regenerated as well.

Resolves #330.

The format string edThumbprintTemplate was broken, missing opening " before x property name. It cause interoperability issues with other JOSE implementations.

In case RawURLEndocing fails while decoing JWKs, try if falling back to Standard URLEncoding can decode - which may be the case i.e with padded JWKs

Fixes #373

Hi everyone,

I am using go-jose as a transient dependency (in oauth2-proxy) at a customer's in combination with Oracle Access Manager. Since the release of 2.5.1 (I guess due to the fix of #299 ), validation of the JWK in use is breaking with the error message square/go-jose: invalid JWK, x5t header has invalid encoding.

I think I narrowed the issue down to Base64 padding of the x5t and x5t#S256 headers breaking the decoding of the headers in https://github.com/square/go-jose/blob/v2/jwk.go#L251 and respectively https://github.com/square/go-jose/blob/v2/jwk.go#L271 for x5t#S256.

For compliance reasons, I am not able to submit the real key for testing but I was able to construct a test key based on https://docs.oracle.com/en/cloud/paas/identity-cloud/rest-api/op-admin-v1-signingcert-jwk-get.html that is triggering the same behavior:

{
      "kty": "RSA",
      "e": "AQAB",
      "x5t": "wCAFGcBT8CeA4U2mYa4z3xg0-Zw=",
      "kid": "SIGNING_KEY",
      "x5c": [
        "MIIDQzCCAiugAwIBAgIGAU+7bWHIMA0GCSqGSIb3DQEBCwUAMFExGzAZBgNVBAoTEk9yYWNsZSBDb3Jwb3JhdGlvbjEhMB8GA1UECxMYaWRlbnRpdHkub3JhY2xlY2xvdWQuY29tMQ8wDQYDVQQDEwZHbG9iYWwwHhcNMTUwOTExMDgwMjMxWhcNMjUwOTExMDgwMjMxWjBRMRswGQYDVQQKExJPcmFjbGUgQ29ycG9yYXRpb24xITAfBgNVBAsTGGlkZW50aXR5Lm9yYWNsZWNsb3VkLmNvbTEPMA0GA1UEAxMGR2xvYmFsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxWVFlx+E925RYQjPnKpKtHLqUonJMI1/xyM1f4Orly9RzpcaXX7ajEkgMAzffL3rsvBQkPLmO0vHIHs4KNdWoVUmbLZerjDdfLZQl3FZuXcZKXtzVOLyBVt2SNp/k23VgyGN7+8tiAJWC9SFIPBdWD8U2dxqM9izSEn9pvoMyR5iyaEoZepazJQPLysrF23g1/gI8Bo2EUAHdO5atfGfT2YQbZPSOBWiq09QYwMRBuI0Ye0TI3GwYs1x3/2LoporOj+fkYCl4ki4JK2ifwk+TA5o29cdNSuSoA7rTZL3u+dNw0c6OPxvnW6LtCn4RpieZTh7W2sYLg8ozBwd3PHNTwIDAQABoyEwHzAdBgNVHQ4EFgQUi9Fzo9g57klDG3Kv0nK+8IhbtrIwDQYJKoZIhvcNAQELBQADggEBAKx9sZvbGiQnbO/BfgdlXwloqwjZHT3Byr91Pqp0zXrdg/QaUMIOiJQ8A85d5ptccpgNrYzIukSdFUzRP0kugyNzdFXBZ9/muhSkiFBdfBBdEwqXprdZBHcwWng9t2iww4tvzVhw06ZcIYyGUo8/e8erXmiOt9WeFhi7utQg+gyKw01RvaP73ApCpMuQjxTh7QgQNh02Xo+1QStYLFGcv+ZqHhTZwqOndZiQ68t7JcbGaZmNMxKwR4Z1go+RZ+4Ffa8d9rH1OiXWNB6ukGawQdcfZWNlUWcA7ntRSCfKP5UeDcNpHBDCVZSTvnpAEB42jiTuRuWfuA5Lq0rTDxapmzI="
      ],
      "alg": "RS256",
      "n": "xWVFlx-E925RYQjPnKpKtHLqUonJMI1_xyM1f4Orly9RzpcaXX7ajEkgMAzffL3rsvBQkPLmO0vHIHs4KNdWoVUmbLZerjDdfLZQl3FZuXcZKXtzVOLyBVt2SNp_k23VgyGN7-8tiAJWC9SFIPBdWD8U2dxqM9izSEn9pvoMyR5iyaEoZepazJQPLysrF23g1_gI8Bo2EUAHdO5atfGfT2YQbZPSOBWiq09QYwMRBuI0Ye0TI3GwYs1x3_2LoporOj-fkYCl4ki4JK2ifwk-TA5o29cdNSuSoA7rTZL3u-dNw0c6OPxvnW6LtCn4RpieZTh7W2sYLg8ozBwd3PHNTw"
    }

Unfortunately, this one does not have a SHA 256 fingerprint, though.

My propose on handling this would be to fall back to decoding with base64.URLEncoding in case base64.RawURLEncoding is failing:

// x5t parameters are base64url-encoded SHA thumbprints
// See RFC 7517, Section 4.8, https://tools.ietf.org/html/rfc7517#section-4.8
x5tSHA1bytes, err := base64.RawURLEncoding.DecodeString(raw.X5tSHA1)

// we might get base64 encoded parameters that include padding
// this is not supported by RawURLEncoding, so as a backup, let's try to decode with URL encoding
if err != nil {
	x5tSHA1bytes, err = base64.URLEncoding.DecodeString(raw.X5tSHA1)
}

if err != nil {
	return errors.New("square/go-jose: invalid JWK, x5t header has invalid encoding")
}

However, I am not a Go expert, so please correct me if there is a better way. Currently I am checking if I can submit a proper PR for this without breaking compliance.

As far as I understand, go-jose implements the JSON Web Signature (JWS) Unencoded Payload Option (https://www.rfc-editor.org/rfc/rfc7797) via the SigningOption: func (*SignerOptions) WithBase64.

I tried setting this option via: opt := (&jose.SignerOptions{}).WithBase64(false), but it still leads to a base64 encoded payload when using full serialization. The option is indeed evaluated and the payload is not base64 encoded in signing.go (https://github.com/square/go-jose/blob/v2/signing.go#L291), but then, in the FullSerialize() the rawJSONWebSignature containing a Payload *byteBuffer is serialized.

For the byteBuffer, a custom JSON Marshalling method is implemented in encoding.go (https://github.com/square/go-jose/blob/v2/encoding.go#L142) and this method always encodes base64:

func (b *byteBuffer) MarshalJSON() ([]byte, error) {
	return json.Marshal(b.base64())
}

Did I do something wrong using the WithBase64() option or doesn't this mean setting WithBase64 still leads to base64-encoded payload?

Does this project have helper methods or something for a jwk that fetch keys from a remote url ? something like below

       const url = "https://abc.com/keys"

	jwks, err := NewJWKFromWeb(url)

	key, err := jwks.Key("id1")

I have a decryption key and a JWE token that I can decrypt in python like so:

from jose import jwe, jwt
from jose.utils import base64url_decode

TOKEN="sfsdfsdfsfs.sfsfsdfsf.sfsfsfsf"
decryption_key_bytes = base64url_decode("ODFfdsdfs879s8fs=")
decrypted_token = jwe.decrypt(TOKEN, decryption_key_bytes)

print("Decrypted token:")
print(decrypted_token)
print("\nToken contents:")
print(jwt.decode(decrypted_token, None, options={"verify_signature": False}))

Doing the "same" In golang results in the above error:

package main

import (
	"encoding/base64"
	"fmt"

	"gopkg.in/square/go-jose.v2"
)

const customersJweRaw = "sfsdfsdfsfs.sfsfsdfsf.sfsfsfsf"

func main() {
	base64Decode, err := base64.StdEncoding.DecodeString("ODFfdsdfs879s8fs=")
	if err != nil {
		panic(err)
	}
	jwe, err1 := jose.ParseEncrypted(customersJweRaw)
	if err1 != nil {
		fmt.Println(err1)
		return
	}
	bytes, err2 := jwe.Decrypt(jose.JSONWebKey{Algorithm: "A256KW", Use: "A256GCM", Key: base64Decode})
	if err2 != nil {
		fmt.Println(err2)
		return
	}
	fmt.Println(string(bytes))
}

I have also tried not specifying the encryption / decryption algorithm and just pass the key like so: jwe.Decrypt(base64Decode), but got the same result.

Bellow is the screenshot of the document for the token origin. I am not creator of the token, we get it from the client.