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 [email protected] https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
