Hi there,

I spent some time this week becoming familiar with the JOSE familiar
of specifications, in the context of implementing a Mozilla Persona
identity provider. This took quite a bit longer than I expected,
partially due to a misunderstanding on my side about JWS.

In particular, I spent a few hours figuring out why my signatures were
being rejected by a Persona server, with the error message given "bad
signature in chain". It turns out that the signature I provided was
incorrect, because I had used basic RSA signing rather than PKCS1 v1.5
as the JWS spec seems to require. Unfortunately I spent much more time
looking at the JWS draft-06 appendices with examples than I spent time
looking at JWA, where the algorithms are properly called out. In fact,
while JWS seems to refer to the algorithms allowed quite often, the
term PKCS is not to be found in the current draft. I haven't read the
entire spec, but it seems an oversight not to include a reference to
PKCS, particularly in the example sections.

Finally, while I appear to be quite late to the party, I was wondering
if something like HTTP's Transfer-Encoding has been considered for
inclusion. The JOSE family of specs looks very useful, but one use
case I had developed earlier (for which I built my own serialization
format for encrypted and signed messages) included some form of
compression. It seems like a "te" field in the header part could,
through a value like "zlib" or "gzip", simply confer to the receiver
that the payload must first be decompressed after being decoded. This
would neatly encapsulate handling of larger payloads.

On the other hands, perhaps compression could easily be done with the
encoded header/payload/signature, without much of a loss in
compression efficiency due to the order of the compress and encode
operations.

Cheers, and thanks for the useful specs,

Dirkjan
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose

Reply via email to