x5c / x5t parameters

[aeneasr]

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

[csstaub]

There's not field for it in the struct right now, but it should be fairly simple to add. I can take a look at adding this next week maybe. Or if you want to take a shot at it, pull requests are welcome!

[aeneasr]

Hey I would be glad if you could take a look because I have a lot of work right now. If you don't find the time I will look at this in the next weeks / month

[aeneasr]

I took a quick look but I'm not really sure where to begin. I guess we need to add a type assertion for tls.Certificate in MarshalJSON. Then, marshal the private key using fromEcPrivateKey or respectively fromRsaPrivateKey. My question is how to encode tls.Certificate.Certificate in DER encoding - or is the byte slice already in DER encoding?

I guess it would look something like (pseudo):

raw, err = fromEcPrivateKey(cert.PrivateKey)
raw.X5c = base64(DER(cert.Certificate))

Am I on the right path here? Additionally, how to tests? :D

[csstaub]

You want x509.Certificate, not tls.Certificate. The only changes that would be required are the logic for marshalling/unmarshalling the list of []*x509.Certificate a caller puts into the X5c field of a jose.JsonWebKey struct. But while we're at it, should probably also add support for X5t and such.

[aeneasr]

Would base64(x509.Certificate.Raw) be enough for x5c? And base64(sha1(x509.Certificate.Raw)) for x5t?

[csstaub]

Yes -- also base64(sha256(certificate.Raw)) for x5t#S256.

[csstaub]

Although now that I think about it, setting x5t and x5t#S256 should actually be up to the caller.

[aeneasr]

Ok so only x5c for now?

[csstaub]

No I think the fields should be added to the struct, just serialize them directly.

[aeneasr]

I am confused. Do you mean that the developer using go-jose is responsible for x5t? I think I will stick to x5c for now - I'm not confident with the according RFCs and such.

[aeneasr]

Let's continue this in #96

[aeneasr]

resolved by #97