Any feedback on this? I can understand how no one is interested in discussing a new header option at this stage (particularly if there are out-of-band methods to solve the problem), but the lack of mentions of PKCS seems like a significant usability bug. I will add to the paragraph from below that the appendix also doesn't explicitly refer to relevant sections of the JWA spec.
Cheers, Dirkjan On Sat, Oct 20, 2012 at 6:47 PM, Dirkjan Ochtman <[email protected]> wrote: > 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
