Re: [jose] Question regarding RFC 7515

[Anders Rundgren <[e-mail]>]

On 2020-12-02 04:26, Arshad Noor wrote:
> Hi,

Hi Arshad,

> 
> I have a few questions on the use of the "x5c" header parameter for
> which there is insufficient guidance.
> 
> 1) Section 4.1.6 (X.509 Certificate Chain) states that the "..chain is
> represented as a JSON array..". However, it is not clear whether a
> single certificate still needs to be enclosed within an array if one is
> using a self-signed certificate, and when using "Flattened JWS JSON
> Serialization Syntax".

It is always an array of JSON strings (=certificates).

> 2) Section 6 (Key Identification) states that "..Header parameters ..
> "x5c" .. MUST be integrity protected if the information ...is to be
> utilized in a trust decision. I take this to read that, when using the
> flattened JWS JSON serialization, "x5c" must be included in the
> "protected" attribute.
> 
> In Section 4.1.1 (Algorithm), the RFC states "This Header Parameter MUST
> be present .." and in Section 5.1 (Message Signature), "..(algorithm)
> Header Parameter MUST be present in the JOSE Header..". This implies
> that "alg" is part of the "protected" section of the JWS.
> 
> However, there is no guidance on how the "protected" attribute must be
> encoded when both, "alg" and "x5c" are present in the JWS. It seems
> logical that it would be encoded as a sub-JSON object; but there is
> neither any guidance nor an example of what is canonical here.

The contents of the "protected" attribute is identical to the header for compact serialization.  That is, a base64url encoded JSON object holding JOSE header data.

> 
> Second, if one creates a sub-JSON for "protected" in a "Flattened" JWS,
> should the "protected" attribute remain in text form or should it be
> Base64Url encoded before being signed?

Flattened JWS is just about taking the JWS compact elements apart.  You can create a valid Flattened JWS from a Compact JWS without any computations.

> 
> 3) Appendix B shows an example of an X.509 Certificate Chain using
> Base64-encoded strings to represent certificates. While this will work
> with most code, is there any rationale for departing from the PKI
> industry practice of using PEM encoded certificates for textual
> representations (considering the JWS JSON Serialization is not concerned
> with space limitations)? This advice is mandated in Section 4.1.5 for
> "x5u", referencing Section 6.1 of RFC 4945, but not so for "x5c".

The rationale for the "x5c" syntax is that it is "closer" to PEM than base64url :)

If you are looking for a more JSON-oriented signature solution you might take a look at:
https://www.ietf.org/archive/id/draft-jordan-jws-ct-00.html

Regards,
Anders

> 
> Thank you.
> 
> Arshad Noor
> StrongKey
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>