Support setting all headers anytime

[ekristen]

Support setting all headers anytime

[ekristen]

@shaxbee this might be a more relevant issue instead of being a JWT #126 specific issue. I appreciate your quick attention to all this.

Please note headers like x5t, x5c, should probably be a bool like JWK and added automatically if set since they are the fingerprint and contents of the public key associated with the private key being used to sign.

If you have any questions please let me know. Thanks again for the quick work!

[shaxbee]

@eriksten x5t contains certificate chain so I'll have to figure out the way to optionally pass it to signer.

[shaxbee]

Do you use crypto/x509 to load/manage certificate pool?

[ekristen]

@shaxbee I think that's reasonable to expect (using the crypto/x509). For example in my uses and in a few other uses I've seen, there is no certificate authority being used, its just the base64 encoding of the public key that corresponds to the private key being used in the signing algorithm, RSA or EC. I'm not using signed certs, just a generated private key and deriving the public key from it.

[shaxbee]

I can't find information in spec about which certificate in the chain is used for thumbprint calculation. Is it first or last? Is the chain always ordered from peer to root or the other way around? So far I exposed x5t, x5t#sha256 as string fields in JSONWebKey which then should be propagated to JWS headers. I can provide thumbprint functions or setters on JSONWebKey. @csstaub any thoughts?

…

On Sat, Dec 3, 2016, 12:59 AM Erik Kristensen ***@***.***> wrote: @shaxbee <https://github.com/shaxbee> I think that's reasonable to expect (using the crypto/x509). For example in my uses and in a few other uses I've seen, there is no certificate authority being used, its just the base64 encoding of the public key that corresponds to the private key being used in the signing algorithm, RSA or EC. I'm not using signed certs, just a generated private key and deriving the public key from it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#129 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE_mfZTGfYVuN8Fe2sCKgZpV8VtXtrJvks5rEE5lgaJpZM4K-jRs> .

[ekristen]

I would imagine it's the fingerprint for the private key used to sign. The same fingerprint should match any public key derived from the same private key.

…

Sent from my iPhone

On Dec 2, 2016, at 10:24, Zbigniew Mandziejewicz ***@***.***> wrote: I can't find information in spec about which certificate in the chain is used for thumbprint calculation. Is it first or last? Is the chain always ordered from peer to root or the other way around? So far I exposed x5t, x5t#sha256 as string fields in JSONWebKey which then should be propagated to JWS headers. I can provide thumbprint functions or setters on JSONWebKey. @csstaub any thoughts? On Sat, Dec 3, 2016, 12:59 AM Erik Kristensen ***@***.***> wrote: > @shaxbee <https://github.com/shaxbee> I think that's reasonable to expect > (using the crypto/x509). For example in my uses and in a few other uses > I've seen, there is no certificate authority being used, its just the > base64 encoding of the public key that corresponds to the private key being > used in the signing algorithm, RSA or EC. I'm not using signed certs, just > a generated private key and deriving the public key from it. > > — > You are receiving this because you were mentioned. > > > Reply to this email directly, view it on GitHub > <#129 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AE_mfZTGfYVuN8Fe2sCKgZpV8VtXtrJvks5rEE5lgaJpZM4K-jRs> > . > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[shaxbee]

It seems to be based on DER certificate which is public key part.

The "x5t" (x.509 certificate thumbprint) header parameter provides a base64url encoded SHA-256 thumbprint (a.k.a. digest) of the DER encoding of an X.509 certificate that can be used to match a certificate.

https://morgansimonsen.com/2013/04/16/understanding-x-509-digital-certificate-thumbprints/

I've provided helper functions to generate thumbprints from *x509.Certificate

See #131 for prototype.

[csstaub]

From the standard, about x5c ordering:

The certificate containing the public key corresponding to the key used to digitally sign the JWS MUST be the first certificate. This MAY be followed by additional certificates, with each subsequent certificate being the one used to certify the previous one. The recipient MUST validate the certificate chain according to RFC 5280 [RFC5280] and consider the certificate or certificate chain to be invalid if any validation failure occurs.

[csstaub]

Oh, also:

Each string in the array is a base64-encoded (Section 4 of [RFC4648] -- not base64url-encoded) DER [ITU.X690.2008] PKIX certificate value.

The use of base64 vs. base64url here is rather annoying.

[shaxbee]

@csstaub Thanks, I'm generating thumbprints and populating x5* headers in JWS, thumbprints can be provided as JSONWebKey field as well. I'll work on test and JWE headers next.
@ekristen could you try out my PR and see if API is convenient enough?

[shawnps]

@shaxbee is there currently a way to set "kid" on a JWS header as described here?

https://tools.ietf.org/html/rfc7515#section-4.1.4

Edit: nvm, I see you can pass a JsonWebKey to NewSigner. But what about being able to set Private Header Parameter Names as specified in the RFC here?

https://tools.ietf.org/html/rfc7515#section-4.3

[mitar]

So #242 added a bit of support for x5t header, but https://github.com/square/go-jose/pull/131 has also code to generate the field, which I would find very useful as well, to be able to get from JWK directly to x5t in go.